@ Joe "Somos una tienda" ágil ", así que entiendo que se supone que debemos ajustar y qué no, pero a veces el cambio es grande y nada trivial".
Si su proceso no le permite controlar la tasa de cambio en los requisitos, su proceso no es ágil, sino fortuito. Ágil no significa "tomar cualquier cosa que se me presente".
Para controlar el cambio o el desplazamiento de requisitos, puede adoptar, en su proceso, la noción de que un requisito no cambia (una noción de que está en el corazón de Scrum). Trate un cambio de requisito como el reemplazo de un requisito anterior por uno nuevo. Debe tener una acumulación de requisitos, y debe hacer que el usuario elija cuáles quiere implementar.
Querías X e Y en dos semanas, pero de repente quieres Z. Bueno, entonces puedo entregarte los tres en 4 semanas. O puedo dar un par (X y Z) o (X e Y) o (Y y Z) en dos semanas y entregar el restante más tarde. Escoger.
Así es como negocia con los clientes. Así es como se comunica el costo del cambio de requisitos. Si su grupo no tiene ese poder, no está en una tienda ágil y no hay nada que pueda hacer al respecto. Apesta, pero es verdad.
En caso de que pueda negociar, debe realizar un seguimiento (con precisión) del tiempo que lleva implementar los requisitos y los cambios de requisitos. Es decir, debe recopilar estos datos de proyectos pasados y presentes.
Recopila la estimación de tiempo original y el tiempo de finalización real (además de recursos como el recuento de desarrolladores) por solicitud (o módulo afectado por N solicitudes). Mejor aún, calcule el tamaño del cambio de solicitud / solicitud (en términos de líneas de código o puntos de función en proyectos y solicitudes anteriores).
Digamos que tiene una métrica con la que puede hablar con el usuario. Usted sabe que una nueva solicitud tomará, por ejemplo, 1K líneas de código o 10 páginas web con un promedio de 5 campos de entrada cada una (50 puntos de función).
Luego, al observar datos históricos específicos de sus proyectos anteriores (algunos por líneas de códigos, algunos por páginas web, otros por puntos de función reales), y puede estimar cómo cada uno de estos cuesta en términos de tiempo de finalización absoluto. Para aquellos con datos suficientes, también puede identificar aquellos requisitos que rastrean un recuento real de desarrolladores.
Luego usas eso y le dices a tu cliente que basado en datos históricos; Usted argumenta que las fallas del proyecto tienden a seguir una distribución exponencial; y luego está armado con el siguiente argumento para su cliente:
Según los datos de nuestros proyectos pasados y presentes y los recursos disponibles, el requisito que usted solicite tomará
X cantidad de tiempo para completar con un 25% de probabilidad de falla (o 75% de éxito)
1.5 * X cantidad de tiempo para completar con un 5% de falla (o 95% de éxito)
0.5 * X cantidad de tiempo para completar con un 95% de falla (o 5% de éxito)
La probabilidad de falla en función de la cantidad de tiempo que los recursos suelen ser del 95%, 25% y 5% (similar a una distribución exponencial). Transmite el mensaje de que una cierta cantidad de referencia ofrece una posibilidad de éxito algo decente (pero con riesgos reales ) 1.5 de eso podría dar casi una cierta posibilidad de éxito con un riesgo mínimo, pero mucho menos que eso (0.5 del original garantiza un fracaso casi seguro).
Dejas que digieran sobre eso. Si todavía van por la propuesta arriesgada (¡ hecho ayer! ) Al menos tienes por escrito que se lo dijiste. Si existe la esperanza de que su grupo no solo sea ágil sino también ingeniero, entonces el cliente podría considerar seriamente sus números y programar esta y futuras solicitudes en consecuencia.
Es su trabajo como ingeniero explicar en términos ingeniosos, verificables y claros que solicitar cambios no son una comida gratis.