Integración de la cadena crítica en Scrum/Prácticas ágiles

La Gestión de Proyectos de Cadena Crítica exige una mayor flexibilidad de su equipo:

De Wikipedia Gestión de proyectos de cadena crítica:

Una red de proyectos de Cadena Crítica tenderá a mantener los recursos nivelados, pero requerirá que sean flexibles en sus tiempos de inicio y que cambien rápidamente entre tareas y cadenas de tareas para mantener todo el proyecto dentro del cronograma.

Pero también (de Wikipedia Critical Chain Project Management):

cuando están ejecutando su "parte" del proyecto, deben concentrarse en completar la tarea asignada lo más rápido posible, sin distracciones ni multitarea .

Y también (de Wikipedia Critical Chain Project Management):

Debido a que las duraciones de las tareas se han planificado con una probabilidad del 50%, existe presión sobre los recursos para completar las tareas de la cadena crítica lo más rápido posible, superando el síndrome de Student y la Ley de Parkinson.

Lo que más me preocupa es la probabilidad de que el equipo acabe haciendo una mala multitarea. Consulte el artículo Human Task Switches Considered Harmful de Joel Spolsky:

Del artículo de Joel mencionado anteriormente:

El truco aquí es que cuando administra programadores, específicamente, los cambios de tareas toman mucho, mucho, mucho tiempo. Eso es porque la programación es el tipo de tarea en la que tienes que tener muchas cosas en la cabeza a la vez.

Como especificó que está trabajando con el desarrollo de software, intente asegurarse de que su equipo de desarrollo comprenda el proceso de la Cadena Crítica; de lo contrario, se asustarán y comenzarán a realizar muchas tareas al mismo tiempo.

También del artículo de Joel:

De hecho, la verdadera lección de todo esto es que nunca debes dejar que la gente trabaje en más de una cosa a la vez . Asegúrese de que sepan lo que es. Los buenos gerentes ven su responsabilidad como la eliminación de obstáculos para que las personas puedan concentrarse en una cosa y realmente hacerla. Cuando surjan emergencias, piense si puede manejarlas usted mismo antes de delegarlas en un programador que está profundamente inmerso en un proyecto.

Para eliminar sus conflictos entre Scrum/Agile y Critical Chain:

Critical Chain depende del hecho de que no tiene suficiente tiempo para completar el trabajo (por ejemplo, le dan 2 días para completar 4 días de trabajo). En Agile, si las historias no están completas, simplemente se cancelan o pasan al siguiente sprint.

Este conflicto se puede resolver si asume el hecho de que una tarea de 4 días en realidad es una tarea de 2 días. El trabajo real se realiza en menos tiempo que el dimensionado.

De la Ley de Parkinson :

El Corolario de Stock-Sanford de la Ley de Parkinson dice: "Si esperas hasta el último minuto, solo te tomará un minuto hacerlo".

Por supuesto, algunas tareas llevarán más tiempo de lo esperado, pero Critical Chain asume que la mitad de las tareas terminan antes y la mitad de las tareas terminan tarde.

Critical Chain utiliza un búfer al final del proyecto. (Si el cronograma de su proyecto es de ocho semanas, le dan cuatro semanas para hacer el trabajo y un margen de cuatro semanas al final del proyecto). En Agile, solo tiene sprints (iteraciones) cuando tiene trabajo que hacer.

Para eliminar este conflicto, tendrá que configurar su sprint de manera que siempre tenga trabajo por hacer.

Con el tiempo reducido para terminar las tareas como se indica en el primer conflicto, muchas más tareas llenarán el sprint-backlog. El tiempo total para la finalización del proyecto se reducirá, luego configúrelo como el tiempo ideal para la duración del proyecto y deje que el tiempo restante sea un búfer.

Es muy importante establecer prioridades en las tareas, como must do(se necesita justificación si no se completó) y should do( could dojustificación no se necesita si no se completó).

Básicamente, ejecutará una metodología Scrum pragmática bajo los ojos de Critical Chain.

En realidad, el concepto de búfer funciona bastante bien con un método de desarrollo ágil como scrum. Sin embargo, no estoy tan seguro de reducir las estimaciones a la mitad, pero también aplicamos algo similar usando estimaciones 'más probables' - 'peor de los casos' . Así es como lo hacemos:

Primero hacemos una gestión adecuada del proyecto comenzando con una Estructura de Desglose del Trabajo ( WBS ) bien diseñada hasta el nivel del paquete de trabajo. La lista de paquetes de trabajo es nuestra cartera de productos. Estos paquetes de trabajo se estiman luego con un rango 'Más probable' - 'Peor caso'.

Nuestro 'presupuesto' es la suma de las estimaciones 'más probables'. El 'búfer' se calcula como la suma de los promedios, la suma de los más probables. Algunos usan 2 x desviaciones estándar, como se explica en el libro de Cohn recomendado por Marcie (consulte el capítulo 17 Planes de amortiguación para la incertidumbre).

