Cuando desde la gerencia de proyectos tradicional (PMP) nos enfrentamos a un proyecto ágil creemos que todo encaja y que podemos emplear los mismos artefactos, entregables y estrategias para ambos tipos de proyectos, esta aproximación nos lleva "gerenciar" de forma equivocada y en consecuencia a fallar, es necesario reconocer que gerenciar un proyecto tradicional o de gestión predictiva es diferente a gerenciar un proyecto adaptativo - como son los ágiles, y en especial los que adoptan scrum como marco de trabajo-. En este post quiero compartirles la diferencia entre una EDT tradicional y una EDT ágil (si es que se le puede decir así)
Comencemos
Recordemos que la línea base del alcance para proyectos tradicionales esta constituida por tres artefactos.
- Enunciado del Alcance
- EDT (esquema de desglose de trabajo) (1)
- Diccionario de la EDT
Donde la EDT reflejará TODO Y SOLO TODO EL ALCANCE A SER CONSTRUIDO. A continuación presento un ejemplo de una EDT correspondiente a un proyecto de software tipo RUP con alcance fijo.
 |
| EDT de un proyecto de software realizado empleando RUP |
Y justo en la palabra alcance es donde comienza la fricción entre tradicional y ágil, pues en software nos interesa es generar valor, no alcance, y es probable que la solución encuentre el resultado esperado del negocio antes (o después (2)) de haber construido todo el alcance planteado
 |
| Diferencia entre tradicional y Scrum |
Aun así, si de obstinados fuéramos a realizar la EDT del proyecto en Scrum resultaría en algo como:
 |
| EDT de un Proyecto en Scrum |
Y la fracción a correspondiente correspondiente a cada sprint sería similar a la siguiente imagen
 |
| EDT correspondiente al Sprint 1 |
Donde, para acabar de ajustar no tenemos certidumbre sobre:
- si el producto en cuestión requerirá todos estos releases
- o si un release requerirá todos los sprints planteados
- o si un sprint contendrá todos las historias planeadas pues la continua repriorización del backlog no nos permite predecirlo(3)
Es por tanto que en un artefacto como la EDT no quedaría registrado todo el alcance a ser construido y podría llegar a verse de la siguiente manera
 |
| Propuesta de EDT para proyectos Scrum |
Este artefacto - la EDT - , como vemos. se queda corto para la gestión del valor y del alcance del proyecto scrum, es por eso que para este tipo de proyectos se emplean otro tipo de herramientas para la gestión del alcance y por ende del Product Backlog (que es en donde reside el alcance y el valor del producto y del proyecto), una de esas herramientas es el mapa de historias de usuario (user story map), el cual permite:
- Identificar y gestionar los releases
- Identificar y repriorizar las historias épicas a construir
- Visualizar los objetivos de negocio a cumplir
Para saber más del User Story Map hacer clic aquí.
La "EDT" podría verse así:
 |
| "EDT" Proyecto Ágil considerando un MVP y varios Releases (en negro están los elementos con incertidumbre a ser construidos) |
Nota importante: Para complementar el entendimiento de cómo se construye un "proyecto" o mejor un producto ágil te sugiero estos dos post:
Bueno hasta acá esta disertación y lo que quería compartirles, bienvenido el feedback.
Saludos ágiles
Jorge Abad
Notas, Aclaraciones, Comentarios y Referencias
- También conocida como WBS - Work Breakdown Structure - en inglés
- Dependiendo del product owner.
- La constante repriorización agotaría cualquier gestión rigida del proceso de control de cambios.
Muy buen aporte... a través de estos es que se construye conocimiento.
ResponderBorrarSuper! Saludos Jorge.
ResponderBorrarGenial! Gracias por el aporte, Jorge! Saludos!
ResponderBorrarExcelente!!
ResponderBorrar