¿Qué técnicas (formales) de estimación de esfuerzo se usan comúnmente en los proyectos de desarrollo de software en estos días?

Gracias por el A2A.

Hay muchas técnicas reconocidas que puedes aplicar. Intento clasificarlos en dos grupos:

• Técnicas que se basan en abstracciones (como los puntos de la historia) para calcular el esfuerzo general
• Técnicas basadas en la estimación del esfuerzo puro

En los últimos años, la amplia adopción de los marcos ágiles llevó a muchos gerentes de proyecto a distanciarse de las estimaciones de esfuerzo, aunque en muchos contextos siguen siendo la mejor opción para redactar un plan de lanzamiento.

Estimación análoga (esfuerzo)

También conocido como “Estimación del orden de magnitud”, es un enfoque muy eficiente para tener una estimación rápida de los requisitos de alto nivel: suponiendo que pueda acceder a los puntos de referencia de proyectos anteriores, recomienda que todos los requisitos se estimen en función de características similares ya entregadas .

Evaluar si el nuevo requisito es más simple o más complejo que la referencia permite aumentar o disminuir el punto de referencia. Por ejemplo, un requisito puede estimarse como un 20% más complejo que un requisito similar que se entregó en 20 días-hombre en otro proyecto, lo que significa que la estimación del nuevo requisito es de 24 días-hombre.

Pros: es rápido y no requiere mucho esfuerzo.

Contras: depende de datos históricos y, en parte, de la opinión de expertos.

Estimación de rango (esfuerzo)

El hecho de que las estimaciones de esfuerzo en última instancia solo ofrezcan un número único que represente todo el proyecto (el esfuerzo total) es posiblemente lo que más odian las personas. No hay lugar para errores y esto establece expectativas erróneas. Las técnicas de estimación de rango tienen como objetivo mitigar este problema.

En las estimaciones de tres puntos, todos los requisitos tienen 3 valores: el mejor de los casos, el peor, los escenarios más probables. El esfuerzo se estima como la media aritmética de estos tres valores:

[matemáticas] E = \ frac {a + b + c} {3} [/ matemáticas]

O una media ponderada (según las preferencias):

[matemáticas] E = \ frac {a + 4m + b} {6} [/ matemáticas]

La suma de la estimación de todos los requisitos nos dará el esfuerzo total, mientras que la desviación estándar total (σ) nos dará un nivel de certeza. Por ejemplo, existe una confianza del 95% de que los requisitos se pueden cumplir en el tiempo calculado como el esfuerzo total más o menos dos veces la desviación estándar, es decir, dentro del rango representado por:

[matemáticas] E_ {tot} ± 2 \ sigma [/ matemáticas]

Aún más interesante (al menos para mí) es la simulación de Monte Carlo : dados dos escenarios para cada requisito, la simulación elegirá un valor aleatorio entre esos dos escenarios para cada requisito, un número suficientemente alto de veces para resaltar lo que es más probable resultado del proyecto, y la desviación estándar lo convierte en un rango con un nivel de confianza, como en las estimaciones de tres puntos.

Pros: muy útil si no tiene datos históricos y desea un nivel de confianza.

Contras: solo proporciona el esfuerzo total como un rango, no se puede realizar ingeniería inversa para resolver el esfuerzo para un solo requisito.

Puntos de historia (abstracción)

Creo que este punto fue abordado muy bien por Chuck Cobb. Obtienes una estimación en Story Points para cada requisito. El número total de Puntos de historia dividido por la velocidad de referencia del equipo te dará una cantidad de Sprints y, en consecuencia, el esfuerzo total.

Pro: estar basado en una abstracción no sufre los inconvenientes de las técnicas de estimación de esfuerzo y no depende de la antigüedad de las personas que estiman.

Contras: necesita un punto de referencia, para el mismo equipo, para la misma longitud de Sprint.

Espero eso ayude.

Jeje, usted formuló la pregunta de tal manera que insinúa proyectos de desarrollo de software fallidos. Dejame explicar…

Las técnicas (formales o informales) que usan los desarrolladores para la estimación son las únicas técnicas confiables. Solo las personas que realizan el trabajo de desarrollo pueden estimar el esfuerzo. Y cualquiera que sea la técnica que usen, al final cada técnica se basa en un sentimiento o experiencia instintiva de los desarrolladores.

Pedir técnicas de estimación formales para que la alta gerencia apruebe problemas de hechizos , a lo grande. Porque la gerencia, incluso si tienen buenas intenciones, no saben nada sobre el trabajo que se realiza; sí, ¡incluso si ellos mismos son desarrolladores! Solicitarán técnicas que obliguen a los desarrolladores a hacer más o menos trampa y mentir (incluso a sí mismos).

¡Una buena administración dejará las técnicas de estimación y estimación a los chicos que hacen el trabajo! Porque esa es la única forma de llegar a estimaciones realistas. Y recuerde siempre: las estimaciones son solo estimaciones. Incluso si los desglosa en tablas de Excel, agrúpelos y póngalos en plazos de entrega sofisticados: son conjeturas y no debe confiar en que sean una predicción del futuro.

Realmente no puedo agregar nada a lo que Chuck Cobb ha dicho.

Los puntos ágiles de la historia son la mejor manera que he encontrado para estimar el esfuerzo requerido. El secreto es no obsesionarse demasiado si una historia dada es una historia de 3 puntos o una historia de 5 puntos. Utilizamos los números de Fibonacci para nuestras estimaciones. Las historias valían 1, 2, 3, 5, 8, 11 o 19 puntos.

La ventaja de los puntos de la historia es que puedes seguir la velocidad a medida que avanzas. Si su proyecto tiene 120 puntos de historia y estima que puede completar 20 puntos de historia por sprint de dos semanas, puede proyectar que el proyecto tomará (120/20) * 2 = 12 semanas. Si su velocidad en realidad es de 12 puntos de historia por semana, puede volver a estimar rápidamente el proyecto a (120/12) * 2 = 20 semanas.

Si la gerencia insiste en el plazo original de 12 semanas, tiene datos sólidos para insistir en que aumentan el tamaño del equipo o disminuyen el alcance del proyecto. Esto evita el mayor problema que tiene la administración con otras técnicas de estimación: la sorpresa de última hora, cuando se ha consumido tiempo o presupuesto y sin previo aviso, el proyecto no está completo. Se advirtió a la administración con anticipación que si ELLOS no tomaban medidas, era culpa de la ADMINISTRACIÓN que el proyecto llegara tarde.

A lo largo de los años, he utilizado varias técnicas de estimación, pero ahora me decidí más o menos por la estimación relativa. Para las historias de los usuarios, prefiero la serie Fibonacci y para el tamaño de la camiseta.

Autor: El Manifiesto Ágil en inglés

Blog: Agile, Scrum, Kanban, Arquitectura de soluciones

Twitter: @tjain