La junta del proyecto quiere estimar las epopeyas con puntos de historia y luego dividir esas epopeyas en historias más pequeñas donde todos los puntos se suman a la historia principal. La variación en estimaciones posteriores es punible.
Si realizo una sesión de estimación para una docena de grandes historias épicas usando números bastante grandes, 20 puntos y más, este número resulta en 400 puntos. Más tarde divido esas epopeyas en historias más pequeñas y las estimo por un incremento. Estoy bajo la presión de la junta de mi proyecto para tener muy poca variación en estas estimaciones posteriores. Por ejemplo, todas las historias más pequeñas deben sumar la estimación de su epopeya "principal", y todas las historias más pequeñas deben seguir sumando 400.
Tengo mis propios puntos de vista sobre esto, pero me pregunto:
¿Qué hacen otras personas en estas situaciones? Estoy más que feliz de aclarar cualquiera de los puntos si ayuda.
La variación aquí es punible.
Eso es desafortunado. Es inminente que será sancionado porque es seguro que habrá variaciones. Esperar o intentar tener una varianza cercana a cero, o una varianza cero, es sugerir que es posible que podamos predecir el futuro con precisión y precisión... cosa que no podemos. Estimaciones precisas es un oxímoron.
Primero, debe comprender que existe una diferencia real entre una estimación y sus valores de planificación. Una estimación es SIEMPRE un rango y su valor de planificación es el número en el que se cuelga el sombrero. En otras palabras, estima que esta tarea tomará de 10 días a 25 días. Su valor de planificación es de 19 días. ¿Ver la diferencia?
Su objetivo aquí es elegir un valor de planificación en el que la mayor parte de su probabilidad esté detrás de usted y no delante de usted, pero en el que no acumule demasiada grasa desperdiciada. La elección debe ser coherente con la tolerancia al riesgo de su organización. Dado que se encuentra en una cultura de varianza cero, eso implica que no hay mucha tolerancia al riesgo, por lo que estará en el lado gordo de sus estimaciones. Es caro pero seguro operar de esa manera.
Pero creo que su verdadero desafío aquí es capacitar a su organización sobre las realidades de la estimación, los riesgos aleatorios y la expectativa poco realista de esta noción de varianza cero.
En un proyecto determinado, las estimaciones deberían mejorar a medida que el equipo de experiencia adquiere experiencia y conocimiento del proyecto en particular. Esto hará que la estimación cambie. A medida que desglosa las cosas, debería obtener mejores estimaciones que pueden o no ser iguales a la estimación del paquete más grande. Si hay poca tolerancia para la variación de la estimación del original, es posible que desee proporcionar estimaciones escaladas a la junta del proyecto. Realice un seguimiento de los totales reales para que esté al tanto de lo que oculta la escala. Si está ocultando un retraso en el cronograma o si la variación es alta, cuanto antes se aclare, mejor.
En muchas industrias, es posible planificar con mucha precisión. Cuando está construyendo otra unidad cuando ha construido cientos, miles o millones antes, es fácil estimar con precisión cuánto tiempo llevará. En estos casos, se repite un proceso conocido y no se requiere diseño, experimentación o reelaboración. La prueba, si es necesario, es para garantizar que se mantenga la calidad y rara vez da como resultado una repetición del trabajo.
La creación de software es un proceso completamente diferente. A menos que tenga un proceso deficiente, cada unidad consta principalmente de diseño, experimentación, prueba y reelaboración. Todos estos pasos son difíciles de predecir.
Al final, debería construir componentes únicos. Estos no tienen la certeza de tiempo que se encuentra produciendo la siguiente unidad de una serie.
Pregunte a la junta del proyecto si aceptarían una falta de variación similar en el tiempo que dedican a su tarea.
Las respuestas dadas hasta ahora son buenas. Agregaría una cosa: trate todas las estimaciones como inmutables.
Nunca actualizas una estimación. Usted crea una nueva estimación.
Nunca hay "la" estimación.
Hay "las estimaciones" y "la estimación más reciente".
Sin embargo, dado que su junta ha vinculado la estimación con la recompensa y el castigo, han frustrado el propósito de la estimación y destruido la información. Realmente no importa qué política o proceso de estimación se utilice, porque la junta ha creado un incentivo negativo directo para subvertir todas las estimaciones.
Su estrategia más racional ahora es renunciar, la segunda estrategia más racional es involucrarse en actividades agresivas de sacos de arena, regateos, abogados y otras actividades de CYA.
Como para:
Por ejemplo, todas las historias más pequeñas deben sumar la estimación de su epopeya "principal", y todas las historias más pequeñas deben seguir sumando 400.
Esto no va a pasar. El efecto de desempaquetado muestra que las estimaciones, cuando se desglosan, crecen.
Su tablero está fuera de sus calabazas colectivas. Las estimaciones no son garantías, y la precisión de las estimaciones en cualquier proceso (pero especialmente en procesos iterativos como Scrum) es una función tanto de los requisitos de cambio inevitables como de un cono variable de incertidumbre.
El propósito de estimar épicas es brindar un resumen general del cronograma del proyecto y permitir que las historias se prioricen para lograr un valor óptimo para cada hito o fecha de envío objetivo.
Por la propia naturaleza de las épicas, el cono de incertidumbre es extremadamente grande y las estimaciones iniciales (que no son garantías) no tendrán la precisión de las estimaciones historia por historia que se realizan al inicio de cada Sprint.
La estimación del proyecto es una proyección y una guía para medir la varianza. El cronograma del proyecto puede y debe estar sujeto al mismo ciclo de inspección y adaptación que el resto de su proceso. Luego, la junta puede usar la Teoría de las Restricciones para ajustar el cronograma, el alcance o los recursos como mejor les parezca.
¿Están relacionados los puntos de la historia entre la estimación inicial y las sesiones posteriores?
Si y no. Idealmente, si bien puede haber una variación entre la proyección inicial y la entrega de funciones iteración por iteración, la variación debería estar dentro de un orden de magnitud razonable. Si no es así, lo cual no es una ocurrencia poco común, entonces es simplemente evidencia de que la estimación inicial fue incorrecta y debe revisarse.
Otra forma de ver esto es que la estimación inicial es una línea de base contra la cual identificará la varianza. Lo que elija hacer con esa variación depende de usted. En un proyecto Scrum bien dirigido, uno podría:
El verdadero problema aquí es cultural. Tiene un tablero de proyecto de comando y control que considera el desarrollo iterativo como una panacea. no lo es
La identificación de la variación es un resultado deseable de un control de proyecto eficaz. Castigar al mensajero no redunda en transparencia ni visibilidad; solo puede resultar en comportamientos CYA como:
El propósito de comparar su progreso actual con una estimación de programación inicial o actualizada es identificar esa variación. Si se castiga la discrepancia, no se identificará. QED
"La variación en las estimaciones posteriores es punible".
¡¡¡¡AY!!!!
Hay muchas respuestas excelentes aquí, pero quiero centrarme en este tema, ya que este tipo de actitud acaba con los proyectos, los equipos y la productividad.
Estimar es exactamente eso... un estimado. No es un real. El mundo del desarrollo de software está lleno de complejidad e incertidumbre y esto debe ser aceptado por las empresas. La gerencia debe hacerse la pregunta de "¿Qué va a hacer para mitigar la estimación que excede?" En Scrum enseñamos a los equipos a no asumir riesgos que son por el negocio, estos son de tiempo, dinero, presupuesto.
Los equipos construyen software y esa es su habilidad. No son gerentes de proyecto, ni son los estimadores. Pueden ayudar a orientar las estimaciones, pero es simplemente eso.
A menudo desafío a la gerencia en torno a las ventas y los presupuestos. ¿Estiman con precisión sus cifras futuras de ventas y presupuesto al día? es NO ; entonces, si no pueden estimar como gerencia, ¿cómo demonios esperan que otras personas calculen con precisión?
Recomiendo contratar a un entrenador calificado para ayudar a educar a su gerencia sobre la estimación, ya que hay muchos, muchos factores que son demasiado importantes para discutir aquí. El entrenador debe ayudar a cambiar la mentalidad de sus gerentes.
andres claro