En mi trabajo actual, siento que tenemos muchos cambios de requisitos. Somos una tienda "ágil", así que entiendo que debemos ajustarnos y qué no, pero a veces el cambio es grande y nada trivial.
Mi pregunta es, ¿cómo comunicas efectivamente el costo del cambio? Debido a ser ágil, si un cambio es lo suficientemente grande, algo se caerá del sprint actual, pero por lo general solo se agregará la próxima vez. Dado que nuestro modelo es SaaS, el cliente final es efectivamente el negocio en sí, y saben que obtendrán la función de corte n semanas después.
Creo que a lo que estoy tratando de llegar es a la eliminación de una función que realmente no es nada para usar para la comunicación, ya que solo se retrasó por n semanas. ¿De qué otras maneras tiene que hacer que la empresa comprenda lo que cuesta un cambio?
Respuestas:
@ 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:
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.
fuente
Por lo que describiste, no tienes ningún problema. Piden un cambio y están dispuestos a esperar hasta que usted diga que se puede hacer o están dispuestos a posponer otra función. Parece un equilibrio entre: tiempo, recursos y requisitos.
fuente
Puede intentar establecer una edad mínima de una nueva adición / cambio (no aplicable a las correcciones de errores). Por ejemplo, no se pueden trabajar nuevos cambios hasta que tenga 3 semanas de antigüedad.
Tener una edad mínima de una tarea es bueno porque al principio, cada tarea parece ser extremadamente importante, pero si espera un tiempo, su importancia a menudo disminuirá significativamente. Dependiendo de su intervalo de tiempo, le dará al menos ese tiempo de estabilidad en las tareas en las que está trabajando.
Para realizar un seguimiento de la edad, permitiría que las tareas se agreguen a alguna lista, pero no se considerarían tareas en las que trabajar hasta que haya expirado ese período.
fuente
Este es un problema muy común, no importa cuán rápido avance un proyecto en términos técnicos, el cliente lo percibe como mucho más lento y se siente libre de cambiar los requisitos, ya que les gusta pensar que los desarrolladores no deben hacer mucho de todos modos.
Esta percepción defectuosa proviene de tres tareas principales de desarrollo que consumen tiempo y que los clientes nunca tendrán en cuenta adecuadamente:
Ninguno de los anteriores será entendido y contabilizado adecuadamente por los clientes finales.
Básicamente, lo que no tiene "vistas" (elementos GUI) no se ha hecho.
Llamemos a esto el teorema del projenix, jaja no es broma: D
fuente