Como realizar Historias de Usuario
¿Qué son las historias de usuario?
Las Historias de Usuario son una forma de representar los requisitos del proyecto. Estas son redactadas en frases cortas con un lenguaje entendible por el usuario. A las historias de usuario también se las conoce como User Storiesy y actualmente son un estándar usado en proyectos ágiles al momento de definir requisitos. Sin embargo aunque son muy populares y usadas en Scrum es importante recalcar que no son elementos estándar de la Guía Scrum.
Una vez que conocemos que son las historias de usuario. Revisemos cono se construyen y para eso tenemos que tomar en cuenta que una historia de usuario consta de 3 piezas clave que son:
- La Carta
- La Confirmación
- La Conversación
Componentes de una Historia de Usuario
- La Carta: La carta básicamente es un pequeño resumen de la historia de usuario que se desarrolla en conjunto con el equipo. Aquí establecemos 3 elementos principales que son: Para quien o quien usara lo que vamos a crear, que es lo que esta persona quiere y finalmente para qué sirve. En la imagen tenemos un ejemplo de carta con estas partes principales.
- La Conversación: Es una Reunión en la cual conversamos con el equipo y el dueño del producto o el cliente para definir la historia de usuario. Este paso es fundamental, ya que el equipo en conjunto el dueño del producto nos ayudaran a esclarecer los requisitos y las historias que tendremos en el proyecto
- La Confirmación: La confirmación: Aquí se describe los criterios de aceptación se establece que condiciones deben cumplirse para dar por terminada la historia.
Consideremos la primera película en donde aparece la estrella de la muerte y lo que buscan los rebeldes es destruir esta arma del enemigo. De esta forma este proyecto genera valor al destruir a la estrella de la muerte y derrotar al imperio.
Ejemplo de Historia de Usuario
Para esto el Product Owner o dueño del producto debe conocer que cosas se necesitan para cumplir con el objetivo del proyecto que es destruir una arma del enemigo. Cada entregable del proyecto o cada funcionalidad que se desarrolle será una historia de usuario y busca resolver algún problema o necesidad.
De esta manera el PO crea las historias de usuario en conjunto con el equipo y los interesados principales. Esta Reunión es muy impórtate y es conocida como conversación. En nuestro ejemplo el PO usará esta Reunión para encontrar como pueden destruir a la estrella de la muerte. Como resultado de esta Reunión tendremos la carta y la confirmación de cada historia de usuario que el proyecto posea.
- Carta
Como: líder del escuadrón de asalto
Quiero: Conocer las vulnerabilidades del arma del enemigo
Para: Organizar un ataque efectivo que destruya la estrella de la muerte
Una vez definida la Carta se debe establecer la confirmación. Esto lo podemos realizar durante la Reunión de conversación en donde vamos definiendo cuáles son los criterios de aceptación. Al realizar esta conversación y escuchar los diferentes argumentos de los participantes se puede establecer estos criterios. En nuestro caso podemos decir que la misión sería un éxito si cumplimos con los siguientes criterios. Recuerda que el equipo y los participantes ayudan a definir estos criterios de aceptación.
- Criterio de aceptación
- Tener los planos del arma
- Definir las vulnerabilidades del arma
- Destruir la estrella de la muerte
Toma en cuenta el INVEST para realizar una historia de usuario
Una historia de usuario es desarrollada por el Product Owner y es su responsabilidad que las historias estén correctas y que aporten valor al cliente o la organización. Para comprobar justamente esto existe una herramienta conocida como INVEST la cual permite revisar los aspectos principales de una historia de usuario.
- Independiente: En primer lugar la historia debe ser independiente. Como vemos nuestra historia no depende de otras historias o poder ser completada.
- Negociable: Una historia es negociable y puede variar. Como esta historia ha sido negociada con los miembros del equipo y el cliente en la conversación. Cumplimos con este punto
- Valiosa: Una historia de usuario no dependa de otra para generar valor. Esta historia genera valor por si sola.
- Estimado: Que el equipo pueda decir cuál es la dificultad de la historia comparada con otras. En nuestro caso la historia esta lo suficientemente clara como para poder establecer los puntos de historia que tendrá. Recuerda que los puntos de historia se deben definir al comparar con la historia más pequeña.
- Small/Pequeña: La historia de usuario debe ser realizada en un sprint. En nuestro caso si es posible realizar esta historia en un sprint
- Testeable: Podemos probar si la historia cumple al tener definidos nuestros criterios de aceptación
Y de esta manera tenemos completa nuestra historia de usuario.
Gracias por éste artículo. Podrías agregar algunos otros ejemplos relacionados con el Desarrollo de Software o la Construcción. Aclaro, no estoy en contra de los ejemplos de Star Wars, a nivel didáctico son muy buenos, pero siempre me gusta afianzar el conocimiento con ejemplos reales. Saludos.
Hola, Eric
Gracias por el feedback. El ejemplo que se plantea es más enfocado al tema educativo. Pero es una buena idea y voy a colocar un ejemplo enfocado a la construcción , en el futuro