Desarrollo
Un sprint, de la planning a la retrospectiva
En PES hay una incepción y tres sprints de unas tres semanas, con una sola release. No hay release backlog: solo el product backlog y un sprint backlog para cada sprint.
Las cuatro ceremonias
Sprint planning
Definid el objetivo del sprint y cread su backlog. Ese mismo día, planning_X.pdf en el Drive.
Daily scrum
Como mínimo dos veces por semana, en clase: qué hice, qué haré, qué me bloquea. Sincroniza al equipo para las próximas horas.
Sprint review
Enseñad lo que está hecho, comentad qué ha ido bien y qué problemas habéis resuelto, y revisad el product backlog para el próximo sprint.
Retrospectiva
Qué ha ido bien, qué se puede mejorar y a qué os comprometéis para el próximo sprint. Revisa también vuestra forma de trabajar.
Planning guiada por la velocidad
- Ajustad prioridades y fijad una velocidad objetivo (por historial, prototipo o estimación).
- Un objetivo del sprint, en una sola frase.
- Elegid historias según prioridad y esfuerzo hasta la velocidad objetivo.
- Partidlas en tareas, idealmente de un día como máximo.
- Estimad las tareas en horas ideales. La suma debería cuadrar, a grandes rasgos, con los puntos.
Las tareas mezclan ingeniería y gestión (diseñar la UI, programar, escribir pruebas de aceptación, reuniones) y se asignan dinámicamente según habilidades y disponibilidad. Cada tarea tiene que aportar valor.
planning_X.pdf
Ojo: en el plan de release no asignéis personas a historias ni pongáis tareas de ingeniería ni el orden del trabajo. Todo eso va en el plan de cada sprint.
Juega
El task board
Sirve para autoorganizarse y para ver qué queda y qué se está haciendo. Moved las tareas y mirad cómo bajan las horas pendientes.
Definición de hecho (DoD)
Una historia no está hecha cuando "funciona en mi ordenador", sino cuando pasa por todo el ciclo que el equipo ha acordado. Por ejemplo:
especificada → implementada → probada → documentada → diagramas actualizados
Acordadla en la incepción, escribidla en la memoria (metodología) y revisadla en cada retrospectiva.
¿Y cuando aparece un bug?
- En una historia aún abierta: no tiene mucho efecto, se arregla dentro de la misma historia.
- En una historia ya cerrada: si es poca cosa, se arregla y ya está; si es costoso, se reabre la historia (vigilad los puntos).
- Registradlos siempre: la gestión de bugs es uno de los aspectos metodológicos evaluados.
El report del sprint
Plantilla sprints/1/nom_report_1.docx, en tres partes:
- Introducción: resumen del sprint y del trabajo en equipo.
- Ceremonias: planning, dailies, review y retrospectiva, con los gráficos.
- Changelog: todos los cambios desde la iteración anterior, de forma sistemática.
Al lado, la memoria se mantiene viva (requisitos, metodología y descripción técnica) y se guarda una copia en PDF en cada sprint.
Generador
Los tres gráficos del report
Taiga genera algunos, pero aquí podéis hacerlos con vuestros datos y descargarlos en PNG o SVG para el report. Los datos se quedan en vuestro navegador.
Burndown del sprint
Puntos pendientes al final de cada día del sprint (el día 0 es el total comprometido).
Velocidad
Puntos completados en cada sprint. Es la herramienta principal para planificar fechas y alcance.
Burndown del producto
Puntos pendientes de todo el backlog al inicio y después de cada sprint.
Recordad: el burndown no es para castigar a nadie. Se reestima cada día y sirve para que el equipo se autoorganice. Si la línea real no baja, es el momento de hablarlo en la daily.