Historias De Usuario

Historia de usuario

Descripción de una funcionalidad que debe incorporar un sistema de software, y cuya implementación aporta valor al cliente.

La estructura de una historia de usuario está formada por:

Nombre breve y descriptivo.

Descripción de la funcionalidad en forma de diálogo o monólogo del usuario describiendo la funcionalidad que desea realizar.

Criterio de validación y verificación que determinará para considerar terminado y aceptable por el cliente el desarrollo de la funcionalidad descrita.

Y adicionalmente por la información que resulte necesaria por el modelo de implementación: Prioridad, Riesgo, Tamaño, etc.

Estructura:

• ID – un identificador único, simplemente un número auto-incremental. Esto nos permite no perder la pista a las historias cuando cambiamos su nombre.

• Nombre – una descripción corta de la historia. Por ejemplo, “Ver tu historial de transacciones”. Suficientemente claro como para que el Dueño de Producto comprenda aproximadamente de qué estamos

hablando, y suficientemente clara como para distinguirla de las otras historias. Normalmente, 2 a 10 palabras.

• Importancia – el ratio de importancia que el Dueño de Producto da a esta historia. Por ejemplo, 10. O 150. Más alto = más importante. Suelo evitar el término “prioridad” porque típicamente “1” se considera la

“máxima prioridad, lo que es muy incómodo si posteriormente decides que algo es más importante. ¿Qué prioridad le daríamos a ese nuevo elemento? ¿Prioridad 0? ¿Prioridad -1?

• Estimación inicial – la valoración inicial del Equipo acerca de cuanto trabajo es necesario para implementar la historia, comparada con otras historias. La unidad son “puntos de historia” y usualmente corresponde a “días-persona ideales”. Pregunta al Equipo: “si tuvierais el número óptimo de personas para esta historia (ni muchos ni pocos, típicamente 2) y os encerraseis en una habitación con cantidad de comida, y trabajaseis sin distracciones, ¿en cuantos días saldríais con una implementación terminada, demostrable, testeada y liberable?”. Si la respuesta es “con 3 tíos encerrados en una habitación nos llevaría 4 días”, entonces la estimación inicial son 12 puntos. Lo importante no es que las estimaciones absolutas sean correctas (es decir, que una historia de 2 puntos deba durar 2 días), lo importante es que las estimaciones relativas sean correctas (es decir, que una historia de 2 puntos debería durar la mitad que una historia de 4 puntos).

• Como probarlo – una descripción a alto nivel de como se demostrará esta historia en la Demo al final del Sprint. Se trata, esencialmente, de una simple especificación de un test: “Haz esto, entonces haz lo otro, entonces debería ocurrir aquello”. Si practicáis TDD (Test-Driven Development, desarrollo orientado a test)

...