Requisitos ágiles
User stories que se pueden hacer, probar y estimar
El backlog es el corazón del proyecto: si las historias están bien escritas, planificar, estimar y demostrar que avanzáis es fácil. Aquí tenéis el formato, ejemplos buenos y malos, y un par de juegos para practicar.
El formato
Cada historia dice quién quiere qué y por qué. El "por qué" no es decoración: es lo que permite priorizar y decidir cuándo la historia aporta valor.
Podéis escribirlas en catalán, castellano o inglés, pero siempre con la misma plantilla. Las historias se agrupan en épicas, se descomponen en tareas y se miden con story points.
Como ciclista, quiero ver las estaciones con bicis libres cerca de mí de manera que no tenga que caminar en vano.
Com a ciclista, vull veure les estacions amb bicis lliures a prop meu de manera que no hagi de caminar en va.
As a cyclist, I want to see stations with free bikes near me so that I do not walk for nothing.
Toca cada letra
INVEST: las seis preguntas de control
Antes y después
Cinco historias reescritas
Ejemplos de una app de movilidad que usa los datos abiertos del Bicing.
Hacer el endpoint /estaciones con Express.
Es una tarea técnica: no dice quién la quiere ni para qué.Como ciclista, quiero ver las estaciones con bicis libres cerca de mí de manera que no tenga que caminar en vano.
El endpoint será una de las tareas de esta historia.Como usuario, quiero una red social de ciclistas.
Demasiado grande: es una épica, no una historia.Como ciclista, quiero seguir a otros ciclistas de manera que vea sus rutas en mi feed.
Una pieza concreta de la épica "Comunidad".La app tiene que ser rápida.
RNF imposible de comprobar.Criterio: el 95 % de las peticiones que no son búsquedas responden en menos de 1 segundo.
Medible, y se comprueba en las historias donde aplica.Como usuario, quiero un botón verde arriba a la derecha.
Impone la solución y no dice para qué sirve.Como usuario, quiero reservar una bici desde el mapa de manera que la tenga garantizada cuando llegue.
El diseño del botón se decide en las maquetas.Como usuario, quiero iniciar sesión.
Sin beneficio ni criterios: ¿cuándo está hecha?Como usuario, quiero iniciar sesión con Google de manera que no tenga que recordar una contraseña nueva.
Criterios: entra con una cuenta válida, muestra un error claro si cancela, la sesión dura 30 días.Criterios de aceptación
Añaden el detalle que le falta a la historia y dicen exactamente cuándo está cumplida. Se validan con pruebas de aceptación, idealmente automatizadas. Escribidlos en Taiga, dentro de cada historia.
Un formato que funciona muy bien es Dado / Cuando / Entonces (Given / When / Then): contexto, acción y resultado esperado.
En el Fag-2 ya se piden los criterios más importantes de cada historia del backlog, aunque no estén muy detallados.
Dado que estoy a 300 m de dos estaciones y solo una tiene bicis libres Cuando abro el mapa Entonces veo las dos estaciones y la que tiene bicis aparece destacada con el número de bicis disponibles
Dado que no tengo conexión Cuando abro el mapa Entonces veo los datos de la última carga con la hora de actualización
Requisitos no funcionales (RNF)
- Si afectan a todo el sistema (rendimiento, seguridad, idiomas), cread una historia propia e identificad tantos criterios de aceptación como podáis. Después se comprueban en cada historia donde aplican.
- Si son locales (privacidad en el login, por ejemplo), ponedlos directamente como criterio de aceptación de la historia.
- En ambos casos: medibles y realistas. "Rápido" no; "menos de 1 segundo el 95 % de las veces" sí.
- Dejad claro dónde viven en Taiga: es uno de los aspectos metodológicos que se valoran.
Story points y planning poker
Los puntos son una medida abstracta de complejidad, no de horas. Usad una escala como 1-2-3-5-8-13 y estimad cada historia por analogía (se parece a otra), juicio experto o desagregación (la partís mentalmente).
El planning poker combina las tres: todo el mundo vota a la vez; si hay mucha dispersión, quien ha votado más alto y más bajo lo explican y se vuelve a votar. Probadlo aquí con el equipo simulado:
Cuándo dividir una historia
- Si aún es demasiado grande para un sprint, o si cabría pero no queda espacio.
- Divididla por datos (primero estaciones, después carriles bici), por funcionalidad (ver, filtrar, reservar), sacando aspectos transversales (multiidioma aparte) o por prioridad.
Cómo priorizar
Valor económico, coste de desarrollo, conocimiento nuevo que aporta (del producto y del proyecto) y riesgo que elimina.
Practica