Ahora a la ejecución: digamos que según la capacidad de nuestro equipo podemos terminar el proyecto en 6 sprints (según las estimaciones más probables) y nuestro presupuesto de ' búfer' es bueno para otros 2 sprints. Hace un total de 8 sprints para terminar el trabajo.

Por lo general, dividimos nuestros proyectos en varias fases técnicas (o lanzamientos más formales); cada una de estas fases obtiene su propio búfer.

Mi opinión es que existe un potencial para una buena sinergia entre CCPM y Scrum

Si nos enfocamos en la dirección de cómo mejorar Agile/Scrum usando el pensamiento CCPM:

La idea del búfer de proyecto frente a los búferes de tareas: mi recomendación es evitar las estimaciones de tareas por completo. solo use tareas pequeñas, sin fechas de vencimiento, y llévelas a cabo lo más rápido que pueda hasta completarlas. Esto evita la ley de Parkinson y trata mejor la variabilidad.

Compromiso de Sprint a la luz de la variabilidad: compromiso basado en el peor de los casos, pero tenga un búfer de alcance de cosas que puede entregar en exceso en caso de que ocurra el promedio. Plan para Murphy, pero plan también para que Murphy no aparezca...

Libere el compromiso de la misma manera utilizando los búferes de alcance y los escenarios de peor caso/promedio. Veo el compromiso de lanzamiento/proyecto/entrega mucho más importante que el compromiso de sprint, y mucho más merecedor de almacenamiento en búfer. No le importa la optimización local del sprint (a menos que cada sprint sea una entrega), puede más sobre la optimización global del lanzamiento/entrega. Comience a usar gráficos de control para conocer las capacidades para mejorar los compromisos y la previsibilidad.

Evite la mala multitarea imponiendo prioridades en el trabajo pendiente del lanzamiento y el trabajo pendiente del sprint, y limite la cantidad de historias que están en progreso en el sprint, así como las características que están en progreso en el trabajo pendiente del lanzamiento. "Dejar de empezar - Empezar a terminar".

También hay aspectos que son similares al enfoque de escalonamiento y congelación del entorno de múltiples proyectos, cuando se usa Kanban para administrar el lanzamiento de extremo a extremo, limita el diseño general en proceso en el sistema.

Scrum/Agile le brinda una gran ventaja sobre el CCPM típico: debido al trabajo que utiliza historias de extremo a extremo en la cartera de pedidos, la flexibilidad de recursos debido al impulso hacia la propiedad colectiva y la menor necesidad de sincronizar debido a los equipos de funciones/Scrum, obtiene una cadena crítica mucho más simple, con menor necesidad de buffers de alimentación, buffers de recursos, etc.

Si tiene dependencias entre equipos y otras entidades externas, puede tener un gráfico pert de alto nivel de su proyecto, también conocido como "Planificación anticipada" en el mundo Agile. Pero si ve DEMASIADAS dependencias, podría ser una indicación de que sus equipos no están formados idealmente para hacer frente al trabajo.

Hay mucho más en esta discusión, pero en resumen: no enemigos, sino primos... ahora el consultor de CCPM le dirá que CCPM es mucho más fuerte y Agile es una solución local, pero sea fuerte ;-) CCPM por su parte tiene mucho que aprender del mundo Agile: flexibilidad en las características/requisitos, retroalimentación temprana, empoderamiento del equipo, todas las cosas excelentes que pueden mejorar un entorno CCPM y ayudar a lidiar con la variabilidad y mejorar la previsibilidad y el rendimiento incluso para una excelente implementación CCPM. Veo Agile/Scrum como una forma de aplicar el Proceso de Mejora Continua (POOGI) en el mundo CCPM.

Espero que esto ayude.

Va a ser un poco confuso, pero la teoría parece sugerir que podría lograr esto al:

1. Acortar el sprint en x días, por ejemplo, 3 días
2. Usar la totalidad o una parte de esos 3 días como amortiguador
3. NO permita que las historias se cancelen o prorroguen. Deben completarse dentro del sprint plus buffer.
4. Extienda ciertos entregables a través de varios sprints (haciendo crecer las historias) y construya/administre un búfer que esté compuesto por todos los días de búfer de todos los sprints, por ejemplo, 9 días si está usando un búfer de 3 días y distribuyendo la historia en 3 sprints.

Sería genial escuchar cualquier comentario sobre este enfoque en la práctica.

Probablemente esta no sea una respuesta popular, pero si está haciendo Scrum, deseche la mayor parte de lo que aprendió haciendo su PMP. Son procesos de pensamiento completamente diferentes.

