PMOinformatica.

com
La oficina de proyectos de informática
La web sobre gerencia de proyectos de informática, software y tecnología. Síguenos en:

Principal Sobre el blog Plantillas Gerencia de proyectos Agile / Scrum Desarrollo y tecnología Cursos Productos Amazon Contacto

Suscríbete a la lista de correo

electrónico:

Descargar Avast Free Ingresa tu email:

Antivirus Suscríbete
100% Gratis y Fácil Descarga
Artículos, plantillas, ejemplos, reseñas
de libros y mucho más
Avast ABRIR
completamente gratis.

Lo más leído en pmoinformatica.com

Requerimientos funcionales: Ejemplos

lunes, 6 de mayo de 2013
Los requerimientos funcionales de un
sistema, son aquellos que describen
¿Qué son las historias de usuario?: 5 errores comunes al escribirlas cualquier actividad que este deba
realizar, en otras palabra...

BÚSQUEDAS PATROCINADAS
Requerimientos no funcionales:
plantillas para proyectos gratis plantillas de gestion de proyectos Ejemplos
Imagen de: Epicentre Presentamos la
logros a los 4 meses metodo scrum tercera parte de la serie sobre los
requerimientos no funcionales, con
algunos ejemplos que pu...

Plantilla del acta de constitución de

