¿Cómo hacer que la planificación de lanzamiento sea más precisa?

No en vano, escucho mucho esa pregunta. El problema básico con la pregunta es que Agile no está de acuerdo con la idea fundamental de un proyecto de alcance fijo/línea de tiempo fija. En la pregunta que le hicieron, existe la suposición de que la fecha de finalización de un alcance establecido se puede conocer y el problema es que somos malos para conocerla (estimar). Eso no es realmente cierto. La fecha de finalización de un ámbito dado no es un punto conocido en el tiempo. Más bien, es un punto de cambio en el tiempo.

La mejora de las capacidades del equipo, la comprensión de las necesidades de los usuarios y una comprensión más sofisticada de la implementación a medida que avanza el proyecto en realidad mueve esa fecha.

Mire este video de Henrik Kniberg de 11:25 -> 14:45 (todo el video es excelente, pero esta parte es más relevante para esta pregunta). Hace un gran trabajo hablando de pronósticos y puede usar esto con los resultados de la Planificación de lanzamiento.

Puede ver que puedo establecer la fecha de finalización de su proyecto cuando lo desee si la fecha límite es lo que es realmente importante o podemos extender la fecha cuando el alcance esté terminado si eso es lo importante, pero configurar ambos es solo una suposición y una apuesta.

Sergey, los pasos que describe harán que su planificación de lanzamiento sea más precisa, pero no mejorarán la precisión. No caiga en la trampa de pensar que tener un proceso detallado y explícito durante la planificación del lanzamiento mejorará la precisión.

Es una trampa en la que estamos predispuestos a caer porque, como humanos, buscamos crear una sensación de control donde no lo hay. La única forma de hacer que la planificación del lanzamiento sea más precisa es realizar la planificación más cerca de la fecha de lanzamiento. De hecho, si haces la planificación el día del lanzamiento, tendrás una precisión muy alta ;).

Como Daniel hace un gran trabajo al explicar, Agile no está de acuerdo con el concepto de tiempo fijo/alcance fijo y respeta el hecho de que simplemente no podemos estimar con un alto grado de precisión al comienzo de un proyecto. Debe preguntarle a su gerencia qué tiene de especial la marca de desviación del 30 %.

Lo mejor que puede hacer durante la planificación del lanzamiento de Agile es:

• Asegúrate de tener a las personas adecuadas en la sala
• Planifique a menudo en ráfagas más pequeñas y enfocadas
• Aceptar que el plan cambiará
• Sea explícito acerca de cualquier suposición

Parece que sus entrevistadores estaban definiendo un "plan de lanzamiento" como un escenario de alcance fijo y fecha fija. Una forma sencilla de mejorar la precisión de esos planes en al menos un 30 %.

Respuesta sencilla

• Reduzca drásticamente los estándares de calidad según sea necesario para cumplir con el plazo

Hablando en serio, esto suena como una pregunta engañosa para un taller que ejecuta Scrum. Los proyectos de fecha y alcance fijos están casi condenados al fracaso para proyectos de cualquier complejidad apreciable (consulte Stacey Matrix a continuación para ver una ilustración de 'complejidad').

Es posible que pueda argumentar que los procesos o metodologías predictivos se pueden superponer a proyectos más simples o incluso complicados; sin embargo, la mayor parte del desarrollo de software está definitivamente en el rango complejo. Para obtener más información, consulte Cynefin Framework para obtener buenas definiciones de simple, complicado, complejo y caótico.

Así es como podrías haber respondido esa pregunta

Primero, rompería la fecha fija y la disfunción del alcance; lanzaríamos en una fecha particular pero flexionaríamos el alcance de lo que lanzamos o lanzaríamos cuando se completara un alcance particular del trabajo. Además, el equipo de desarrollo se encargaría de desarrollar software de alta calidad y baja deuda técnica para que las versiones futuras no se ralentizaran o se hicieran cada vez más impredecibles debido a malas decisiones técnicas y recortes.

La Guía Scrum dice:

Scrum se basa en la teoría de control de procesos empíricos, o empirismo. El empirismo afirma que el conocimiento proviene de la experiencia y de la toma de decisiones en base a lo que se sabe. Scrum emplea un enfoque iterativo e incremental para optimizar la previsibilidad y controlar el riesgo. Tres pilares sostienen toda implementación de control empírico de procesos: transparencia, inspección y adaptación.

