Hace poco me preguntaban a través del blog sobre qué es lo que hay antes del primer sprint de Scrum. Al lector le daba la impresión de que todos los textos que leía sobre Scrum empezaban directamente en el desarrollo pero y ¿qué hay de la preparación de los entornos, de los equipos o de la oficina? ¿y del diseño? ¿No hay que pararse a pensar en todo el diseño y la arquitectura de lo que vamos a construir antes de empezar a programar?
Sobre la preparación o el ‘antes’ de comenzar a programar, hay gente que lo resuelve con el llamado ‘sprint número 0’ en el que se preparan las herramientas, se instala lo que se necesita, se forma al equipo, etc. Puede ser un sprint más largo (3, 4 semanas o así). Hay algunos detractores a este sprint nº 0 por no ser ágil y estar escondiendo ahí un trabajo que no se está resolviendo en la misma forma que el resto del trabajo.
Es cierto que puede ser muy cómodo porque le dices al cliente que en 3 semanas estás de vuelta para tener la reunión de preparación del primer sprint y para entonces tú ya tienes casi todo organizado. También he usado esos sprints 0 en mis primeros proyectos pero ahora prefiero resolver esos trabajos también de forma ágil.
Intento que cada una de esas tareas (instalar servidor de despliegue, instalar servidor de demo, crear proyecto y tareas en Trac o Redmine, instalar IDE, etc.) formen parte ya del primer sprint y que tengan, en lo posible, un entregable al final de cada demo.
En esa demo podría mostrarse por ejemplo la herramienta de gestión de proyectos ya instalada en la url definitiva y con la lista de tareas esperando ser asignadas, o arrancar el IDE en esa reunión de demo comprobando que el workspace está bien creado y que el jetty ejecuta correctamente una aplicación ‘Hola Mundo’.
Otro punto importante es el diseño inicial de la arquitectura. Si hacemos un gran diseño de toda la arquitectura de la aplicación (big up-front design) antes de comenzar a programar nada estaremos volviendo hacia un diseño en cascada tradicional: primero lo analizamos todo, tres meses después hacemos todo el diseño durante otro par de meses, y por último comenzamos a programarlo todo del tirón hasta acabarlo seis meses más tarde. Si al acabar todo el trabajo se lo enseñas al cliente y te dice: ‘eso no es lo que hablamos hace un año…‘ estamos ante un problema.
Mejor haz el diseño de uno de los módulos de la aplicación o de la nueva funcionalidad, crea las especificaciones y pásalas a desarrollar. Mientras una parte del equipo lo implementa, los analistas pueden ir recogiendo los requisitos para otro nuevo módulo u otras funcionalidades, y así sprint tras sprint.
Habrá sprints en los que no haya nuevas cosas que analizar y otros en los que el desarrollo avanza un poco más rápido de las especificaciones pero normalmente siempre hay algún trabajo listo para comenzar hasta que el product owner dé su visto bueno a los últimos requisitos o estén ya completamente definidos.
Trabajando así, los nuevos módulos o funcionalidades podrían ir pasando a producción o pre-producción cada cierto tiempo por lo que los usuarios pueden ir usándolos sin esperar hasta que la última de las características de la aplicación esté diseñada.
Referencias:
Si te ha gustado este post, puedes encontrar más contenidos que expliquen Scrum de forma práctica y desde su base en mi libro en Amazon Curso práctico de Scrum: Algo más que teoría.
 |
| Libro en Amazon: Curso práctico de Scrum – Algo mas que teoría |
