Contabilización del crecimiento del alcance en el desarrollo ágil

Medir el trabajo. Como dices, trabajas en muchos proyectos diferentes. Teniendo en cuenta que recopila datos relevantes sobre proyectos anteriores, debería poder ver algunos patrones, por ejemplo, la mayoría de los proyectos parecen funcionar de esta manera, pero hay casos no estándar que fueron impulsados ​​por una cosa u otra.

Es difícil responder qué aporta variabilidad a su trabajo, pero es probable que pueda encontrar fácilmente las causas principales.

Otra idea que te puede gustar es dimensionar no en términos de estimar cuánto tiempo necesitas para construir un proyecto, sino cuántas características/historias/qué necesitas para construirlo . Ser capaz de estimar que un nuevo proyecto tiene aproximadamente 40 funciones puede brindarle mucha información, siempre que sepa cuánto tiempo se tarda en crear una función promedio (de extremo a extremo) y cuántas funciones tiene en progreso al mismo tiempo. Vea un ejemplo de tal enfoque aquí .

Una vez más, se reduce a medir su trabajo. Otro sabor importante aquí es la comprensión de la variabilidad. Quiero decir, si el tiempo necesario para construir un elemento de trabajo varía mucho, por ejemplo, entre 2 y 50 días, el promedio o la mediana no le dirán mucho a menos que tenga una muestra realmente grande de registros anteriores .

Y finalmente, si puede trabajar con sus clientes a tiempo y materialmente, simplemente elimina el problema de la mesa. En tal situación, solo compran su tiempo (junto con sus habilidades) y no es su riesgo directamente cuando surge algo nuevo.

Lee sobre el Cono de Incertidumbre : cuanto más tiempo trabajes con el proyecto, más exacta y precisa será tu estimación de su duración y tamaño (imagen del sitio web Construx.com ):

PMBOK sugiere volver a estimar el proyecto cada vez que tenga más información sobre su alcance. Comienza un proyecto con una estimación de ROM ( Orden de magnitud aproximado) y lo refina en cada hito. También sugeriría leer "Software Estimation: Demistifying the Black Art" de Steve McConnel, que brinda un buen resumen de las técnicas de estimación existentes.

Pawel habla de medir tu trabajo. Esto es crítico y clave. Una de las razones es que mirar hacia atrás puede ayudarlo a mirar hacia adelante.

Hay un término, que se usa a menudo en ágil, llamado "El clima de ayer". El concepto es que el clima de hoy probablemente se parece mucho al clima de ayer y se parecerá mucho al clima de mañana (si alguna vez has ido a Los Ángeles, CA, EE. UU., esto es aterradoramente cierto). Por lo general, esta máxima se usa para determinar la velocidad potencial de un equipo ágil. Si hizo 30 puntos en la última iteración, entonces probablemente hará unos 30 puntos en esta, así que no se exceda.

El concepto puede extenderse más allá de esto. Si realiza un seguimiento de sus proyectos, en el transcurso de varios proyectos puede comenzar a ver cuál es la norma para usted. Verás, ninguna fórmula va a resolver el problema. Las personas no son fórmulas matemáticas. Así que no podemos conectarnos fácilmente con fórmulas universales. Lo que podemos hacer, sin embargo, es mirar nuestra propia historia. Después de hacer varios proyectos, probablemente encontrará que hay algunas normas que puede observar para determinar cuánto cambio tiene desde el inicio del proyecto hasta el lanzamiento.

Utilice sus propias métricas para determinar su propio potencial.

Agile generalmente evita las dificultades de saber cuándo se realizará una gran parte del trabajo al no comprometerse a hacerlo.

Si tiene un trabajo de seis meses (basado en una estimación de un dedo en el aire), elija una pequeña parte que le dará valor al hacerlo primero. Por lo general, es más fácil tener una idea de cuánto tiempo llevará una pequeña cosa que una gran cosa y la publicación temprana le permite obtener comentarios de los clientes rápidamente.

Lo más probable es que, una vez que haya hecho una o dos de estas pequeñas porciones, obtendrá buenos comentarios que guiarán el resto del trabajo. No entregue obstinadamente lo que pensó que era su alcance al principio, vuelva a priorizar constantemente los comentarios contra el resto de su alcance potencial.

Estamos cambiando la pregunta habitual de "¿cuándo podremos terminar?" con "¿qué es lo más pequeño que podemos hacer que agrega valor?".

Siempre que esté sopesando el valor de todos los trabajos posibles, podría comenzar uno contra el otro y asegurarse de no comenzar cosas que son demasiado grandes, en realidad no es tan importante obtener una estimación a largo plazo 'correcta', es por lo general una ilusión de todos modos.

Se pueden encontrar más pensamientos a lo largo de una pista similar aquí: http://decision-coach.com/lean-and-real-options/

Si mide el costo real de los proyectos (en tiempo) frente a la estimación inicial (en tiempo o en puntos) hasta la finalización/lanzamiento (~= 1/velocidad promedio de la acumulación del producto) en algunos de los proyectos del mismo equipo, debería ver que no No varían mucho entre proyecto y proyecto. Usando ese factor, puede obtener una estimación aproximada del tiempo real frente al tiempo estimado inicialmente para proyectos futuros con el mismo equipo.

El tiempo real incluye historias de usuario añadidas, eliminadas y modificadas.

Dado que el equipo da las estimaciones y hace el trabajo, es importante no mezclar velocidades entre equipos. Si recibe la solicitud de cambio de los clientes, intente comparar con proyectos del mismo cliente, ya que la elección del cliente afectará las mediciones (puede pensar que el cliente es parte del equipo ampliado).
Si ve una mejora con el tiempo, entre proyectos (por ejemplo, debido a que el equipo se acostumbró a trabajar juntos (o junto con el cliente) de manera más eficiente), dé más peso a los proyectos más recientes.

Para una estimación más segura, tome los factores mínimo y máximo (de proyectos anteriores) y utilícelos para trazar un cono de incertidumbre.