Historias de usuario-Manual completo
Las historias de usuario son descripciones cortas y simples de un requisito desde el punto de vista del cliente.
La plantilla de una historia sería como la siguiente:
Como <Rol>
Quiero <Objetivo>
Para <Motivo>Las historias antes se escribían en notas o Post-it y se ponían en una pared pero a día de hoy se suelen utilizar herramientas como Jira o Trello para gestionarlas.
Un ejemplo de historia de usuario para el requerimiento de maximizar los ingresos de un hotel y seria:
Como operador hotelero Quiero poder ver en un calendario las habitaciones ocupadas Para poner en Booking las habitaciones libres.Además de las historias de usuario tenemos las Épicas que son historias de usuario demasiado grandes para que un grupo pueda realizarla en un Sprint, por eso se dividen en otras más pequeñas.
Un ejemplo de Épica seria la siguiente:
Como dentista Quiero hacer una copia de seguridad de todos mis pacientes Para recuperar sus datos por si se pierden.Esta épica se podría dividir en un montón de historias de usuario pero 2 podrían ser:
Como dentista Quiero buscar a mis clientes por DNI o pasaporte Para hacer una copia de seguridad de su historial dental.
Como dentista Quiero buscar aquellos pacientes que llevan mas de 5 años sin venir Para no hacer una copia de seguridad de su historia dental.Por último, comentar que para poder especificar mejor o añadir detalles a una historia de usuario se puede hacer de 2 maneras, dividiendolas en otras más pequeñas o utilizando criterios de aceptación.
Criterios de aceptación
Los criterios de aceptación se aplican a las historias de usuario y nos permiten saber cuándo una de ellas está finalizada;,suelen expresarse en forma de lista o como una serie de criterios.
El Product Owner es quien suele crear estos criterios con antelación, dado que es el propietario del producto, el que más sabe de las expectativas del cliente.
Los criterios de aceptación deberían crearse en la reunión de planificación del sprint.
Se hace en esta reunión para que los desarrolladores entiendan las historias de usuario de este Sprint y el objetivo que quiere el cliente con este incremento.
En la reunión de revisión del sprint es donde el product owner comprueba que las historias cumplen con sus respectivos criterios de aceptación.
La plantilla de un criterio de aceptación seria la siguiente:
Dado (Give) un contexto inicial
Cuando (When) se produce un evento
Entonces (Then) se produce un resultado
Una manera de hacer criterios de aceptaciónes es utilizando BDD.
BDD es un enfoque que se centra en el desarrollo de software basándose en escenarios de usuario en donde programadores, técnicos y stakeholders definen los requisitos con el lenguaje Gherkin .
Ejemplo de criterio de aceptación
En la sección de abajo vamos a ver un ejemplo de criterio de aceptación.
Basándose en la historia de usuario de abajo:
Como visitante del sitio Quiero suscribirme al sitio Para poder ver las carreras de Motos GP en vivo y en diferido.
Escenario 1: Suscripción del visitante
Dado unvisitante que ha cargado la página web en su navegador
Cuando el visitante esta registrado, está logeado, está suscrito al streaming y ha guardado una tarjeta de crédito o débito en la web.
Entonces el visitante podrá ver en vivo o en diferido en su cuenta las carreras de Motos GP-1 es el número de escenario
-Suscripción del visitante es el título del criterio
– Un visitante que ha cargado la página web en su navegador es el estado inicial
– El visitante esta registrado, está logeado, está suscrito al streaming y ha guardado una tarjeta de crédito o débito en la web son las condiciones o acciones que desencadenan un proceso
– El visitante podrá ver en vivo o en diferido en su cuenta las carreras de Motos GP es el resultado del proceso.
INVEST. Creación de una buena historia de usuario
Para que una historia de usuario este bien creada debe ser INVEST que es independiente, negociable, aportar valor, estimable, corta y testeable.
La palabra INVEST son las siglas de esas 6 características pero en inglés y voy a explicar cada característica más en detalle.
Independiente
Las historias de usuario deben ser independientes, si 2 o más son dependientes si son pequeñas unifícalas en una sola y si son grandes debes tenerlo en cuenta a la hora de planificar.
Negociable
Deben poder cambiarse cuantas veces sea necesario.
Valorable
Deben aportar valor al cliente y deberían ser independientes a la tecnología solo centrándose en la funcionalidad.
Estimable
Se tiene que poder estimar la historia, si no se puede es porque hay que realizar más reuniones con el cliente para obtener más detalle y poder estimar.
Cortas
Las historias de usuario deben ser lo suficientemente cortas para que puedan ser fáciles de estimar,sea sencillo trabajar con ellas,se puedan realizar de manera independiente,se puedan realizar en un Sprint
Testeables
Las historias de usuario deben poder probarse, la mejor prueba de que una historia de usuario está finalizada es que pase todas las pruebas que se realizaron sobre ella.
Refinamiento de historias de usuario
Para refinar una historia de usuario se tendrían que realizar las siguientes preguntas:
- Usuario=¿Quién va a interactuar con el producto?
- Interfaz =¿Qué interfaz tendrá el producto?
- Acciones =¿Qué acciones se pueden realizar en el producto?
- Datos=¿Qué datos se podrán buscar y guardar en el producto?
- Control =¿Qué control de calidad va tener que pasar?
- Ambiente= ¿En qué contexto se usara el producto?
- Calidad =¿Los tiempos de carga son pequeños, es extensible y usable el producto?
Si utilizamos las siguientes preguntas podemos ver si una Historia de Usuario se puede refinar más:
• ¿Tiene impedimentos?
• ¿Está el DoD definido correctamente?
• ¿Soluciona el problema del Sprint?
• ¿Se estima correctamente?
• ¿Debe ser refinada?
• ¿Se puede probar?
Si da no en lagunas de estas preguntas habrá que refinar más la Historia de usuario.
Un lugar donde se suele utilizar el refinamiento es en las épicas, que como sabemos por su tamaño necesitan más de un Sprint para realizarlas, deben dividirse para aportar valor.
User story mapping
Es una técnica que se utiliza para la creación de un producto o de una nueva funcionalidad de un producto.
El resultado será un diagrama en que todas las historias de usuario están ordenadas en grupos funcionales lo que permite tener un panorama general.
Esta técnica es útil porque permite el descubrimiento del producto y la priorización de las tareas en construcción.
Esta técnica tiene 6 pasos que son los siguientes:
- Definir las siguientes entregas.
- Empezar por épicas o grandes historias.
- Descomponer las épicas en historias de usuario más pequeñas.
- Revisar la completitud del diagrama.
- Ordenar las tareas según su importancia.
- Definir las entregas.
Estimación de historias de usuario
Las técnicas relativas para estimar historias de usuario son estimación por tallas, estimación por Planning Poker y estimación individual.
Estimación individual
La estimación individual la comenté antes, se asignan las tareas a los miembros del equipo y cada miembro les da una estimación a sus tareas en función de su experiencia personal.
Si la hizo otros miembros se basa en la de otros.
Esta técnica es la más utilizada en la vida real o es la que yo vi en varias empresas y se da una estimación en horas.
Estimación por tallas
La estimación por tallas se basa en imaginarse que las tareas son camisetas con 5 tallas: XS S M L XL
XS es la talla más pequeña y XL la más grande.
La estimación se tiene que hacer entre todos los miembros del equipo porque se tiene que coger el conocimiento de todos.
Por ejemplo, supongamos que queremos hacer un desplegable para coger todas las marcas de una tienda virtual para el diseñador eso es una tarea que de esfuerzo seria S pero un programador web tendría que hacer las funciones en el backend comunicar con la base datos hacer consultas y devolver la información en JSON por ejemplo y para él sería bastante esfuerzo y podría decir que es una talla L con lo que la estimación final podía ser una M si hiciéramos la media.
Por todo esto es tan importante que la estimación se haga entre todos los miembros del equipo.
Estimación planning poker
La estimación por Planning Poker se basa en suponer que tenemos unas cartas con los números de Fibonacci
1,2,3,5,8 y 13
En el equipo cada uno cogería una carta con un valor para poner el esfuerzo de una tarea.
Si el miembro tiene mucha experiencia la tarea le daría un esfuerzo bajo y si tiene poca experiencia un valor alto.
Así que cada uno de los miembros del equipo le daría un esfuerzo a esa tarea y la media sería el esfuerzo o coste de la tarea.
Media=Suma de valores de carta Dividido por Número de cartas
La media sería el esfuerzo o coste de esa tarea si el esfuerzo da con números decímales como por ejemplo 5.4 se elige 5 y si es 5.6 se elige 6.
Si te ha gustado comparte mi articulo y suscribete a mi newsletter.
Soy Alejandro Canosa escritor de libros de QA, consultor de pruebas, apasionado del marketing digital y Wordpress.
Deja una respuesta