Continuando con el post de historias de usuario , este es el 3 y ultimo apartado , donde se describe el formato y algunos tips para redactarlas bien.
Formato
El formato habitual para redactar historias de usuario es el siguiente :
I as [Role] want [function] so that [business value]
Como: <Actor >
Deseo: <Necesidad>
Para: <Valor de negocio>
Criterios de Aceptación (Test de Aceptación)
1Las pruebas de aceptación es el proceso de verificar que las historias se desarrollaron exactamente igual como el equipo cliente espera que funcione.
Si se desea ir mas allá para generar escenarios de prueba para complementar la información a desarrollo y calidad , aplicando el inicio de B.D.D por parte de negocio.
Escenarios de prueba
Given , when ,then (Pasado , Presente , futuro)
Dado que: <Un Contexto (Entrada)>
Cuando: <se produce un evento>
Entonces: <resultado esperado (Salida)>
Release Plan
Es importante determinar cuándo será lanzado nuestras funcionalidades generando un mínimo producto viable que genere el mayor retorno de la inversión permitiendo generar un producto con crecimiento organico de forma iterativa e incrementental
Cuando tenemos las historias de usuario defiidas , el product owner debe determinar cuales de esas historias van a salir en el lanzamiento en determinado números de sprint.
Una técnica utilizada es la de MoSCoW 2 Del acrónimo de 3:
- Must have to : Requisito que tiene que estar implementado en la versión final del producto para que la misma pueda ser considerada un éxito
- Should have to : Requisito de alta prioridad que en la medida de lo posible debería ser incluido en la solución final, pero que llegado el momento y si fuera necesario, podría ser prescindible si hubiera alguna causa que lo justificara.
- Could have to : Requisito deseable pero no necesario, se implementaría si hubiera posibilidades presupuestarias y temporales.
- Won’t have this time : Hace referencia a requisitos que están descartados de momento pero que en un futuro podrían ser tenidos de nuevo en cuenta y ser reclasificados en una de las categorías anteriores.
Ya que permite identificar cuales requisitos generan mas valor al sistema.
Consejos
–Cuando una historia de usuario es grande, es necesario dividirla en varios, generando que la historia principal sea comúnmente llamada EPIC.
-Cada historia debe ser escrita en lenguaje de negocio.
-Los desarrolladores estiman cada historia
-Cada historia se le asigna un estimado de puntos de historia . que indica el tamaño del esfuerzo relativo a las demás historias.
-Redactar las historias en voz Activa
-Mantener la interfaz de usuario lo más lejos posibles al redactar las historias de usuario.
-Escribir las historias por roles individuales, por ejemplo “Un buscador de finca raíz puede eliminar descripción”, es mejor “Un buscador de finca raíz puede eliminar sus descripciones”.
-Evitar utilizar números como identificadores, es recomendado utilizar el titulo abreviado para tener un mejor contexto del id de la historia.
-La historia de usuario debe probar partes o funcionalidades en concreto , no todo el sistema
-Usar etiquetas en los escenario , para clarificar el contexto , como por ejemplo si es lento o pesado el escenario , si es necesario configurar el ambiente ,dependencias externas , y otras mas.
– El product owner no puede estimar (Gerencia de Proyecto) sin información del equipo de desarrollo , ya que necesita saber el esfuerzo que representaría las historias de usuario.
Para finalizar comparto un template en hoja de calculo para facilitar el manejo de las historias de usuario.
DESCARGAR TEMPLATE HISTORIAS DE USUARIO HOJA DE CALCULO
Referencias
- User Stories Applied: For Agile Software Development (Cohn, Mike 2004)
- For information on DSDM see DSDM: Business Focused Development (Stapleton 2003)
- https://jummp.wordpress.com/2013/04/27/metodo-moscow/
