10
Feb
Estructura de una Historia de Usuario
- 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)
Artículos relacionados:
- Historias de Usuario vs. Casos de Uso Escribiendo documentación sobre metodologías ágiles en general y ‘buenas prácticas’...
6 respuestas a “Estructura de una Historia de Usuario”
En lo referente a las prioridades yo encuentro más recomendable el uso de valores numéricos dado que para un cliente buena parte de las funcionalidades serán etiquetadas como must.
Una cuestión, David.
Viendo el ejemplo me pregunto si realmente esa es una buena historia de usuario. Más que nada por la descripción. En tu anterior artículo el objetivo de la historia de usuario lo veíamos como una descripción breve de una funcionalidad "tal y como la percibe el usuario". Es una buena definición, así que quedémonos con ella. Entonces, leamos:
"Cómo cliente quiero que los socios puedan pedir prestado un libro, indicando su número de socio y la referencia del libro, siempre y cuando no tengan ya tres libros en préstamo en ese momento."
y pensemos un poco. Esto debería ser "tal y como lo percibe el usuario", de modo que un paso fundamental es ¿quién es el usuario en esta historia? Leyendo tenemos un cliente y unos socios. De hecho dice que: *yo*-cliente quiero que *los socios* puedan… ¿Quién soy "yo, el cliente"? ¿Qué pinto ahí si son los socios los que cogen los libros? ¿Es mi historia o es la suya?
Claramente la historia debería ser algo como "Un socio puede pedir prestado un libro, indicando…". Así queda claro que el usuario de esta historia es el socio, y que es su historia como la percibe él. Al menos esto sería así si estamos pensando en que el socio interacciona con el sistema. Si hay un bibliotecario que es quien maneja el ordenador, entonces la historia sería "El bibliotecario puede solicitar un libro para un socio, indicando…" pero de cualquier forma debería estar más claro quién es el usuario de la historia.
Por otra parte, tampoco tengo del todo claro que la parte de la limitación a 3 libros esté bien definida… Por un lado, me pregunto si no deberíamos decir "el número máximo" en lugar de "3", y por otro me pregunto si realmente esto forma parte de la historia. No termino de tenerlo del todo claro, eh, no digo que no deba estar, sino que mmm… no estoy del todo seguro.
¡Madre mía! ¡menudo análisis exhaustivo del post! Muchas, muchas gracias por el tiempo dedicado.
Como ya he indicado, la historia de usuario que hay dentro de la tarjeta la he cogido prestada de aquí: http://bit.ly/cXWkPB .
Aunque es posible tener varias interpretaciones de todos los conceptos, no puedo estar de acuerdo con tu apreciación sobre los clientes. Para mi, el Cliente o Producto Owner es el que te encarga el producto, el que paga… y en el caso de la historia de usuario de la tarjeta, el cliente es el tipo que te encarga un sistema de gestión de bibliotecas.
Un saludo,
David
Mmm… Bien, bien, el cliente es el cliente. Eso está claro.
Pero aún así, no estoy de acuerdo con que esa sea una "historia de *usuario*". Quiero decir, o bien el usuario es el bibliotecario ("Como bibliotecario quiero poder solicitar un libro para un socio…") o bien el usuario es el socio ("Como socio quiero poder solicitar un libro…"). En mi modesta opinión, una historia de usuario no debe ser "Como usuario-tipo-x, quiero que el usuario-tipo-y pueda hacer esto y lo otro" porque entonces no está claro quién es el usuario de la historia ni cuál es su acción. En este caso "como cliente" qué acción realiza para conseguir que el socio pida un libro? No tiene sentido.
Una historia de usuario se "vive" en primera persona "Como usuario-tipo-x quiero hacer-esto para conseguir-esto" (y el para qué también es importante).
Yo creo que no es que no tengais razón alguno, si no que depende del punto de vista de como entiendas las "historias de usuario". Siguiendo el nombre y la definición literal, el "usuario" de la aplicación de esa historia no es el cliente, es el socio. Sin embargo, si la "historia del usuario" la entendemos como un requerimiento que ha de satisfacer la aplicación, entonces está claro que el que nos pide y explica el requerimiento es el cliente, no el socio.
Así que todo depende de como entiendes las "historias de usuario", si como lo que se pide que haga la aplicación o como, literalmente, lo que hará un usuario en el sistema (lo pida el, su jefe o Santa Rita)
Bueno, es que yo no controlo mucho de agilismo y tal, pero vamos, creía que eso era una cosa de las más básicas y claras que a lo que se refiere es a la historia *del usuario*. Que no sé, eh, que me puedo equivocar, pero hasta donde yo entiendo parece bastante claro que el protagonista de la historia de usuario debe ser el usuario.
Más aún, tenía yo la impresión (y corregidme si no es así) que las historias de usuario quienes las explican son los usuarios. (Que luego puedan ser sustituidos por consultores/personajes/whatever, pues bueno, pero quien la cuenta debe hacerlo desde el punto de vista de la acción que hace como usuario.
Deja un comentario