Los procesos de cadena crítica asumen que tiene un cronograma enorme y detallado, con dependencias de recursos y tareas. En Scrum, tiene un backlog bien priorizado, del cual la función/tarea más importante siempre se completa a continuación. El equipo se comunica a diario (si no más a menudo) y muestra funciones al cliente cada dos semanas o 30 días, y las tareas/funciones se vuelven a priorizar en consecuencia. Esto eliminará las ineficiencias del proceso para usted, al igual que lo haría la cadena crítica en un proyecto de gestión de proyectos tradicional.

Ahora, si le gusta el concepto de "búferes", aún puede usarlos con Scrum. Recomiendo el libro "Agile Estimating and Planning" de Mike Cohn. Tiene excelentes técnicas para manejar estimaciones y "amortiguadores" de manera ágil.

Llego tarde a esto, pero recomiendo encarecidamente leer el libro. Es un aprendizaje envuelto en una historia y es una lectura rápida. No es la ficción más grande del mundo, pero transmite el punto sin ser un libro de texto seco. Estoy de acuerdo en que estas dos metodologías son primas y no diametralmente opuestas.

Scrum y Critical Chain están destinados a resolver diferentes problemas. Con Scrum, se trata de un producto mal definido. Los métodos ágiles están destinados a desarrollar, de la manera más eficiente posible, un producto que no se comprende bien al comienzo del proyecto.

Con Critical Chain, tiene un producto/objetivo bien definido de su proyecto, pero una gran incertidumbre sobre cuánto tiempo tomarán los pasos individuales. Debido a esto, en proyectos grandes, mantener ocupados los recursos críticos se vuelve difícil, ya que los resultados del trabajo de otros recursos pueden no estar listos cuando el recurso crítico lo necesita.

Critical Chain resuelve este problema utilizando técnicas de la teoría de restricciones de Goldratt. El libro original de Goldratt es bastante antiguo y la comprensión de la técnica ha mejorado considerablemente desde su publicación. Sin embargo, los nuevos resultados permanecen dispersos en la literatura especializada.

Oh, sí, la división por dos simplemente proviene de la práctica común de tomar su mejor estimación para la duración de una tarea y duplicarla.

Critical Chain se inventó para manejar el problema siempre presente de las tareas de almacenamiento en búfer en un cronograma con tareas dependientes, y cómo las terminaciones tempranas nunca podrían aprovecharse mientras que las terminaciones tardías deslizaron todas las tareas dependientes. 'Funciona' al reducir la duración de todas las tareas a la mitad, asegurando que la mayoría de las tareas no terminen antes de tiempo. El tiempo eliminado se agrega luego a un "búfer de cadena" como la última tarea dependiente de la cadena. Para realizar un seguimiento del progreso en el cronograma, todas las tareas que se completan dentro o antes de tiempo se marcan como tardías, pero todas las tareas que finalizan tarde se marcan como completadas y el tiempo adicional (tiempo adicional al asignado para la tarea) se 'comido' en el tampón de la cadena.

El objetivo de Critical Chain era garantizar que ninguna tarea tuviera que esperar porque alguien terminara antes de tiempo. Solo funciona cuando tiene muchos recursos que pueden cambiar constantemente de una tarea a otra. Obtenemos lo mismo en Scrum al NO asignar tareas componentes de elementos pendientes a los miembros del equipo, sino que los miembros del equipo toman la tarea de mayor prioridad que no se ha iniciado y que pueden hacer una vez que terminen su tarea actual. Esto nos permite utilizar un sistema de extracción como el que se encuentra en Lean/TPS y garantiza que las tareas 'listas' se inicien tan pronto como esté disponible un recurso apropiado.

En resumen, no necesita, ni quiere, Critical Chain dentro de un proceso Scrum correctamente implementado... es una solución a un problema inexistente.

Si su proyecto:

1. puede ser manejado por un equipo
2. se puede dividir de manera que cada parte pueda ser manejada por un equipo

Entonces Scrum es el camino a seguir (por supuesto, si también necesita ágil).

Los escenarios de múltiples equipos y múltiples proyectos con altas interdependencias requieren sincronización entre los equipos. La gestión de proyectos de cadena crítica es un libro de jugadas para tal escenario. Úselo cuando sea necesario, pero no juegue con él si no lo necesita.

Eso dijo:

La estimación ágil de tareas es tosca; puede asignar esto a la estimación del búfer. La popular serie modificada de Fibonacci, por ejemplo, le daría aprox. 30 % del tamaño del búfer. Asigne esto a la cantidad de sprints que necesita para completar una "tarea". Por ejemplo: el equipo A necesitará 3 sprints para entregar la función X: agregue un búfer de un sprint para calcular la fecha límite.

Puede reevaluar periódicamente las dependencias en retros de sprint entre equipos o similares, volver a planificar su red de tareas y, por lo tanto, actualizar las expectativas de fecha límite de los búferes.