Este es mi resumen de la parte de Scrum (sin incluir XP) del libro «Scrum y XP desde las trincheras» de Henrik Kniberg. No es la biblia ni debe ser una referencia, pero sí que puede ayudar a refrescar algún concepto o a empezar con Scrum.
Scrum = marco de trabajo
1- Pilas de producto
Lista priorizada de requisitos/historias en jerga del cliente.
- Id
- Nombre: de 2 a 10 palabras
- Importancia: más alto = más importante. La importancia la da el product owner.
- Estimación inicial: la unidad son puntos de historia [PH en adelante] (días/persona ideales). Ojo, no es un contrato ni un compromiso. Las estimaciones absolutas no son importantes, lo son las relativas. P.ej. Una historia con 2 PH debería durar la mitad que una con 4 PH.
- Cómo probarlo: descripción a alto nivel de cómo testearlo (descripciones simples).
- Notas: otra info breve.
El product owner se encarga de los objetivos del negocio y no interviene en decisiones técnicas.
Debe existir la pila de producto, con las importancias, antes de empezar el sprint.
2- Planificación del sprint
Produce:
- Una meta de sprint, definida en términos de negocio.
- Lista de miembros porcentaje de dedicación.
- Pila de sprint.
- Fecha para la demo del sprint.
- Lugar y momento definido para el scrum diario.
Cada historia tiene 3 variables:
- Alcance (la da el product owner).
- Importancia (la da el product owner).
- Estimación (la da el equipo).
- [Calidad]
- Externa: lo que perciben los usuarios del sistema.
- Interna: aspectos no visibles al usuario. Es responsabilidad del equipo y NO ES NEGOCIABLE.
Todo en scrum tiene una duración determinada (time-boxed).
2.1. Meta
¿Porqué hacemos ésto en lugar de irnos de vacaciones? Listar la meta en una wiki visible a toda la empresa.
2.2. ¿Qué historias incluir?
Lo decide el equipo, ¡no el product owner!
a) ¿Cómo el product owner puede alterar las deciciones del equipo?
- Re-priorizando la historia para que el equipo se vea obligado a incluirla.
- Reducir el alcance de otra historia hasta que quepa la otra.
- Dividir una historia en dos, con diferentes niveles de importancia.
b) ¿Cómo decide el equipo qué historias incluir?
- A ojo (equipos pequeños y sprints cortos)
- Cáculos de velocidad, ya sea
- Mirando la historia de los sprints pasados ó
- Calculando la velocidad estimada = (dias-hombre disponibles) x (factor de dedicación)
Factor de dedicación = (velocidad real) / (días-hombre disponibles).
Ej. (18PH) / (48 días-hombre disponibles) = 0,409 => Factor de dedicación = 40% aprox.
Por defecto en equipos nuevos, este factor es del 70%.
Tras la reunión de planificación, el scrum master actualiza la pila de producto en excel con los cambios hechos en las tarjetas físicas. NOTA: Las historias (tarjetas) pueden dividirse en tareas (post-its).
2.3. Estimación del tiempo: Planning Poker
13 cartas: 0,1,2,3,5,8,13,20,40,100,?,café. -> Dividir historias en historias más pequeñas. Buscamos 2-8 días/hombre.
Historias vs tareas
Las historias son entregables de los que el product owner se preocupa. Las tareas son no entregables de las que el product owner no se preocupa.
Historias técnicas
No son historias normales y el product owner las suele dejar fuera. Ej. instalar server de integración continua, actualizar la versión de jira, etc.
- Intentar transformar las h.técnicas en h.normales con valor de negocio mesurable.
- Intentar colarla como tarea dentro de una historia.
- Negociar con el product owner para ir incluyéndolas poco a poco.
Sistema de seguimiento de errores
Varias posibilidades: el product owner imprime los elementos de jira más importantes y los coloca junto al resto de historias.
3. Cómo comunicamos los sprints
Página wiki + mail a toda la compañía enviado por el scrum master. Mail recordatorio de demo invitando a quien quiera venir.
4. Pilas de sprint
El scrum master creará la pila de sprint después de la reunión de planificación, antes del primer scrum diario ->tabla de tareas en la pared.
Primero moverás los post-its de tareas. Después, las targetas blancas de historia pasan a terminado, una vez acabadas sus tareas.
4.1. Diagrama de burndown
Se actualiza tras cada scrum diario. Será el scrum master el encargado de reacci0nar frente a las señales de alarma.
4.2. Estimación dias vs horas
1 día-hombre = 6 horas-hombre reales
NOTA: El product owner no debería sentarse junto al equipo
5. Scrums diarios
Serán de máximo 15 minutos, siempre frente al tablón de tareas, el cual se actualizará con lo del día anterior.
Las reuniones serán de pie.
Tras la reunión, se suman los puntos de historia no terminados y se actualiza el burndown.
6. Demo de sprint
- Describe el objetivo del sprint.
- No pierdas tiempo en el PowerPoint ni en incluir «chorradas».
- Demo rápida en lugar de bonita.
- Demo a nivel de negocio (sin detalles técnicos).
- Ideal: que la audiencia lo pruebe.
- No mostrar pequeños errores solucionados ni funcionalidades triviales.
7. Retrospectivas de sprint
- Product owner, scrum master y equipo.
- De 1 a 3 horas.
- Se designa a un secretario.
- Fuera de la sala de equipo.
- Scrum master muestra la pila de sprint y hace un resumen.
- Cada persona, sin interrumpir, dice qué ha ido bien, qué mal y qué mejorar.
- Velocidad estimada vs real.
- Scrum master resume sugerencias de cara al próximo sprint.
Respecto a las mejoras concretas, se hará una votación por puntos para centrarse en qué mejoras aplicar de cara al próximo sprint (3 puntos por miembro, seleccionamos las 5 mejoras más votadas).
8. Descansos entre sprints
Mínimo 1 noche sin sprint -> retrospectiva y al día siguiente planificación.
Mejor: viernes primera hora hacer demo y retrospectiva. Lunes 9AM planificación.
Mucho mejor: jueves 9AM demo, 10AM retrospectiva, viernes día de laboratorio, lunes 9AM planning.
El día de laboratorio es un día libre para que los técnicos hagan lo que quieran (proyectos personales, sacarse un certificado, etc.)
El Libro
Recuerda, tienes el libro Scrum y XP desde las trincheras» de Henrik Kniberg disponible y totalmente gratuito en su edición digital.
Foto por royskeane