El objetivo es convertir las necesidades de negocio del cliente o usuario en historias de usuario lo suficientemente sencillas como para que se puedan transformar posteriormente en tareas de desarrollo para el equipo.
Una historia de usuario describe funcionalidad que será útil para el usuario, o el comprador, de un sistema software. Por definición, las historias de usuario no suelen ni deben tener el nivel de detalle que tiene la especificación de un requisito tradicional. Se recomienda que las historias de usuario se escriban en un espacio reducido, y que el soporte físico, normalmente un post-it o una tarjeta, tenga apenas una frase.
Ron Jeffries comentaba que una historia no es sólo una descripción de una funcionalidad, normalmente en un post-it, una historia de usuario además está formada por tres partes:
Creación de la tarjeta (o post-it). Una descripción escrita con un título asociado que sirve como identificación del requisito. También puede contener la estimación, el valor de negocio que tiene la historia para el usuario, etc.
Conversación. El diálogo llevado a cabo entre el equipo y el cliente para aclarar los detalles y las dudas que puedan surgir sobre la historia de usuario. Esta es la parte más importante de la historia de usuario. En el caso de estar usando post-it, estas aclaraciones (o confirmaciones) se podrían especificar a la vuelta del mismo.
Confirmación. Selección de las pruebas que se realizarán para comprobar que la historia de usuario se ha completado con éxito.
Las historias de usuario, frente a mostrar un “cómo”, sólo dicen el “qué”. Es decir, muestran funcionalidad que será desarrollada, pero no cómo se desarrollará. Por ello, cosas como que “el software se escribirá en C++” no es una buena historia de usuario.
Recomendación Una historia de usuario debería ser pequeña, memorizable, y que pudiera ser desarrollada por un par de programadores en una semana.
Aparte de por su manejabilidad y como herramienta para la interacción con el cliente, las historias de usuario han tomado un gran protagonismo en las metodologías ágiles ya que
- Favorecen la participación del equipo en la toma de decisiones.
- Se crean y evolucionan a medida que el proyecto avanza.
- Son peticiones concretas y pequeñas.
- Contiene la información imprescindible.
- Apoyan la cooperación, colaboración y conversación entre los miembros del equipo.
- Información contenida en la historia de usuario
A continuación vamos a ver las partes más comunes que se suelen encontrar en una historia de usuario. La historia de usuario está compuesta por:
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. Si bien el estilo puede ser libre, la historia de usuario debe responder a tres preguntas: ¿Quién se beneficia? ¿Qué se quiere? y ¿Cuál es el beneficio? Por ello, algunos autores recomiendan redactar las historias de usuario según el formato:
Como (rol) quiero (algo) para poder (beneficio)
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).
VALOR: Es dado por el cliente. El Manifiesto Ágil deja claro que una de nuestras prioridades debe ser entregar software que funciona. Éste, además, maximizará el valor y la satisfacción percibida por el cliente. El valor determinará, junto con el tiempo, el orden con el que las historias de usuario van a ser implementadas.
DEPENDENCIAS: Una historia de usuario no debería ser dependiente de otra historia, pero en ocasiones es necesario mantener la relación. En este apartado se indicarían los IDs de las tareas de las que depende una tarea.
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. También se las suele denominar “criterios de aceptación”.
Las historias de usuario son comúnmente usadas en las metodologías ágiles como Scrum o XP.
Copyright © 2012 Kybele Consulting
31/03/2012 at 8:39 am
A magzine theme could make ur blog nicer:)
[WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.