Scrum es un marco de trabajo ágil para desarrollar software en ciclos cortos llamados sprints, de un mes o menos. En cada sprint, un equipo pequeño construye una parte del producto que ya funciona, la revisa con el cliente y ajusta el plan. Su referencia oficial es la Guía de Scrum de Ken Schwaber y Jeff Sutherland.
¿Es Scrum una metodología ágil?
Sí, aunque sus autores prefieren llamarlo marco de trabajo. La Guía de Scrum lo describe como un marco ligero para generar valor con soluciones adaptativas a problemas complejos. Deja muchas decisiones en manos del equipo en lugar de dictar cada paso.
Su vínculo con lo ágil es directo. Ken Schwaber y Jeff Sutherland figuran entre los firmantes del Manifiesto por el Desarrollo Ágil de Software. Si quieres ver Scrum junto a otras opciones, lo comparamos en metodologías de desarrollo de software.
Los tres roles del equipo.
Un equipo Scrum suele tener 10 personas o menos. Dentro hay tres responsabilidades, que no equivalen a tres cargos de empresa.
- Product Owner. Responde de maximizar el valor del producto y ordena la lista de trabajo pendiente. Es una sola persona, no un comité.
- Scrum Master. Se encarga de que el equipo aplique Scrum y de quitar obstáculos. No manda sobre el equipo; protege el método.
- Developers. Son quienes construyen el incremento de cada sprint, ya sea programando, diseñando o probando.
En proyectos para clientes, el Product Owner suele estar del lado del cliente o trabajar muy cerca de él. Es el papel que más tiempo exige a tu empresa.
Los eventos y su duración.
El sprint contiene todos los demás eventos. La guía fija una duración máxima para cada uno, pensada para un sprint de un mes. Con sprints más cortos, los eventos también se acortan.
| Evento | Para qué sirve | Duración máxima |
|---|---|---|
| Sprint | Construir un incremento útil hacia el objetivo del producto | Un mes o menos, siempre la misma |
| Sprint Planning | Decidir qué se hará en el sprint y cómo | Ocho horas |
| Daily Scrum | Revisar el avance y ajustar el plan del día | 15 minutos |
| Sprint Review | Enseñar el resultado a los interesados y decidir los siguientes pasos | Cuatro horas |
| Sprint Retrospective | Mejorar la forma de trabajar del equipo | Tres horas |
Son los límites que marca la Guía de Scrum. La Daily Scrum es para el equipo, no para informar al cliente. El cliente ve el producto en la Sprint Review, que es su momento para opinar.
Los artefactos y sus compromisos.
| Artefacto | Qué es | Compromiso asociado |
|---|---|---|
| Product Backlog | La lista ordenada de todo lo que podría necesitar el producto | Objetivo del producto |
| Sprint Backlog | Lo elegido para este sprint y el plan para hacerlo | Objetivo del sprint |
| Incremento | El resultado utilizable que se suma a lo anterior | Definición de terminado |
La definición de terminado evita discusiones. Si dice que una función está terminada cuando tiene pruebas y está publicada en el entorno de pruebas, nadie puede dar por acabada una a medias.
Un ejemplo de Scrum en un proyecto de software.
Imagina una clínica de fisioterapia que quiere una app para que sus pacientes reserven cita y reciban sus ejercicios. Se acuerdan sprints de dos semanas.
- Sprint 1. Registro de pacientes y reserva de cita. Al final, el personal de la clínica prueba la reserva.
- Sprint 2. Avisos antes de la cita. En la revisión, la clínica pide que el aviso llegue también por correo.
- Sprint 3. Ejercicios asignados por el fisioterapeuta, con vídeo. El cambio del correo entra aquí, ordenado por el Product Owner.
- Sprint 4. Ajustes, pruebas con pacientes reales y publicación en las tiendas de apps.
Tras dos meses hay una app publicada que ya ha pasado por cuatro revisiones de la clínica. Con un plan en cascada, la clínica la habría visto por primera vez casi al final.
Cuándo Scrum no encaja.
Scrum pide un cliente disponible en cada revisión y un producto que se pueda construir por partes. Encaja peor en encargos muy pequeños o cuando los requisitos están cerrados por contrato.
En el mantenimiento con peticiones sueltas suele funcionar mejor Kanban. Con requisitos cerrados, una planificación clásica. La gestión del proyecto completo, con presupuesto, riesgos y contratos, va más allá de Scrum y la tratamos en gestión de proyectos de software.
En OverFuture desarrollamos software a medida desde Zaragoza, con un fundador que programa desde 2013. Si quieres ver cómo organizaríamos tu proyecto, cuéntanoslo en desarrollo de software a medida. También puedes ver lo que hemos hecho en proyectos.
Preguntas frecuentes.
Un mes o menos, y siempre la misma duración dentro de un proyecto. Muchos equipos eligen dos semanas.
Lo ideal es alguien de tu empresa con capacidad de decidir. Si lo asume el proveedor, necesita acceso frecuente a ti para validar prioridades.
Se puede adaptar, pero pierde parte de su sentido. Con un equipo tan pequeño suele bastar un tablero Kanban y revisiones periódicas con el cliente.