Para garantizar que la confiabilidad de los planes de lanzamiento mejore en un 30 %, insisto en que los equipos de desarrollo permanezcan lo más inalterados posible durante el transcurso del lanzamiento. Esto aumenta la estabilidad en el sistema y aumentará potencialmente la productividad en gran medida en comparación con los equipos que se reforman con frecuencia.

A continuación, trabajaría con el equipo para formar pronósticos basados ​​en su progreso observado hacia el alcance (o la fecha) del lanzamiento después de 2 o 3 sprints del nuevo ciclo de lanzamiento. Este período de 2-3 sprints garantiza que se utilicen algunos datos significativos y empíricos para formar el pronóstico.

Por último, mantendría visualizaciones significativas del progreso de los equipos, teniendo en cuenta su rango colectivo de "cono de incertidumbre" para proporcionar estimaciones actualizadas a las partes interesadas a medida que surjan nuevos datos. Usaría matemáticas básicas como la " Calculadora de rango de velocidad " de Mike Cohn para estimar con precisión qué alcance se completaría dada una fecha o en qué fecha se completaría un alcance determinado.

Evitaré entrar en la comparación con un plan de lanzamiento de fecha fija y solo daré algunas sugerencias sobre cómo mejorar las estimaciones de las historias de los usuarios y las tareas relacionadas (una vez que sepa cuánto toman y la velocidad del equipo es bastante sencillo ver qué alcance puede lograrse en una versión determinada).

• Dividir las historias más grandes ; las historias/tareas más pequeñas son más fáciles de estimar
• puedes usar puntos de historia en lugar de unidades de tiempo (horas-hombre, días-hombre, ...), es decir, números sin unidad y si los relativizas será más fácil: puedes comparar historias similares (es decir, dos -la historia de un punto debería tomar el doble de tiempo que una historia de un punto) - las personas se sienten más cómodas haciendo estimaciones relativas que haciendo estimaciones absolutas.
  podrías comenzar averiguando cuál es la historia más pequeña, una que puede hacer una persona en aproximadamente un día o medio día, y lo estimas como 1. Luego procedes con todas las demás historias de manera relativa.
• Aún más sofisticado es utilizar números derivados de la serie de Fibonacci : 1,2,3,5,8,13,21,… (cada número es la suma de los dos anteriores). Esta serie especial tiene la ventaja de que los números aumentan exponencialmente y esto refuerza el concepto de que más grande es una tarea más compleja que se implementará y se debe dividir.
  Incluso puedes crear tu propia serie (simplificada), como 1,2,3,5,10,20,40,100. ​ El rango inferior (hasta 10) está diseñado para ayudar a los equipos a estimar cosas pequeñas que entienden bien con mayor precisión. Sin embargo, el rango superior tiene números crecientes, lo que refleja una mayor incertidumbre. ​ Si las estimaciones alcanzan este rango, significa que la historia es demasiado grande para una iteración, representa un riesgo sustancial y debe dividirse.
• Por lo general, quien se ofrece como voluntario para la tarea puede estimarla. Esto supone que el voluntario sabe de qué está hablando, pero muy a menudo se obtiene un resultado sesgado, que al final puede resultar bastante erróneo.
  En lugar de colocar toda la carga y la responsabilidad de una estimación sobre los hombros de un individuo , las estimaciones son propiedad de los equipos.
  ​El enfoque aceptado para hacer esto es usar estimaciones de 3 puntos y hacerlas converger como un equipo . Técnicas como Wide Band Delphi proporcionan técnicas para combinar múltiples estimaciones con la imprecisión asociada.
  Un poco más sofisticado sería preguntar a todos los miembros del equipo y hacer un promedio. Podría haber variaciones en esto como quitar del promedio el más alto y el más bajo
• Otra posibilidad sería el llamado póquer de planificación : para cada tarea, todos en el equipo deciden un valor de estimación y luego todos juntos presentan su valor. El más bajo y el más alto explican por qué piensan así y luego el proceso se repite hasta que los miembros convergen en un valor común.
  La gran ventaja de este proceso es que el valor viene como si fuera de todo el equipo.
