Historias de Usuario vs. Casos de Uso

Fuente: sixservix.com

Escribiendo documentación sobre metodologías ágiles en general y ‘buenas prácticas’ a la hora de crear historias de usuario en particular, me encontré con el estupendo post de Jean Claude Grosjean sobre las diferencias existentes entre un caso de uso y una historia de usuario.

Puede ser muy útil explicar estas diferencias, sobre todo cuando -como es mi caso- intentas convertir al agilismo a una audiencia escéptica. Así que, refiné el artículo original, lo traduje al castellano y, sobre todo, lo tabulé para poder incrustarlo fácilmente en documentación o presentaciones. Aquí tenéis el resultado.

Estructura de una Historia de Usuario Fuente: sixservix.com

• ID: Identificador de la historia de usuario
• TÍTULO: Título descriptivo de la historia de usuario
• DESCRIPCIÓN: Descripción sintetizada de la historia de usuario
• ESTIMACIÓN: Estimación del coste de implementación en unidades de desarrollo (estas unidades representarán el tiempo teórico de desarrollo/hombre que se estipule al comienzo del proyecto)
• PRIORIDAD: Prioridad en la implementación de la historia de usuario respecto al resto de las historias de usuario. A mayor número, mayor prioridad. Otra aproximación a la priorización de tareas se hace a través del método MoSCoW:
  • M – Must, se debe completar este requerimiento para finalizar el proyecto
  • S – Should, se debe completar este proyecto por todos los medios, pero el éxito del proyecto no depende de él.
  • C – Could, se debería completar este requerimiento si su implementación no afecta a la consecución de los objetivos principales del proyecto.
  • W – Would, se puede completar este requerimiento si sobra tiempo de desarrollo (o en futuras versiones del mismo)
• DEPENDENCIAS: Una historia de usuario no debería ser dependiente de otra historia, pero a veces es inevitable. En este apartado se indicarían los IDs de las tareas de las que depende una tarea

El ciclo de vida de la tarjeta se compone de tres fases, conocidas como “Las 3 C” por sus iniciales en inglés (Card, Conversation, Confirmation):

• TARJETA (Card), la creación de la tarjeta en sí, con la estructura definida anteriormente y que sirve para determinar QUÉ se debe hacer y cómo planificarlo.
• CONVERSACION (Conversation), representado por pequeños documentos y anotaciones que sirven para aportar detalles y refinar los datos sobre las características del requerimiento.
• CONFIRMACIÓN (Confirmation), o pruebas de aceptación. Pruebas consensuadas entre el cliente y el desarrollador y que el código debe superar para dar como finalizada la implementación del requerimiento.

(Gracias a Vicenç y Jasosa por el ejemplo incluido en la tarjeta)