proyecto (Project Charter)
Imagen de: pmoinformatica.com El
Project Management Institute ( PMI )
define el “Acta de Constitución del
Proyecto” (Project Chart...

Lo urgente y lo importante: 9
recomendaciones para una delegación
efectiva
Imagen de: Cognition Global Concepts
Una habilidad primordial de todo
Gerente es el saber delegar
Imagen de: The DIY Musician adecuadamente las tareas, manteni...

Pmoinformatica.com, “La Oficina de Proyectos de Informática”, presenta una nueva entrega de su serie “¿Qué son
las historias de usuario?, en esta ocasión comentaremos acerca de “5 errores comunes al escribir historias de usuario”. BÚSQUEDAS PATROCINADAS

Las historias son el principal instrumento de levantamiento de requerimientos en el marco del desarrollo ágil de software, historia de usuario filtrar productos
que ha tomado gran auge junto con Scrum, las técnicas de Extreme Programming (XP) y otros marcos de trabajo ágiles.
plantillas para proyectos gratis

plantillas de gestion de proyectos

Large-Scale API Collaboration
logros a los 4 meses
Maintain a single source of API truth throughout your enterprise
with Postman. proyectos de infraestructura

Postman OPEN Visitas de los últimos 30 dias

166,178

En el artículo presentamos 5 errores comunes que pueden cometerse al escribir historias de usuario, tales como: Definir el
rol en la historia como “Usuario”, “Dueño de Producto” o “Desarrollador”, estos son roles inespecíficos no asociados a algún
proceso de negocio en particular. Asimismo, otros errores comunes son, el no describir el valor de la historia para el área de
negocio y no describir los criterios de aceptación de la historia.

Presentamos a continuación el artículo:

Referencia

Este escrito está basado en un artículo original de Kristian Kaczor, para Scrum Alliance, titulado, “5 Common Mistakes
We Make Writing User Stories”. Invitamos a su lectura.

Plantilla de historias de usuario

Pmoinformatica.com coloca a su disposición una “Plantilla para documentar historias de usuario y criterios de
aceptación”, completamente gratis. Nos gustaría recibir sus comentarios sobre la plantilla y sobre el contenido del blog. Enlaces a Blogs

5 errores comunes al escribir historias de usuario El Laboratorio de las TI

El Haiku: Para inventar se necesita… (Thomas Edison)
Hace 23 horas
1.- Definir el rol a quien va dirigida la historia como el “Usuario”
TestingBaires
Seminario gratuito de Machine Learning con Ariel
Ejemplo: “Como un Usuario, deseo poder gestionar cuentas de cliente, con el fin de eliminar cuentas no utilizadas o cuentas Thenon el 26 de mayo, organizado por la Comunidad de
erróneas”. graduados
Hace 4 días

A primera vista, todos los elementos que requiere una historia están presentes. Sin embargo, ¿Qué sucedería si Recusos en project management
necesitamos entender el rol del usuario para poder construir la funcionalidad del sistema?, ¿Quien es la persona para la cual Hace 1 semana
se desarrollará esta funcionalidad?, ¿es un Representante de Atención al cliente que necesita verificar los datos de clientes
Navegapolis
individuales mientras atiende llamadas telefónicas en un Call Center? o ¿es un administrador de un canal virtual de atención
Por qué pusimos en marcha un registro de propiedad
al cliente que necesita una lista de clientes ordenadas por antigüedad?. intelectual
Hace 3 meses
Las expectativas del sistema pueden ser muy diferentes según se defina el rol para quien se desarrolla la historia, por
Daniel Echeverría
lo que es muy importante definirlos específicamente, evitando roles genéricos en las historia, como por ejemplo "El PMI cambia la fecha para el cambio de exámen PMP.
Usuario". Finalmente será el 1 de Julio de 2020.
Hace 9 meses

Formación en Scrum Blog de Víctor M. Fernández

¿Ayudan las APIs abiertas a la evolución de la
tecnología e infraestructura?
Hace 2 años
 En Scrum, el responsable de gestionar el Product Backlog es el Product Owner.

Curso de Product Owner

Categorías

Acta de constitución de proyecto ( 5 )

Cómo desempeñar el rol para maximizar el valor del software desarrollado para la Amazon ( 9 )
organización. Análisis de Requerimientos ( 52 )
Antipatrones ( 9 )
2.- Definir el rol a quien va dirigida la historia como el “Product Owner” Aspectos Generales ( 30 )
Automatización de Pruebas ( 17 )
Ejemplo: ¿Cómo Product Owner, quiero que el sistema tenga la posibilidad de eliminar cuentas del cliente, con la finalidad Bases de datos ( 5 )
que los usuarios puedan eliminar las cuentas de cliente? Boletines ( 2 )
Buenas Prácticas ( 24 )
De nuevo, todos los elementos están presentes, pero algo está mal, primero se dice que el “Product Owner Quiere”,
Certificaciones ( 38 )
pareciera ser una historia que se escribió porque alguien la quería y no porque realmente la necesitaba. Luego, una historia
Ciclo de vida de sistemas ( 11 )
no puede ser dirigida al Product Owner (este es un representante de las necesidades de los usuarios de las áreas de
negocio), hacerlo de esta manera evidencia problemas conceptuales en la implementación del desarrollo ágil, además, al CMMI ( 2 )
igual que en el punto 1, no se le asigna un rol claro a la persona que permita establecer sus expectativas. Comercialización y ventas ( 1 )
Cómo elaborar ( 1 )

3.- Definir el rol a quien va dirigida la historia como el “Desarrollador” Competencias Profesionales ( 16 )
Conferencias y Eventos ( 2 )
Ejemplo: “Como desarrollador, yo quiero reemplazar el Widget de Barra para seleccionar productos, con la finalidad de dar Cursos ( 67 )
mantenimieno al widget de barra para seleccionar productos”. Definición de ( 2 )
Desarrollo ágil ( 70 )
Este es un ejemplo típico de una historia para un Backlog técnico o la representación de un requerimiento técnico. Estas Desarrollo de Carrera Profesional ( 70 )
historias con frecuencia formar parte de la deuda técnica que puede ir creciendo a lo largo del proyecto. Por lo general, la Desarrollo de software ( 145 )
deuda técnica incluye actividades de mantenimiento necesarios para realizar actualizaciones de software, refactorización,
Desarrollo evolutivo ( 1 )
cambiar frameworks, entre otros.
Desarrollo para móviles ( 17 )

Si describimos estás historias técnicas de la forma en que se presenta en el ejemplo, no estamos agregando ningún valor al Desarrollo para Tablets ( 15 )
cliente, por lo que no obtendremos el apoyo del Product Owner y muchos menos de los usuarios del área de negocio. desarrollo profesional ( 1 )
Estimación y Planificación ( 56 )
¿Cómo escribir esta historia de forma correcta?, por ejemplo podría hacerse de la siguiente forma: “Como un usuario Estudios Universitarios ( 2 )
comercial, yo necesito poder ver múltiples productos en una misma barra y poder seleccionarlos, para poder hacer mi Examen PMP ( 10 )
selección de forma más rápida”. Luego de describir la historia, describiríamos tareas como "Hacer Refactorización del Extreme Programming ( 2 )
mecanismo para incluir los productos en el widget de barra de productos" y luego "actualizar la versión de Java", entre otras. Frases célebres ( 2 )
Gerencia de Proyectos ( 150 )
Los criterios de aceptación deben ser medibles y verificables mediante pruebas, por ejemplo, “el usuario puede ver en la
Gestión de Portafolio ( 7 )
barra 5 productos en una misma vez” y “al presionar el botón para mover la barra, el usuario puede recorrer cinco productos
en menos de 5 segundos”. Otro criterio pudiera ser, “al hacer click sobre el producto, la página de detalle del producto se Gestión de Tecnología ( 109 )

muestra en menos de 4 segundos”. Herramientas ( 15 )

ISTQB ( 5 )

Lectura Recomendada sobre Desarrollo Ágil de Software ITIL ( 14 )

Lecciones Aprendidas ( 14 )
Proyectos Ágiles con Scrum: Flexibilidad, aprendizaje, innovación y colaboración en contextos Libros ( 37 )
complejos Libros en Español ( 27 )
Autor: Martin Alaimo; Martin Salas. Liderazgo ( 2 )
>> Latinoamérica (amazon.com) Metodologías ( 39 )
>> España (amazon.es) Metodologías Ágiles ( 62 )
>> Ver reseña
Microsoft Project ( 4 )
Noticias ( 11 )
Plantillas y Formatos ( 39 )
Kanban: Cambio Evolutivo Exitoso Para su Negocio de Tecnología
Anderson, D; Reinertsen, D; Maeda, M (Traductor). PMBOK 5ta Edición ( 13 )
España (Amazon.es) PMBOK 6ta edición ( 13 )
Latinoámerica (Amazon.com) PMI ( 33 )
Prince2 ® ( 3 )
Pruebas de Software ( 71 )
Riesgos en Proyectos ( 18 )
Ruby ( 1 )
4- No describir el valor para el negocio o beneficio SCRUM ( 43 )
Seguridad informática ( 3 )
Ejemplo: “Como vendedor de libros, quiero una opción de filtrado”. Sistema Kanban ( 1 )
Software ( 11 )
En este ejemplo, tenemos el rol, tenemos la necesidad, pero falta la razón y el valor de negocio. ¿Por qué un vendedor
Tendencias ( 8 )
quiere una opción de filtrado?, ¿Qué objetivo necesita alcanzar con eso?, ¿Es por ejemplo para poder responder a
solicitudes especificas de clientes?. Necesitamos describir este valor o funcionalidad en las historias de usuario para que Test Driven Development ( 11 )
los desarrolladores cuenten con más información sobre las expectativas de los usuarios. Tutoriales ( 1 )
Webinar ( 39 )

5- No establecer los criterios de aceptación o condiciones de satisfacción

Cada historia de usuario, debe ser documentada con sus criterios de aceptación o condiciones de satisfacción, no
hacerlo, puede ocasionar una definición inadecuada de las tareas o estimación errónea (subestimación o sobrestimación del
esfuerzo requerido). Como resultado, los casos de prueba no cubrirán los criterios adecuados debido a un
entendimiento erróneo.

Los criterios de aceptación juegan un papel importante en la confirmación del entendimiento del requerimiento. Estas
condiciones sirven como iniciadoras de conversaciones entre el equipo y el Product Owner.

En la medida en que se descubren estos criterios de aceptación, es posible que las historias necesiten ser refinada,
replanificadas o divididas en varias historias.

¿y qué opina usted?

¿Qué opinas tu de las historias de usuario como instrumento de levantamiento de requerimientos?, ¿Cuáles ventajas y
desventajas encuentras?, ¿Consideras que falta algún error común en esta lista?. Archivo del blog

Te invitamos a dejarnos comentarios en la Web de La Oficina de Proyectos de Informática (pmoinformatica) (Si lo 2020 ( 25 )
deseas, puedes firmar tu comentario con la dirección de tu web). 2019 ( 66 )
2018 ( 56 )
<< Artículo anterior: ¿Qué son las historias de usuario?: 7 preguntas y respuestas
2017 ( 35 )
>> Siguiente artículo: ¿Qué son las historias de usuario?: Recomendaciones sobre su definición y uso 2016 ( 37 )
2015 ( 53 )
¿Buscas más información de metodologías ágiles? 2014 ( 49 )
2013 ( 85 )
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de
diciembre ( 5 )
metodologías ágiles?, entonces presiona "suscríbete" a continuación.
noviembre ( 5 )

Suscríbete a la lista de correo electrónico: octubre ( 6 )

septiembre ( 5 )
Suscríbete agosto ( 4 )

Vía FeedBurner, se abrirá una nueva ventana julio ( 11 )

junio ( 9 )
También puedes seguirnos vía Twitter, Facebook o Linkedin: mayo ( 9 )
may 29 ( 1 )
 may 27 ( 1 )
may 22 ( 1 )
may 20 ( 1 )
¿Interesado en otros productos y últimas novedades sobre desarrollo ágil? may 15 ( 1 )
>> Visita nuestra sección de productos amazon
may 13 ( 1 )

Referencia may 08 ( 1 )
may 06 ( 1 )
5 Common Mistakes We Make Writing User Stories ¿Qué son las historias de usuario?: 5 errores
comu...

Otros artículos sobre Desarrollo ágil, Scrum y Test Driven Development may 01 ( 1 )

abril ( 9 )
Desarrollo Ágil en grandes empresas: 3era Parte
marzo ( 6 )
Desarrollo Ágil en grandes empresas: Amazon.com (2da parte)
febrero ( 7 )
Desarrollo Ágil en grandes empresas: Amazon.com (1era parte) enero ( 9 )
Demanda creciente de conocimientos en desarrollo ágil
2012 ( 74 )
8 argumentos para convencer a tu jefe de adoptar Scrum
2011 ( 4 )
10 razones para aplicar metodologías ágiles: Segunda Parte
10 razones para aplicar metodologías ágiles: Primera parte
¿Cuando aplicar y no aplicar el desarrollo ágil?
Refactorización: 6 preguntas y respuestas
TDD: Componentes difíciles de probar
Test Driven Development (TDD): Pruebas de desarrollador
Test Driven Development (TDD): Ventajas y desventajas
Test Driven Development (TDD): Desarrollo de software guiado por pruebas
Test Driven Development (TDD): 9 retos para su implementación
Test Driven Development (TDD): Como llevarlo a la práctica
Gestión de Proyectos PMI y el Desarrollo Ágil: ¿Que tienen en común?
5 Preguntas y respuestas sobre el Feature Driven Development (FDD)
5 métricas de desempeño para proyectos de desarrollo ágil y Scrum
Metodologías de desarrollo ágil
Los Programas de Certificación del Scrum Alliance
Peguntas y Respuestas sobre el Scrum Alliance

Publicado por pmoinformatica.com en 12:40:00 a. m.

Etiquetas: Análisis de Requerimientos , Desarrollo ágil , Metodologías Ágiles , SCRUM

No hay comentarios :

Publicar un comentario

Introduce tu comentario...

Comentar como: Cuenta de Google

Publicar Vista previa

Entrada más reciente Página principal Entrada antigua

Suscribirse a: Enviar comentarios ( Atom )

Pmoinformatica.com," La Oficina de Proyectos de Informática ", es un participante en el Programa de Servicios de Amazon

Associates LLC, un programa de publicidad de afiliación diseñado para proporcionar un medio para que sitios web puedan ganar
honorarios por la publicidad y enlaces a amazon.com y amazon.es.

Copyright 2012-2018. www.pmoinformatica.com. Todos los derechos reservados. Con la tecnología de Blogger.