He estado leyendo 3 libros sobre Agile Project Management y en todos ellos no hay un concepto sobre WBS ni siquiera en el libro de la práctica ágil de agile alliance que viene con la 6ta edición del PMBOK.
De hecho, en uno de esos libros, la WBS solo se muestra en una imagen para comparar la gestión de proyectos en cascada con la gestión de proyectos ágil. Incluso la gestión de EV es ligeramente diferente con otras fórmulas que difieren de la metodología PMI.
Sin embargo, hay algunas técnicas de PMI que todavía se utilizan en el enfoque ágil, pero no están estructuradas como en los grupos de procesos.
Mi pregunta es, cuando inicia un proyecto con un enfoque ágil, la WBS está DESACTUALIZADA, OBSOLETA, DESAPROBADA, ¿INÚTIL?
Pensé que podía representar mis características en sprints con entregables en mi WBS, pero ahora estoy confundido.
No, la EDT no está desactualizada, obsoleta, obsoleta ni inútil.
La WBS es solo una descomposición de LO QUE desea entregar.
La creación de una EDT no es una tarea de una sola vez, sino un proceso interactivo e iterativo .
Una mejor práctica en la gestión de proyectos es crear una WBS orientada al producto , que utilizará más adelante para estructurar su planificación.
En mi artículo " cómo crear una EDT orientada a productos " , analizo este proceso con un ejemplo de un sistema de recomendación.
En ágil hablamos de mapa de historias de usuario , que es una vista de las historias de usuario organizadas por EPIC y características.
¿Es el mapa de historias de usuario lo mismo que el WBS?
No, estas herramientas no son lo mismo , pero se pueden usar juntas ya que desde mi punto de vista son complementarias .
Desde mi experiencia, la WBS es mejor para comunicarse con las partes interesadas fuera del equipo , y el mapa de historias de usuario con el equipo .
Si desea saber cómo puede transformar su WBS en un mapa de historias de usuario, probablemente le gustaría echar un vistazo a mi artículo " De una WBS a un mapa de historias de usuario " .
Espero que esto ayude.
Saludos halcón
Estoy de acuerdo en que la definición estricta de WBS y su uso se presta mejor para ser utilizado en las metodologías de cascada... sin embargo, como se mencionó anteriormente, algunos de sus principios se pueden aplicar a la gestión del concepto Scrum o Agile Backlog. En Ágil. Básicamente, está dividiendo el trabajo en épicas, funciones, historias de usuarios... que coinciden estrechamente con el proyecto, el entregable y el paquete de trabajo en la EDT. Personalmente, me gusta el concepto de construir una WBS para una fase de trabajo ágil para crear el back log. Me gusta reunirme en la sala y usar las notas de publicación para obtener una visión de alto nivel del trabajo que se avecina.
Puede dividir los objetivos comerciales de sus clientes -> en Epics, Epics -> en Historias de usuarios o Características. Y piénselo como si fuera WBS. Pero hay cosas significativamente importantes a tener en cuenta:
Dependiendo de cómo construya su WBS, eso podría ser posible, pero tradicionalmente los WBS se dividen en tareas. Esto supone que conozco todo (o al menos la mayor parte) del trabajo que debe realizarse por adelantado. Este enfoque es imposible cuando se resuelven problemas complejos en los que necesito hacer algo de trabajo para descubrir qué otro trabajo se necesita hacer. Por lo tanto, dado que Scrum fue especialmente diseñado para este tipo de trabajo (la mayoría del desarrollo de productos es en realidad este tipo de trabajo), Scrum utiliza un backlog emergente.
Cuando estaba aprendiendo Scrum, miraba el backlog como una especie de WBS. Hay algunas razones por las que esta comparación es inexacta, pero para mí funcionó como un enfoque de transición. Solo que, en lugar de desglosar el trabajo por hacer, desglosé lo que quería que hiciera el producto.
Estoy de acuerdo con lo que [creo que...] dice Mike Rowe: los dos conceptos se pueden usar juntos, y muy a menudo lo son.
Por ejemplo, cuando decimos que *"esencialmente estás dividiendo el trabajo en épicas, (etc.) ..." bueno, ahí está la misma frase otra vez, solo que en un contexto diferente. Todavía tenemos trabajo, y todavía lo estamos desglosando. (Pero el alcance y los límites, y las metas, de nuestros esfuerzos de descomposición ahora son diferentes... y tal vez, "múltiples y paralelos").
En el contexto de estos proyectos, sigo encontrando valor en la aplicación de conceptos WBS en dos niveles distintos:
En las etapas iniciales del proyecto, mientras intentamos desarrollar, o al menos predecir o pronosticar, una expectativa general para él. Pero luego permitimos que las actividades autodirigidas del equipo descubran los detalles mientras el proyecto se compara periódicamente con este desglose inicial (y se revisa el desglose).
En una escala micro, el conocimiento de los principios de la EDT puede resultar más eficaz para ordenar las próximas actividades a corto plazo del equipo que el "simple consenso".
Los conceptos de WBS también son extremadamente valiosos para determinar cuál debería ser el desglose inicial del proyecto, en un gran esfuerzo que podría involucrar a varios equipos [scrum/agile/what-have-you]. En mi opinión, es extremadamente importante que cada equipo se establezca con un alcance y unos límites bien pensados, y que las interacciones previstas entre las distintas "cajas de equipo" se entiendan tan bien como sea razonablemente posible en este punto. (Y que luego lo revisemos de vez en cuando y publiquemos nuevas revisiones).
La "EDT tradicional [en cascada]" se vino abajo, por así decirlo, porque no podemos predecir todo el futuro antes de comenzar. Se desarrollaron metodologías iterativas (scrum, ágil, etc.) como respuesta a esto, dándose cuenta de que "bueno, no tenemos que hacerlo". Pero diría que ciertamente no descartaron ninguna de las buenas ideas de WBS. Simplemente comenzaron a aplicarlos en diferentes momentos, en diferentes niveles y con objetivos tanto a corto como a largo plazo. Al hacer esto, pensamos que hemos mejorado el agua del baño, pero no tiramos al bebé en el proceso.
Todd A. Jacobs