Ejemplos y buenas prácticas para descomponer historias de usuario en tareas (parte 1 de 2)

Aun incluso después de leer el User Stories Applied de Cohen, parece que el tema de cómo, en un proyecto ágil, descomponer historias de usuario en tareas (te recomiendo aquí este post sobre historias de usuario) para muchos no queda del todo claro. Y este es uno de esos problemas que siempre salen cuando llega el momento de trabajar con historias de usuario: la descomposición en tareas.
Para aclarar este tema, en el libro sobre gestión ágil de proyectos que estamos escribiendo, introducimos un conjunto de ejemplos y buenas prácticas que se recomiendan aplicar a la hora de descomponer historias de usuario en tareas. Afortunadamente, aparte de nuestra experiencia, también hemos podido contar con algunos buenos textos que tratan este tema (por ejemplo este y este).
Os dejo, en esta serie de dos post (la parte 2 la publicaré el lunes), primero un extracto de ejemplos y luego unas buenas prácticas para descomponer historias de usuario en tareas.

Ejemplos que te pueden ayudar a descomponer historias de usuario en tareas:

  • Diseño de la historia de usuario: especialmente para generar discusión sobre cómo se va a implementar la historia de usuario.
  • Implementación de una historia: esta tarea puede incluir la definición de las interfaces y los métodos necesarios para cubrir la necesidad expresada en la historia. Pueden existir múltiples tareas de este tipo.
  • Pruebas unitarias asociadas a la historia (TDD): esta tarea debiera ser obligatoria para cada historia.
  • Pruebas de aceptación asociadas a la historia: tarea definida para desarrollar las pruebas de aceptación automáticas que facilitarán la validación de la historia por parte del cliente y/o usuario.
  • Requisitos no funcionales: para cada historia, se deben tener en cuenta requisitos de seguridad, rendimiento, escalabilidad, etc. Estos atributos de calidad pueden dar lugar a nuevas tareas.
  • Revisiones de código: el código siempre debe haber sido revisado, convirtiéndose la revisión en otra tarea.
  • Refactorización del código (te recomiendo aquí leer este post sobre qué es la refactorización): Esta tarea se debe incluir para cada historia con el fin de evitar una complejidad excesiva del código.
  • Emular interfaces: en el caso de que se demore en exceso la implementación de una interfaz, éstas se deben emular con el fin de comenzar a trabajar.
  • Pruebas exploratorias: pruebas ad-hoc para una historia.
  • Corrección de errores: dependiendo de la historia, se debe reservar tiempo para la resolución de errores o incidencias.
  • Verificación de errores: dependiendo de la historia, se debe reservar tiempo para verificar la corrección de los errores.
  • Demo: demostración interna al equipo de la historia. Esta pequeña demostración se suele realizar una vez finalizada la historia en la reunión diaria.
  • Actualizar la wiki o el repositorio de documentos: con el diseño y los resultados de la historia.
  • Documentación de usuario final: la generación de los manuales de usuario, instalación, etc. también debe estar ubicada en alguna tarea.

Hay que tener en cuenta que el anterior es solamente un listado de ejemplo, y que  dependiendo de la historia de usuario habrá elementos de esta lista que pueden aplicar o no. A su vez, en los proyectos ágiles pueden surgir otros tipos de tareas que no se encuadren en esta lista y que sean igualmente válidos.
¿Alguien tiene algún ejemplo más, o recomendación, sobre descomponer historias de usuario en tareas?

0 comentarios en “Ejemplos y buenas prácticas para descomponer historias de usuario en tareas (parte 1 de 2)”

  1. Pingback: Bitacoras.com

  2. Pingback: Resumen semanal – del 7 al 13 de Mayo - Javier Garzás, sobre calidad software y otros temas relacionados

  3. Pingback: Historia de Usuario | Business World TI

  4. Muchas gracias, muy clara y precisa la información. En mi equipo suele existir una tarea de paso a hardenning que consiste en preparar los entregables (svn, fuentes, documento de catalogación) para la liberación en los distintos ambientes (desarrollo, testing, producción).

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba