Agile Software Development - Ciclo de vida

Trabajar con una metodología ágil, aplicando modelos iterativos e incrementales requiere disciplina, mucha disciplina a seguir. El proceso está compuesto de mini-proyectos y entregas.

En otras palabras, se deben realizar múltiples entregas antes de la entrega definitiva del sofware, por lo que debemos dividir el proyecto en esa cantidad de entregas parciales con su propio alcance y planificación. 

(Consideraciones: Las entregas no tienen que ser siempre externas, ni tienen por que ser desplegadas, pero sí deberían ser desplegables)

Paralelamente a la evolución de las iteraciones incrementales, el proyecto debe seguir su propio ciclo de vida global. Para mi este es el punto más complejo de gestionar. Ya sabéis eso de que "los árboles no te dejan ver el bosque" es decir, cuando te encuentras en situaciones de micro-gestión ... existe un elevado riesgo de perder de vista el alcance temporal y en coste global del proyecto. 

Estas fases, aunque existen diferentes denominaciones, son:

• Inception. Creación - Fases iniciales de definición de requisitos, análisis y constitución del equipo
• Elaboration. Elaboración - Continuación sobre el análisis y el diseño, inicios de las iteraciones de construcción (con sus respectivos test)
• Construction. Construcción - Continuación con los mini-proyectos pero con inicios de despliegues y gestión de la configuración
• Transition. Fase final en la que se dedica más esfuerzo en las iteraciones finales, despliegues finales, y gestión de la configuración

Se puede observar mucho más claramente en el siguiente diagrama de Leffingwell y Widrig, 2003.

En el fondo las fases son simplemente nombres para describir la evolución del proyecto, pero no deja de parecerme interesante tener esa foto en mente, teniendo claro el número de SPRINTS que debería tener el proyecto, el resultado esperado de cada uno de ellos, y identificar lo antes posible situaciones de desviación de presupuesto (Siempre que hablemos de proyecto llave en mano)

El Sprint 0 debe estar destinado a descubrir los requisitos iniciales, planificar el proyecto y configurar las infraestructuras de desarrollo y trabajo. La elaboración de un primer backlog de producto con tareas estimadas, así como guías de desarrollo y buenas prácticas a ser mantenidas durante todo el proyecto.

La planificación en los proyectos ágiles es también iterativa, cada Sprint va acompañado de una hipótesis de progreso, de valor que va a ser entregado a la finalización al cliente. Es un tema que me parece interesante ... olvidando la sobrevaloración (suicida) de las estimaciones de los modelos tradicionales, cuando ni tan siquiera tienes el equipo configurado ni conoces su velocidad de desarrollo.

Cada Sprint se inicia con un meeting donde se define los objetivos del mismo Sprint Backlog, y se actualiza el Release Plan (visión más general del proyecto) correspondientemente. Este plan se realiza de acuerdo con todo el equipo, pero siempre alineado con las prioridades o las decisiones del Product Owner.

Los Sprints contienen tareas de diversa tipología como vemos en la figura anterior, según las necesidades. Al final cada Sprint  se efectúa un Review meeting para demostrar los avances, como medida de progreso del proyecto, y recoger feedback de los promotores. El equipo realiza igualmente un Sprint Retrospective para compartir las experiencias vividas y poder mejorar el proceso.

Los Sprints tienen un periodo de vida conocido y limitado (i.e. 30 días) durante el cual el equipo intenta ejecutar la totalidad de tareas previstas en el Sprint Backlog, no pudiendo este ser modificado por los promotores (no deberían) El tamaño recomendado de los Sprints es como siempre, entre más corto mejor, siendo entre 1 - 4 semanas lo recomendable. 

En ocasiones se considera que, el trabajo derivado de la "burocracia" del proceso, es excesiva, y puede llevarnos a la tentación de alargar los Sprints con el objetivo de minimizarlas. Es un error, teniendo en cuenta que a cada iteración, recibes feedback de promotores y una validación por tanto del producto, debemos tomarlo como beneficioso. (Buscando un equilibrio en relación a la velocidad, en este punto es cuando hay que entender la semántica de cada organización)

Un punto a considerar y que será objetivo de este blog, es que las metodologías ágiles se concentran en el desarrollo de software, dejando fuera de su alcance puntos de interés como la definición de portfolio, el mantenimiento o la gestión de producto (cuando el proyecto es un producto en sí mismo) intentaremos hablar de KANBAN y sus integraciones con SCRUM para la gestión de mantenimiento, y como podemos reflejar la realidad de un producto con estas metodologías (cuando las iteraciones y el feedback viene de usuarios anónimos web por ejemplo)

Saludos,