Dividir una historia grande
En resumen: Una historia grande se corta en vertical: cada trozo atraviesa todo lo que necesita y da algo que alguien puede probar. Los patrones indican por dónde cortar: por pasos, reglas, datos, complejidad, calidad u operaciones. Una capa (frontend, backend, base de datos) no es una historia.
Problema
Tres semanas y nada que enseñar
La historia es «Como cliente quiero devolver un producto y recuperar mi dinero». Es grande, así que el equipo la reparte: una persona construye la pantalla de devoluciones, otra los registros de la base de datos, una tercera el reembolso.
A las dos semanas la pantalla está lista, pero no hace nada. La base de datos está lista, pero nadie puede verla. El dueño pregunta «¿puedo ver una devolución?» y la respuesta es «todavía no». En la tercera semana todo se conecta, y es entonces cuando QA descubre que los 14 días se cuentan desde el pedido, no desde la recepción de la mercancía.
Los trozos eran pequeños. Pero ninguno se podía probar por sí solo.
La idea
En vertical, no por capas
Piensa en la historia como una tarta de capas: pantalla, procesamiento, base de datos. Dividir por capas corta la tarta en horizontal. Te queda una capa entera de nata, y nadie puede comerla como tarta.
Una buena división corta en vertical: cada trozo tiene tanto de cada capa como necesita y da algo que alguien puede probar. En las devoluciones, el primer trozo vertical es «el cliente solicita una devolución dentro de los 14 días desde que recibió la mercancía». Es pequeño. Pero el dueño lo ve la primera semana, y QA puede comprobar enseguida el límite de los 14 días.
Esto se llama dividir historias (story splitting): una historia grande se corta en otras más pequeñas, cada una de las cuales sigue siendo una historia según INVEST.
Más precisamente, para curiosos
La metáfora de la tarta es antigua: Bill Wake ya la usa en su artículo sobre INVEST. Un trozo así se llama corte vertical (vertical slice), y a dividir también se le llama cortar en rebanadas (slicing).
La idea
Por dónde cortar
No hay un único corte correcto, pero hay patrones que aparecen una y otra vez. Aquí van seis, con la tienda:
| Patrón | Cuándo encaja | En la tienda |
|---|---|---|
| Por pasos del flujo de trabajo | la historia es un proceso con varios pasos | devoluciones: solicitud, paquete de vuelta, almacén, dinero |
| Por reglas de negocio | una acción, muchas reglas | el importe final: envío, código promocional, fidelidad, cuál se aplica |
| Por variaciones de los datos | el mismo camino, datos distintos | un producto con una talla, después con talla y color |
| El caso principal primero | hay un caso principal y muchas complicaciones | búsqueda por nombre, después filtros y sugerencias |
| Primero que funcione, después la calidad | un requisito de velocidad o de carga | el pago, después el pago con 2000 clientes a la vez |
| Por operaciones | «gestionar» esconde varias acciones | códigos promocionales: crear, ver, cambiar, detener |
La primera pregunta es: ¿por qué es grande la historia? ¿Por los pasos, las reglas, los datos? La respuesta sugiere el patrón.
Más precisamente, para curiosos
Los patrones de aquí siguen la lista que más se cita en la práctica: «Patterns for Splitting User Stories» (2009) de Richard Lawrence. Otro conjunto muy conocido es el SPIDR de Mike Cohn: Spike, Paths, Interfaces, Data, Rules.
Al último patrón se le llama a menudo CRUD, de create, read, update, delete. En la tienda «eliminar» se convierte en «detener», y verás por qué en el ejercicio.
Pruébalo
¿Qué patrón?
Pruébalo
Divide la devolución
Elige el patrón y después los trozos de la división en el orden en que se construyen.
Como cliente quiero devolver un producto que no me gusta y recuperar mi dinero.
Paso 2: ¿Qué piezas y en qué orden?
Añade las piezas que forman la división y ordénalas: la primera se hace primero.
Las piezas
La división
Patrón
- Por pasos del flujo de trabajo: Una devolución pasa por varios pasos: la solicitud, el envío del paquete de vuelta, la recepción en el almacén, el dinero. Cada uno se puede construir y enseñar al dueño por separado.
La división de ejemplo
- El cliente solicita la devolución de un pedido entregado dentro de 14 días desde que lo recibió
- El cliente recibe instrucciones para enviar el producto de vuelta
- El almacén recibe el paquete y el pedido pasa a devuelto
- La tienda reembolsa al cliente
Una devolución es grande por los pasos, no por las reglas. Cada paso es una historia: después del primero el cliente ya puede solicitar una devolución, y el dueño ve cuánta gente lo hace. La pantalla y la base de datos no son trozos; son partes de cada trozo.
La idea
Por qué no por capas
Dividir por capas parece sensato, porque así está organizado el equipo: una persona construye pantallas, otra el procesamiento. Pero sale muy caro:
- Nadie puede probarlo. El dueño ve algo solo cuando todas las capas están listas. Si la historia está mal, lo descubre el último.
- No se puede comprobar. Los criterios de la historia («dentro de los 14 días desde la recepción de la mercancía») tratan del comportamiento, no de una pantalla ni de una base de datos. QA espera hasta el final.
- El riesgo está al final. Las capas se encuentran al final, y es ahí donde salen los desajustes.
- No es valiosa según INVEST. Ningún trozo aporta nada a nadie fuera del equipo.
Las capas son tareas dentro de la historia. Las construyen los programadores, pero la historia se da por terminada cuando funciona todo el trozo vertical.
La idea
Cómo saber que una división es buena
- Cada trozo es una historia. Tiene un rol, un objetivo y un beneficio, y pasa INVEST.
- El primer trozo aporta más. El mayor valor o el mayor aprendizaje. Si el primer trozo es «preparación», estás cortando mal.
- Los trozos no se solapan. Ninguno está dentro de otro.
- Juntos cubren la historia grande. O al menos lo que de ella hace falta de verdad.
El último punto importa. A menudo, después de unos pocos trozos el dueño dice «con eso basta». Los trozos que quedan no se construyen nunca, y eso no es un fracaso. Es la división haciendo su trabajo.
Ejercicio
Divide las historias
1. El importe final. La historia sobre el importe antes de pagar.
Elige el patrón y después los trozos de la división en el orden en que se construyen.
Como cliente quiero ver el importe final con el envío y los descuentos antes de pagar, para saber cuánto voy a pagar.
Paso 2: ¿Qué piezas y en qué orden?
Añade las piezas que forman la división y ordénalas: la primera se hace primero.
Las piezas
La división
Patrón
- Por reglas de negocio: El importe total es uno, pero las reglas son varias: el envío, el código promocional, la fidelidad y cuál se aplica cuando hay dos. Cada regla se puede construir, mostrar y comprobar por separado.
La división de ejemplo
- El importe con el envío: gratis desde 50,00 €, y en otro caso 4,90 €
- El importe con un código promocional: 10 %, no en los productos rebajados
- El importe para un cliente fiel: 5 %
- Código promocional y fidelidad juntos: se aplica el descuento mayor
Cada regla es una historia que se puede comprobar por sí sola: «un carrito de 50,00 €, el envío es gratis». La regla «se aplica el mayor» va la última, porque tiene sentido cuando ya existen los dos descuentos. Los otros tres pueden ir en cualquier orden.
2. Los códigos promocionales. La historia de marketing.
Elige el patrón y después los trozos de la división en el orden en que se construyen.
Como empleado de marketing quiero gestionar los códigos promocionales para poder iniciar y detener campañas sin un programador.
Paso 2: ¿Qué piezas y en qué orden?
Añade las piezas que forman la división y ordénalas: la primera se hace primero.
Las piezas
La división
Patrón
- Por operaciones: crear, ver, cambiar, detener: «Gestionar» esconde varias acciones separadas. Cada una es una historia que el empleado puede probar por sí solo.
La división de ejemplo
- El empleado crea un código promocional nuevo con un periodo de vigencia
- El empleado ve los códigos y cuántas veces se ha usado cada uno
- El empleado detiene un código antes de que termine su periodo
- El empleado cambia el periodo de vigencia de un código
Crear va primero, porque sin un código no hay nada que ver, cambiar o detener. El «eliminar» de CRUD se convierte aquí en «detener»: un código usado tiene que quedarse, porque contabilidad concilia los descuentos por código. La necesidad de una parte interesada cambió el patrón.
Test