 |
| Imagen de: Everac 99 |
Las siguientes recomendaciones fueron recopiladas de comentarios de la comunidad en los Grupos de discusión Agile-Spain y Scrum Manager de la red social para profesionales "Linkedin". Agradecemos a todos sus comentarios que hicieron posible la publicación de este Post.
En el artículo presentamos recomendaciones para definir y usar historias de usuario: Independencia y atomicidad de las historias, en cuantas iteraciones debe poderse hacer una historia de usuario, tamaño que deben tener las historias, los criterios de aceptación, valoración y estimación, recomendaciones para dueños de producto (product owners) y desarrollo de las historias (durante la iteración). El artículo está orientado al marco de trabajo scrum, pero se puede aplicar también en otros marcos de trabajo ágiles.
A continuación el artículo:
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.
Infografía sobre historias de usuario
Del Blog de Miguel A. Mora nos aportó una muy interesante infografìa de las Historias de Usuario, que define que son y para que se usan. Recomendamos también la lectura del Blog de Miguel A. Mora.
- Las historias de usuario deben ser independientes unas de otras, cada una debe corresponder con una única funcionalidad que pueda salir a producción.
- Deben definirse procurando su atomicidad, si el alcance es demasiado pequeño, tal vez sea necesario agrupar con otras historias, o si es muy grande, la historia debería dividirse.
- Una medida de esto puede ser el grado en que la historia supone "el mínimo código necesario para aportar el mínimo valor posible". Siguiendo este principio, el tiempo que permanece inestable el codebase es menor y las integraciones serán más fáciles.
Formación en Scrum
En Scrum, el responsable de gestionar el Product Backlog es el Product Owner.
Cómo desempeñar el rol para maximizar el valor del software desarrollado para la organización.
¿En cuantas iteraciones debe poder implementarse una historia?
Tal como lo establece la literatura y la opinión de la gran mayoría de la comunidad, una historia de usuario debe poder diseñarse, desarrollarse, probarse e implementarse en una sola iteración. Si toma más tiempo, entonces debería revisarse si no debería dividirse.
Las historias de usuario deben ser pequeñas
Si esto se cumple, las historias de usuario:
- Pueden estimarse sin realizar mucho esfuerzo, pudiendo estimarse todas las historias dentro de una única sesión de planificación de la iteración (Sprint). Si las historias no son lo suficientemente específicas, entonces la sesión de estimación tomará varios días.
- Pueden desarrollarse, probarse e implementarse dentro de una sola iteración.
- Como medida general, se puede tomar como 4 el máximo número de criterios de aceptación que puede tener una historia, aunque la decisión final se debe tomar revisando caso por caso.
Los criterios de aceptación
Las historias de usuario deben ser comprobables, y esto equivale a decir que los criterios de aceptación deben estar definidos.
Los criterios de aceptación permiten:
- Obtener mayores detalles sobre la verdadera complejidad de la historia para decidir si es muy grande o muy pequeña.
- Definir qué condiciones deben cumplirse para marcarla como “Cerrada” o “Hecho” (Done).
- Facilitan el trabajo en la fase de planificación de la iteración para definir bajo qué condiciones se considerará una tarea “hecha” (Done) y como se probará.
Valoración y estimación de historias de usuario
- La valoración de esfuerzo de las historias de usuario debe corresponder con su dificultad.
- Para ello, deben darse las conversaciones entre Product Owner y equipo de desarrollo, quienes colaboran para determinar si la historia es suficientemente pequeña y tiene bien definidos sus criterios de aceptación.
- El equipo de trabajo es quien realiza las estimaciones, asesorados por el Scrum Master (si estamos trabajando con Scrum), en presencia del dueño del producto y otros involucrados de las áreas del negocio (usuarios). Este último no puede intervenir en la estimación, sólo aportar más detalles si el equipo se lo solicita.
- Si en la primera iteración no se tiene suficiente conocimiento o experiencia, se estima lo mejor que se pueda y en las siguientes iteraciones se pueden ir refinando las estimaciones. El método permite ir ajustando y corrigiendo en el tiempo.
- Estos ajustes deben hacerse después de finalizar la iteración, nunca durante la misma. Las tareas asignadas a la iteración que no lograron completarse, deben pasar nuevamente al Backlog para ser priorizadas en la siguiente iteración.
- La valoración de la complejidad y estimación de las historias se realiza en términos de esfuerzo, no de tiempo, por ejemplo “puntos de historia”. Los días reales se deciden en la planificación.
- Durante la reunión de planificación de la iteración es cuando las historias de usuario pasan a formar parte de la planificación de la iteración, siendo en este momento cuando el equipo les asigna una valoración y define las tareas necesarias para hacerla.
Lectura recomendada
Proyectos Ágiles con Scrum: Flexibilidad, aprendizaje, innovación y colaboración en contextos complejos
Autor: Martin Alaimo; Martin Salas.
>> Latinoamérica (amazon.com)
>> España (amazon.es)
>> Ver reseña
Kanban: Cambio Evolutivo Exitoso Para su Negocio de Tecnología
Anderson, D; Reinertsen, D; Maeda, M (Traductor).
España (Amazon.es)
Latinoámerica (Amazon.com)
Proyectos Ágiles con Scrum: Flexibilidad, aprendizaje, innovación y colaboración en contextos complejos Autor: Martin Alaimo; Martin Salas.
>> Latinoamérica (amazon.com)
>> España (amazon.es)
>> Ver reseña
Anderson, D; Reinertsen, D; Maeda, M (Traductor).
España (Amazon.es)
Latinoámerica (Amazon.com)
¿Interesado en otros productos y últimas novedades sobre desarrollo ágil?
>> Visita nuestra sección de productos amazon
Recomendaciones para Product Owners
Desde el punto de vista del Product Owner, deben considerarse las siguientes recomendaciones.
Del desarrollo de las historias (durante la iteración)
¿y qué opinas tu?
¿Qué recomendaciones aportarías tu para definir y utilizar las historias de usuario, ¿Consideras que falta alguna recomendación en esta lista?.
Te invitamos a dejarnos comentarios en la Web de La Oficina de Proyectos de Informática (pmoinformatica) (Si lo deseas, puedes firmar tu comentario con la dirección de tu web).
<< Artículo anterior: ¿Qué son las historias de usuario?: 5 errores comunes al escribirlas
¿Buscas más información de metodologías ágiles?Desde el punto de vista del Product Owner, deben considerarse las siguientes recomendaciones.
- Llevar un registro de la persona o área solicitante de cada historia, de esta manera sabrá a quien dirigirse en caso de dudas.
- Registrar la fecha en que la está esperando el solicitante, en métodos ágiles no se trabaja con fechas predefinidas, pero aun así, conocer la expectativa de fecha del solicitante puede ayudar en la priorización, la cual es responsabilidad del Product Owner.
- Es vital que cada historia tenga bien asignada su prioridad.
Del desarrollo de las historias (durante la iteración)
- Si las historias han sido bien definidas en los pasos anteriores, los criterios de aceptación serán fácilmente traducibles a definiciones de “Hecho” (Done), para cada tarea definida en la planificación de la iteración.
- Estos a su vez se convertirán en nuestras pruebas unitarias automatizadas, que son los que de hecho validan si la tarea esta “Hecha” (Donde).
- Cuando se aplican los métodos del marco de trabajo ágil, las pruebas unitarias aportan gran valor, al ser de las más tempranas, y el definir adecuadamente los criterios de aceptación de las historias nos facilita el trabajo de definir las pruebas adecuadas.
¿y qué opinas tu?
¿Qué recomendaciones aportarías tu para definir y utilizar las historias de usuario, ¿Consideras que falta alguna recomendación en esta lista?.
Te invitamos a dejarnos comentarios en la Web de La Oficina de Proyectos de Informática (pmoinformatica) (Si lo deseas, puedes firmar tu comentario con la dirección de tu web).
<< Artículo anterior: ¿Qué son las historias de usuario?: 5 errores comunes al escribirlas
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de metodologías ágiles?, entonces presiona "suscríbete" a continuación.
También puedes seguirnos vía Twitter, Facebook o Linkedin:
Referencia
5 Common Mistakes We Make Writing User Stories
Otros artículos sobre Desarrollo ágil, Scrum y Test Driven Development
5 Common Mistakes We Make Writing User Stories
Otros artículos sobre Desarrollo ágil, Scrum y Test Driven Development
Dentro de las historias de usuario no se debe considerar las iteraciones, por que las iteraciones forman parte de los requisitos de software, es decir, en cuantas iteraciones se presentara el producto de software.
ResponderEliminar