Seguimos con la serie de artículos acerca del DSDM Agile Project Framework Handbook publicado por el Agile Business Consortium, esta vez profundizando en el ciclo de vida de los proyectos.
La palabra «proyecto» tiene cierta connotación negativa en algunos entornos ágiles. Años de fracasos en proyectos waterfall tienen gran parte de la culpa, y el significado de «proyecto» en entornos IT se ha acabado asociando a algo pesado, estricto, con fechas inamovibles, … y de rebote ha estigmatizado la figura del Project Manager como un jefe autoritario, que trata a las personas como recursos y que dirige con un estilo command & control. Incluso iniciativas como #NoProjects han hecho de este enfoque su marca, a pesar que el auténtico significado de #NoProjects es más bien «haz foco en el equipo».
Scrum es genial. Es un marco de trabajo muy potente, ideal para construir productos complejos, y sin duda el más extendido en Agile. Pero no es fácil de aplicar, en la propia guía Scrum ya nos dice que es «difficult to master». Y dos de las dificultades que siempre me comentan los alumnos de nuestros cursos de Scrum y de las organizaciones a las que hemos ayudado a implantarlo, son: la dificultad para aplicarlo; y qué hacemos desde que se decide empezar el proyecto hasta que tenemos el equipo formado para empezar a desarrollar. Técnicas como Agile Inceptions nos ayudan a que este período de tiempo sea el menor posible. Aplicando Scrum, podríamos incluirlo como parte del primer Sprint, y entregar software terminado en 30 días o menos. Pero Scrum no detalla qué otros roles pueden intervenir en este proceso, ni qué actividades llevar a cabo (al igual que tampoco entra en qué actividades llevar a cabo para el desarrollo o el testing).
En este sentido, DSDM se diferencia de Scrum (y de otros marcos ágiles) en que requiere unos pasos mínimos para conceptualizar, aprobar e iniciar el desarrollo de la solución. Uno de los principios que explicamos en el anterior artículo es Build Incrementally from Firm Foundations. Para tener una buena base DSDM propone primero analizar la viabilidad, y después acordar unas expectativas de negocio, solución técnica y modelo de gestión.
Fases de ciclo de vida del proceso DSDM
Las fases de ciclo de vida del proceso DSDM Agile Project Framework son las siguientes:
Pre-project
Asegurar que la organización únicamente empieza los proyectos adecuados, con un objetivo claro. Es una visión de Portfolio en la que se debe decidir en qué invertir basándose en la estrategia de la empresa.
Feasability
Analizar la viabilidad técnica del proyecto junto con un mínimo análisis coste-beneficio para detenernos en este momento o continuar. Es el inicio formal del proyecto.
Foundations
Establecer las bases del proyecto, sin entrar en detalle, para entender la solución potencial a crear, y como llevaremos a cabo el desarrollo y la gestión del proyecto. Debería llevarnos días, pocas semanas a lo sumo, incluso para proyectos grandes y complejos. El objetivo es entender el alcance del trabajo a alto nivel y cómo lo ejecutaremos, quién, cuándo, dónde, y cuánto nos va a costar. Para proyectos pequeños podemos fusionar Feasability y Foundations en una única fase de pocos días.
Evolutionary Development
A partir de los fundamentos establecidos, el objetivo de esta fase es crear y evolucionar la solución. Requisitos breves y orientados a valor, escritos por ejemplo en forma de User Stories, priorización con MoSCoW, utilizar timebox de 4 semanas como máximo (cuanto más cortos mejor)… El formato del timebox es similar a Scrum, estableciendo objetivos y alcance al principio, coordinando el avance mediante daily stand up meetings, demostrando el producto terminado al final de la iteración, y reflexionando con una retrospectiva. El testing está integrado en esta fase, y nos aseguramos que el incremento desarrollado satisface las necesidades de negocio y está construido correctamente.
Deployment
El objetivo de la fase de deployment es poner la solución desarrollada en un entorno operativo, a disposición de los usuarios. Puede ser una solución parcial, o la versión final. Después de la última puesta en producción de la solución completa, el proyecto se cierra formalmente.
Post-Project
Una vez finalizado el deployment de un proyecto, la fase de Post-Project revisa hasta qué punto hemos alcanzado los beneficios de negocio esperados. Puede llevarse a cabo justo después, o varios meses más tarde. Todo depende del plan de consecución de los beneficios.
Diferencias con un modelo Waterfall
Alerta. Puede parecer que se trata de un clásico modelo waterfall de Analisis, Diseño, Desarrollo… pero hay varias diferencias importantes que es necesario remarcar:
- La duración de Feasability y Foundations debe ser mínima, a ser posible en timebox, y razonable con la magnitud del proyecto. Por ejemplo, si en menos de 30 días mantenemos las fases de Feasability, Foundations y el primer timebox, estaremos entregando software terminado en los plazos que marca Scrum. Y el Agile Manifesto nos sugiere un par de meses a lo sumo. Todo depende de la proporción. Ah, si hacemos únicamente una entrega y finalizamos el proyecto, no estaremos haciendo DSDM. Eso es waterfall y no sigue los principios de DSDM.
- El testing está totalmente integrado en las iteraciones de Evolutionary Development. No dejamos el testing para el final. DSDM es estricto en diseñar una estrategia de Testing como parte del proceso de desarrollo, y categoriza diferentes tipos de test (colaborativo, repetible, priorizado, independiente, TDD, …)
- El Deployment se realiza frecuentemente. Entregas incrementales, cuanto antes mejor, y cuanto más frecuentes mejor. El hecho de tener de forma explícita la fase de Deployment no significa que haya una sola fase de Deployment. Significa que debemos poner en producción la solución que estamos desarrollando, y que debemos hacerlo correctamente, estableciendo una baseline de nuestra solución, y con una correcta gestión de la configuración.
Ejemplo
Un ejemplo de configuración del ciclo de vida de un proyecto con 5 iteraciones podría ser el siguiente:
Utilizando DSDM, a partir de las diferentes fases podemos diseñar un roadmap de entregas tempranas y continuas para nuestro proyecto, implantando una solución de manera incremental, adaptándonos a partir del feedback obtenido en todo el proceso, y revisando que se estén cumpliendo los beneficios esperados.
Un modelo ágil que sin duda puede ayudar mucho a organizaciones habituadas a trabajar por proyectos a cambiar su mentalidad y su forma de trabajar para mejorar su capacidad de entrega de valor y reducir el time to market.
Por último, no dudéis en informaros de nuestras convocatorias de cursos y certificaciones en AgilePM y AgileBA.