Los 14 Productos de DSDM Agile Project Framework

Seguimos en la #semanaDSDM, así que en este cuarto artículo de la serie de DSDM Agile Project Framework vamos a profundizar sobre los productos que DSDM propone crear durante el ciclo de vida del proyecto.
Un factor muy importante a tener en cuenta es la obligatoriedad o no de la creación de estos productos. Si parece que no aportan valor, que lo estamos haciendo por burocracia, porque «lo dice nuestra metodología», porque «me lo exige el cliente», y tenemos la sensación de trabajo perdido, debemos plantearnos si realmente es necesario. No es obligatorio, es una recomendación del framework. Textualmente, nos dice lo siguiente:
It is also critically important to remember that DSDM products are only created if and when they add value to the project and/or to the solution it creates. The most important thing is that the stakeholders and participants in the project understand what is needed and what is being delivered and that quality is assured. If documents genuinely help achieve this then create them, if not, don’t waste valuable time and effort doing so.
Los productos incluyen la solución en sí misma, el principal producto a crear, y los productos necesarios para ayudar a desarrollarla y mantenerla; más los productos que sean necesarios  para ayudar con la gobernanza y el control del proyecto.

Tipos de productos

DSDM distingue entre 2 diferentes tipos de productos:

• Productos que evolucionan con el tiempo. Por ejemplo, los requisitos o la solución. Pueden hacerse diferentes baselines de este producto a lo largo del proyecto.

• Productos que marcan un hito. Normalmente al final de una fase como checkpoint o para facilitar el proceso de gobernanza.

Categorías

Además, clasifica los productos en 3 categorías:

• Business-oriented Products. Enfocados a detallar aspectos de negocio, como beneficios esperados, requisitos, justificación del proyecto, … Marcados de color naranja.

• Solution/technical oriented Products. Enfocados a definir aspectos técnicos, de desarrollo, de gestión de calidad, de alcance, … Marcados de color verde.

• Management/control oriented Products. Enfocados a la gestión del proyecto, incluye aspectos de comunicación, de planificación de entregas, de mejora continua, … Marcados de color azul.

Además de esta clasificación, algunos de ellos pueden estar relacionados con los procesos de gobernanza o con la conformidad de la solución respecto estándares corporativos o regulaciones. Estos se detallan con una G en un círculo azul.
En la siguiente imagen podemos ver los 14 productos, con el color correspondiente, y con la fase del proyecto en los que se propone crearlos y evolucionarlos:

Productos de DSDM

Estos son los 14 productos de DSDM:

• Terms of Reference. Creado antes del inicio formal del proyecto, es el documento que nos proporciona una definición a alto nivel del por qué iniciar el proyecto. Nos justifica el hecho de invertir esfuerzos en la fase de Feasability.

• Business Case. Nos proporciona una visión y una justificación del proyecto desde una perspectiva de negocio. Se trata de un documento evolutivo, que elaboraremos progresivamente durante Feasability y Foundations, y que marcaremos como línea base al empezar el desarrollo. Lo revisaremos periódicamente para asegurar que estamos alienados con los objetivos del proyecto, y nos ayudará a determinar si debemos continuar con el proyecto, detenerlo, o reenfocarlo.

• Prioritised Requirements List. Descripción a alto nivel de los requisitos del proyecto, y la prioridad relativa entre ellos. Este producto es muy similar al Product Backlog de Scrum.

• Solution Architecture Definition. Diseño a alto nivel del framework de la solución. Incluye aspectos técnicos y negocio con un nivel de detalle suficiente para tener claro el alcance de la solución, pero sin que nos limite un desarrollo evolutivo que nos permita adaptarnos a futuros cambios.

• Development Approach Definition. Nos describe a alto nivel qué herramientas, prácticas, estándares, … serán aplicados durante el desarrollo de la evolución. Siguiendo los principios de DSDM, el desarrollo deberá ser iterativo, con entregas incrementales, e integrando el testing en todo el proceso. Por tanto, incluirá el detalle de cómo tenemos previsto asegurar la calidad de la solución desarrollada.

• Delivery Plan. Planificación a alto nivel (semanas – meses) de las entregas incrementales previstas, similar a un Roadmap o Release plan. No entra en detalle de las tareas necesarias para llevarlo a cabo, sino las fechas estimadas de entrega.

• Management Approach Definition. Engloba cómo vamos a ejecutar el proyecto desde una perspectiva de gestión: cómo vamos a organizarnos, cómo vamos a planificar, como vamos a involucrar a las personas claves, como vamos a comunicarnos y demostrar el progreso…

• Feasability Assessment. Al final de la fase de Feasability debemos tomar una decisión acerca de la viabilidad del proyecto. ¿Vamos a ser capaces de hacerlo? En este producto de gobernanza incluiremos los productos elaborados hasta ahora (Business Case, PRL, SAD, DAD, Delivery Plan, MAD), o un resumen ejecutivo de ellos. Su aprobación nos permite entrar en más detalle para tomar más adelante la decisión de Go – No go, antes de empezar el desarrollo.

• Foundation Summary. Nos basaremos en este producto para la decisión Go – No go de del desarrollo de la solución. Nos proporciona un nivel de detalle suficiente para estimar si vamos a poder entregar la solución requerida con los términos esperados de coste, tiempo, calidad…

• Evolving Solution. El producto evolutivo, motivo por el cual hemos iniciado el proyecto. Incluye tanto la solución desarrollada como otros componentes necesarios para su uso y mantenimiento, generando así diferentes Solution Increments que van construyendo la Evolving Solution. Al final de cada Project Increment, el Solution Increment se pasa a un entorno productivo, y se convierte en la Deployed Solution.

• Timebox Plan. Detalle del Delivery Plan a realizar en una iteración. Incluye tanto tareas a realizar como la actualización de su estado, y los entregables a producir. Se puede materializar en forma de Team Board, con un Kanban sencillo por ejemplo. Similar al Sprint Backlog en Scrum.

• Timebox Review Report. Resumen de lo conseguido al finalizar el Timebox. Captura también el feedback de la revisión al final de la iteración, y las posibles mejoras a incorporar. Es similar a las conclusiones que podríamos obtener de las reuniones de Sprint Review y Sprint Retrospective en Scrum.

• Project Review Report. Documento incremental, con las conclusiones y el progreso después de cada Project Increment.

• Benefits Assessment. Descripción de los beneficios conseguidos después de poner en producción la solución desarrollada. Puede rellenarse incluso varios meses después de finalizar el proyecto, en función de la justificación prevista en el Business Case.

Recordemos una vez más la no obligatoriedad de estos productos, siendo una recomendación del framework a ser considerada por los integrantes del equipo de proyecto. Citando textualmente DSDM:
«Not all products are required for every project and the formality associated with each product will vary from project to project and from organisation to organisation.»
DSDM nos está proporcionando buenas prácticas acerca de qué aspectos tener en cuenta en el desarrollo ágil de una solución, y debemos ser coherentes con el esfuerzo requerido vs los beneficios aportados por cada uno de los productos.
Por último, no dudéis en informaros de nuestras convocatorias de cursos y certificaciones en AgilePM y AgileBA.