• Mantenga un conjunto histórico de elementos completados para la revisión
• Dedique parte del enfoque retrospectivo a la diferencia entre los objetivos de liberación y las estimaciones y comprenda de dónde proviene.
  Concentre el esfuerzo de estimación en el área en la que existe la necesidad más clara (como donde la diferencia entre el resultado esperado y el resultado fue mayor o áreas particularmente inciertas).
• Planifique picos (iteraciones de investigación dedicadas) para áreas de incertidumbre
• En cualquier lanzamiento, muchas cosas pueden salir mal para invalidar la estimación. Esta variabilidad se magnifica a gran escala (más o más equipo, ciclos más largos). Los estimadores pueden modelar sistemas estocásticos (probabilísticos), como el trabajo de desarrollo mediante el uso de simulaciones de Monte Carlo . Con un modelo de este tipo para la duración del lanzamiento, puede incluir el impacto de muchos elementos de variabilidad o riesgo, incluido el cambio de alcance, el desgaste y la larga enfermedad. Es especialmente útil en desarrollos muy grandes y de larga duración y en proyectos de precio fijo y duración fija.
  Tom DeMarco creó un archivo de Excel para la simulación de Monte Carlo llamado Riskology que es de libre acceso.

Pero ojo con la discusión: demasiada precisión puede perjudicar.
Pasar demasiado tiempo generalmente no aumenta la precisión de las estimaciones (¡y aburre al equipo!). Pasar demasiado tiempo estimando es realmente una forma de desperdicio. Al final, los equipos deben tener cuidado de cronometrar sus estimaciones y no intentar convertir esta heurística en una pseudociencia.

Hacer que la planificación de lanzamientos sea más precisa significa tener en cuenta las siguientes precauciones: Sin embargo, no puede evitar considerar un colchón del 15 al 20 %.

1. Comprenda los recursos y sus niveles de eficiencia [Esto es posible solo si está trabajando con el equipo durante mucho tiempo]

2. Mantener una ficha sobre las iteraciones y el control de calidad. [Esto es posible si se mantiene la comunicación y la disciplina con las partes interesadas].

3. Vigilando la próxima tecnología [Nunca se sabe qué puede hacer que su vida sea más fácil o más difícil]

4. Revisiones y Desarrollo manteniéndolos de la mano. [Mantener un control de calidad óptimo y ciclos de revisión]

5. Vigile de cerca los movimientos de la competencia [La evaluación continua de los desarrollos de la competencia lo mantendrá a la vanguardia en la visión del producto. Conozco algunos productos que fueron a las pizarras blancas después de que la competencia publicara contenido increíble.]

6. Haga una división de funciones con capacidad de alcance. Y priorice los más importantes en TOP.

Parece que estás en un entorno de baja confianza.

Si se encuentra en un entorno de baja confianza, debe realizar toda la planificación necesaria para comenzar. Una vez que comience y entregue, comenzará a crear confianza y erosionará la necesidad de una planificación tan detallada por adelantado. Tu respuesta es la única viable.

Esto es tan típico de las grandes organizaciones al comienzo de una transformación ágil, o estancada, que hay una sección completa sobre esto en la Capacitación profesional de Scrum.

Está la ideología, el entorno ideal de scrum, y luego está la realidad de su disfunción organizacional. Como esta organización parece necesitar trabajo y esfuerzo serios para seguir avanzando hacia la agilidad, debe preguntarse si ese es el esfuerzo que está dispuesto a contribuir.

Por mi parte, me encantan los desafíos...

Completamente de acuerdo con lo que dijo @Daniel y podría agregar un poco más: si el entorno (como distracciones no planificadas, horas de trabajo aproximadas disponibles, ...) es constante, entonces con el tiempo el equipo se dará cuenta de sprint velocityque eso solo podría ayudar a estimar qué tan rápido un La historia puede ser entregada. Esto no es un contrato sino solo una estimación.

Y las estimaciones de las que estamos hablando son un máximo de días de hasta un período de sprint, no meses como se puede ver en la cascada.

Cuando agrega continuous deliverya Agile, ni siquiera necesita (o mejor, no tiene sentido) crear estimaciones, ya que las historias van y vienen de la acumulación con casi minimal lead time. Con la entrega continua, puede tener varios lanzamientos todos los días. Sin embargo, esto funciona con productos basados ​​en software y es posible que no se aplique directamente a ningún otro tipo de productos.