Modelo de gestión y desarrollo de productos DAPC

En los últimos años a raíz de mi experiencia en varios tipos de proyectos que quieren implementar modelos ágiles, como Scrum, Lean Startup, Kanban, etc, fui modificando DAC cada vez para que se adaptara a un tipo específico de proyecto y a las condiciones de la organización.

Es así como surge esta nueva propuesta. Desarrollo Ágil de Productos con Calidad, es un modelo de gestión y desarrollo de productos de software aplicando el Framework Scrum a la par que se utilizan los procesos de la Guía del PMBOK como complemento para alcanzar una mayor calidad en la gestión y por ende en los resultados del proyecto. Este nuevo modelo está enfocado al desarrollo de productos más que a proyectos, productos que inician pequeños y van creciendo a través del tiempo en dependencia del mercado y sus usuarios, desarrollados por equipos pequeños y multidisciplinarios dentro de una organización cuya razón de ser es el desarrollo y comercialización de estos productos.

Al estar basado en Scrum toma como base la Guía de Scrum y define un modelo de desarrollo donde antes de comenzar el proceso de Scrum se realizan dos procesos iniciales: Inicio del proyecto y Arquitectura y Prototipo. Durante estas dos primeras fases se realiza toda la actividad que hoy en día muchos de los que usan Scrum desarrollan en algo que a veces llaman Sprint 0. Al ser una adaptación de DAC también está basado en todas las prácticas ágiles de DAC., sin embargo cambia varios conceptos y enfoques del modelo DAC debido a que está pensado para otro tipo de productos.

En la fase de Arquitectura y Prototipo debe quedar definido el alcance inicial del producto, una primera versión priorizada del Product Backlog con los elementos a desarrollar en el primer Sprint lo suficientemente claros. Además en esta fase se ha de definir un diseño y una arquitectura del producto robusta a todos los niveles a través del desarrollo del prototipo. El Product Owner definirá como debe verse y funcionar el prototipo. Se recomienda en esta fase implementar los diferentes entornos a utilizar durante la etapa de ejecución: Entorno de Desarrollo, Entorno de Testing, Entorno de Pre-Producción y Entorno de Producción. De igual manera se recomienda implementar de ser posible técnicas y herramientas de integración continua, despliegue continuo y pruebas automatizadas. Durante el desarrollo del prototipo se ha de establecer el sistema de trabajo en equipo. Se recomienda utilizar un tablero Kanban para darle seguimiento a las tareas de esta etapa.

En la Fase de Desarrollo del Sprint se deberá obtener siempre un producto desplegado al entorno de pre-producción por lo que como parte de las tareas asociadas a cada elemento del Product Backlog deberán existir tareas de diseño, análisis, implementación, pruebas y despliegue. Durante el Mantenimiento del Product Backlog el Product Owner decide si se libera o no el incremento anterior al entorno de Producción.

Se recomienda aplicar el Desarrollo Guiado por Pruebas (TDD) para disminuir el esfuerzo requerido para las tareas de pruebas de integración y aceptación. Se recomienda además utilizar estándares de código, trazabilidad entre el código y los elementos del Product Backlog, patrones de arquitectura y reutilización de código,  para la obtención de un producto de mayor calidad. De igual forma se recomienda la utilización de sistemas de gestión de tareas, sistemas de comunicación de proyectos y repositorios de información y conocimiento (por ejemplo Wikis).

A continuación una imagen donde se muestran los procesos del modelo DAPC:

En este modelo vamos a tener los siguientes roles:

1-Project Manager: Estará a cargo de los procesos de Gestión de Proyecto y es quien se encargará de crear el equipo de desarrollo del producto y de las actividades de la Fase de Inicio. Máximo responsable de mantener la documentación del proyecto/producto actualizada y de monitorear el avance de los proyectos/productos. Máximo responsable de los proyectos a su cargo. Puede administrar varios proyectos a la vez dentro de la misma organización pero si se trata de un Proyecto/Producto grande con varios equipos de Scrum es mejor que se dedique a este único Proyecto/Producto. Debe estar comprometido con la implementación de Scrum y conocer sus bases.

2-Reliability Team: Estará a cargo de los procesos de Soporte (Procesos, Calidad, DevOps y TechOps). Es común a los diferentes equipos Scrum del producto/proyecto y puede cumplir esta función para varios productos de la organización en dependencia del tamaño. Debe estar comprometido con la implementación de Scrum y conocer sus bases. Encargado de definir los artefactos y formatos para documentación necesaria a generar durante la ejecución de los Sprint tratando de cumplir al mismo tiempo los principios de calidad, los valores y principios del Manifiesto Ágil y los valores y artefactos de Scrum. Encargado de mantener una infraestructura tecnológica segura, de calidad y automatizada garantizando la integración y entrega continua de los productos/proyectos a su cargo.

3-Scrum Master: Todas las funciones definidas para un Scrum Master en la Guía de Scrum. Interno al producto/proyecto. Sirve a un solo producto o proyecto que puede estar compuesto por varios Equipos de Scrum. Debe tener todas las capacidades requeridas para este rol.

4-Product Owner: Todas las funciones definidas para un Product Owner en la Guía de Scrum. Interno al producto/proyecto aunque puede ser un representante nombrado por el cliente. Sirve a un solo equipo de proyecto. Debe tener todas las capacidades requeridas para este rol. De preferencia ha de tener conocimientos básicos suficientes de programación, calidad de software y análisis y diseño de sistemas.

5-Equipo de Scrum: El equipo de Scrum, tal cual se describe en la guía de Scrum, es un equipo multidisciplinario. Se considera que debe contar como mínimo con las siguientes capacidades o áreas de desempeño: Arquitectura de Software, Programación, Calidad de Software, Despliegue, Diseño, Análisis de sistemas y/o negocios, Bases de Datos, Diseño UI/UX, entre otros. Puede haber varios Equipos de Scrum trabajando en el mismo proyecto o producto.

6-Stakeholders: Involucrados con poder e influencia sobre el proyecto o producto ya sea de la propia organización o de los clientes.


No hay comentarios:

Publicar un comentario

Por fa déjame un comentario

Artículo destacado

Lo qué necesitas saber sobre el rol de Scrum Master - Revisión de varios artículos de Javier Garzás

Hola amigos Hace tiempo no escribo nada nuevo pero aquí voy. Resulta que en los últimos meses he estado leyendo varios artículos de Javier...

Populares en este blog