¿Existe un sistema de calificación estándar para la estimación de tareas de desarrollo de software?

Aquí en RubyGarage combinamos varios enfoques de estimación para proporcionar a nuestros clientes estimaciones exactas de los proyectos. El proceso de estimación del desarrollo del sitio web consta de cinco pasos:
Paso 1. Obtención de requisitos. Para empezar, es muy importante comprender el concepto del producto, el público objetivo, sus problemas y soluciones para ellos. Le pedimos la lista de todas las características que desea en su sitio y la lista de productos de la competencia.

Paso 2. Funciones de descomposición. Siempre descomponemos las funciones que dividen las tareas grandes en muchas más pequeñas con la ayuda de la siguiente estructura: Epics – User Stories – Use Cases.

Paso 3. Estimación análoga. Esta técnica utiliza una medida de un proyecto similar anterior para estimar el costo y la duración del proyecto actual. Confiar en la experiencia previa garantiza estimaciones más precisas, pero solo podemos usarlo si las tareas son muy similares a las del proyecto anterior.

Paso 4. Estimación del juicio de expertos. Los expertos iteran la estimación del juicio hasta el consenso. Investigan las características estimadas, aclaran el alcance del trabajo, descomponen tareas y estiman la cantidad de horas necesarias para la implementación.

Paso 5. Finalizar la estimación. El gerente de proyecto obtiene una estimación final con la ayuda de los resultados de estimaciones de juicio análogas y expertas.

En RubyGarage estimamos proyectos de desarrollo de aplicaciones utilizando los llamados Story Points . Esa técnica de medición ofrece beneficios para desarrolladores y clientes. No depende de quién está implementando la historia, y todos los miembros del equipo, con diferentes habilidades, pueden discutir la estimación juntos. Todo el equipo puede entender claramente el tamaño y la complejidad de la historia. Además, la velocidad es un poderoso método de planificación de capacidad y el equipo puede aumentarlo con la ayuda de Story Points y no necesitará volver a estimar su proyecto si la velocidad cambia. Los puntos de historia han adquirido una reputación; son estables e independientes de la habilidad o experiencia de los miembros del equipo; te permite seguir la velocidad de un equipo; y ayudarlo a mantenerse flexible en la planificación de las fechas de lanzamiento del proyecto.

Para obtener más información sobre cómo calcular la tarea de desarrollo de software, puede leer el artículo “Cómo calcular con precisión el costo y la duración del proyecto” aquí:
Cómo estimar con precisión el costo y la duración del proyecto
Si desea leer sobre Story Points, lea los artículos “Cómo estimar con Story Points” y “3 razones para estimar con Story Points” aquí:
https://rubygarage.org/blog/how-…

Existen diferentes métodos para lograr algo como lo que usted describió. Los métodos como COCOMO, Puntos de función (FP), Puntos de caso de uso (UCP) y otros similares se basan en la especificación de diferentes partes de una tarea y luego agregan sus estimaciones para que lleguen a una en general.

Son diferentes en lo que usan para estimar el tiempo (FP usa la complejidad de la función mientras que UCP usa el número de casos de uso / actores / etc.), pero al final tienen el mismo principio detrás.

Sin embargo, la estimación del software es un problema bastante complicado (consulte ¿Por qué las estimaciones de las tareas de desarrollo de software se desactivan regularmente en un factor de 2-3? Y http://dannorth.net/2009/07/01/t …) y han recorrido un largo camino ya que estos métodos fueron propuestos, especialmente con el surgimiento de metodologías ágiles para desarrollar software. En el contexto ágil (que incluye XP, Scrum, Kanban, etc.), la estimación se basa más en datos históricos y en la estimación de la complejidad que en la estimación real del tiempo necesario para una tarea.

Entonces, en lugar de tener una tarea, dividirla y estimar el tiempo necesario para cada tarea, los equipos estiman la complejidad de una tarea (en una unidad comúnmente llamada Story Point) y observan los datos para ver cuánto tiempo llevó realizar una tarea similar. complejidad. Por ejemplo, si la tarea B es de complejidad media y nuestro equipo tardó 2 días en resolver la tarea A, que también fue de complejidad media, creemos que tomará algo cerca de 2 días nuevamente para realizar la tarea B. Un buen recurso para buscar estimaciones ágiles es el libro de Mike Cohn ( http://www.amazon.com/Agile-Esti …).

Otra idea que ha ido en aumento en el pasado reciente no es estimar las tareas en absoluto, sino crear tareas de tamaño similar, que luego terminarían teniendo un tiempo similar para completar. De esta manera, el esfuerzo de estimación desaparece por completo, convirtiéndose en un simple ejercicio de contar cuántas tareas quedan. Se puede ver más sobre este tema aquí: http: // softwaredevelopmenttoday ….

Si bien todos los métodos ágiles no son extremadamente precisos, la precisión no es lo que las partes interesadas generalmente buscan en una estimación. Lo que se necesita es suficiente confianza para tomar decisiones comerciales que involucrarán la coordinación con otras personas fuera del equipo. Desafortunadamente (o no), el desarrollo de software es un área muy compleja, por lo que su estimación tiene un cierto grado de incertidumbre, e intentar eliminarlo utilizando métodos muy científicos resulta en más problemas que la alternativa en mi opinión.

Escribí un poco más sobre eso aquí: http://blog.franktrindade.com/20