¿Cuáles son los mejores métodos para la estimación de proyectos de software?

Gracias por el A2A. Veo que ya se han dado algunas respuestas.

Para ser sincero, yo mismo todavía no tengo una respuesta satisfactoria a esta pregunta.

Algunas observaciones, basadas en mi experiencia personal:

• Aunque el Análisis de puntos de función (FPA) afirma ser objetivo, a menudo hay tantas formas de interpretar el diseño / funcionalidad de una aplicación que, en mi experiencia, a menudo es muy subjetiva.
• Creo que la combinación de desglosar el trabajo que debe hacerse en partes pequeñas y hacer estimaciones de expertos con respecto a esas piezas pequeñas puede ser una muy buena manera de hacer una estimación. El método Delphi (Wideband delphi) es un método que se puede usar. Se describe como un proceso muy formal, pero también se puede hacer de una manera mucho más informal. Y de hecho, la planificación del póker está hecha, está muy inspirada en este método de estimación:
  – Pídale a un grupo de expertos que calcule el esfuerzo que se necesita
  – Haga que el experto con la estimación más baja y el experto con la estimación más alta expliquen sus razones y lo discutan con el grupo de expertos.
  Si es necesario, en función de los conocimientos adquiridos, realice una nueva ronda de estimación
• Es importante tener en cuenta que:
  – los gastos generales (reuniones, coordinación) a menudo no se consideran
  podría considerar usar un porcentaje fijo del tiempo total estimado para esto (por ejemplo, 15%)
  – Siempre habrá sorpresas y contratiempos. Determina cómo quieres manejar esos
  – puede ser útil determinar ciertos parámetros que lo ayudan a obtener información sobre los factores que determinan el tiempo necesario. Por ejemplo, la cantidad de campos en una pantalla, la cantidad de botones en una pantalla, la cantidad de tablas de la base de datos involucradas, las relaciones entre los datos que deben mostrarse en una pantalla, etc. Cuando usa parámetros, puede ajustar estima más adelante, cuando los parámetros cambian o puede ajustar el impacto de un determinado parámetro en la planificación si la experiencia muestra que toma mucho más tiempo (o menos) de lo estimado inicialmente

Nota adicional: para proyectos ágiles es cada vez más habitual estimar en mediciones aproximadas. Por ejemplo, una camiseta de planificación de historias de usuarios, usando Small, Medium y Large como categorías y determinar el contenido de un lanzamiento basado en la estimación del equipo en qué combinaciones de números de historias de usuario Small, Medium y Large encajarían.

Todo depende del tipo de proyecto que va a estimar. El mejor método para estimar el desarrollo de una tienda en línea no será bueno para una aplicación móvil. Puede haber un enfoque básico, pero de todos modos, durante cada procedimiento de estimación, variará las etapas y las direcciones de cualquier método.

Para evitar errores comunes durante el proceso de estimación y encontrar mejores soluciones para los futuros proyectos de software, consulte un artículo Cómo calcular con precisión el costo y la duración del proyecto.

Aquí, en Quora, me gustaría compartir un método que utilizamos en RubyGarage para una estimación del desarrollo del sitio web. Hay varios pasos

Primero, es importante que comprendamos el concepto de un producto, el público objetivo, sus problemas y las formas sugeridas para resolverlos. Recopilamos toda la información necesaria sobre un sitio web esperado.

Después de obtener toda la información que necesitamos, dividimos las tareas grandes en muchas más pequeñas. Descomponemos las tareas de acuerdo con la siguiente estructura: Epics – Historias de usuarios – Casos de uso. En la siguiente etapa, analizamos si teníamos una experiencia similar en la creación de dichos productos y transferimos las horas que nos llevó antes construir, por ejemplo, un sitio web. Confiar en la experiencia previa garantiza estimaciones más precisas. Pero podemos usar el enfoque análogo para la estimación solo si un producto anterior contiene tareas que son muy similares a las del proyecto que estamos estimando.

Si nuestros nuevos proyectos requieren características que aún no hemos desarrollado, adoptamos un enfoque de juicio experto para la estimación. Los expertos que confían en su experiencia para estimar proyectos de desarrollo de software llegan a un consenso y podemos finalizar la estimación.

Cuando un gerente de proyecto considera los resultados de estimaciones de juicio análogas y expertas y llega a una estimación final, presentamos esta estimación a nuestro cliente.

Para proyectos estándar, use técnicas de estimación de tiempo “estándar”, que serán adecuadas el 10% del tiempo, generalmente porque algo no es estándar después de todo …

Para los proyectos que involucran investigación, que tienen un resultado incierto o que usan tecnología que no ha sido probada exactamente, no recomiendo estimar cuánto tiempo llevará. Nunca se sabe. Las preguntas más importantes aquí son:

• ¿Todavía hay progreso?

• ¿Las personas adecuadas siguen trabajando en el trabajo?

• ¿Todavía creemos que es posible lograr nuestro objetivo?

• No: ¿el proyecto ya está terminado? Pero: ¿ya hay resultados que podamos usar para proyectos estándar?

Lo comparo con un artista en el escenario, por ejemplo, un acróbata. El acróbata puede realizar un espectáculo, que es un proyecto estándar. Durante el espectáculo, todo transcurre sin problemas, siempre y cuando se apegue a su plan. Probar nuevos trucos durante un espectáculo es peligroso.

Pero cuando el acróbata intenta mejorar su espectáculo, él repite cosas, una y otra vez. No está seguro de poder hacerlo. Pero al final, vale la pena probar cosas nuevas, porque de vez en cuando, se puede agregar un nuevo truco al programa. Un nuevo truco atraerá a nuevas personas a su espectáculo, y la gente volverá para ver todas las cosas nuevas, incluso si ya han visto el espectáculo antes.

En cuanto al desarrollo de software, cada desarrollador de software tiene implícita o explícitamente un conjunto de herramientas de cosas, bibliotecas, programas, lenguajes, paradigmas y marcos que se encuentran en el “nivel de rendimiento”. Con el kit de herramientas, se pueden componer soluciones, a veces en minutos.

Además del “nivel de rendimiento”, un programador también tiene un “nivel de referencia”, todo lo que sabe, pero tiene menos experiencia. El nivel de referencia es un punto de partida para proyectos no estándar. Es donde se buscan y prueban las soluciones, pero es imposible estimar cuán difícil será o cuánto tiempo llevará.

Depende del programador o del equipo qué proyectos son estándar y cuáles no. Por lo tanto, a veces es difícil estimar cuánto tiempo llevará un proyecto desde una vista externa. Las posibilidades de lo que una persona o un equipo pueden lograr son infinitas, pero algunas personas lograrán objetivos que otras no. Algunas personas pasarán mucho tiempo en cosas que otros pueden hacer en minutos. Y eso ni siquiera hace que un programador sea mejor o peor que el otro.

Por lo tanto, mi respuesta a la pregunta es: no existe el mejor método para estimar el desarrollo de software, solo use su cerebro y manténgase actualizado con el proyecto.

¡Tomando esto de un artículo llamado Your Estimates are Spot On!

Es una descripción general bastante completa de la estimación de proyectos en general: qué explicar, qué considerar y describe las preguntas que debe formular en cada etapa del proceso de estimación de proyectos.

Por ejemplo, al comenzar, considere lo siguiente:

• ¿Estoy tomando demasiado trabajo?
• ¿Tengo todo lo que necesito para comenzar este trabajo? Lo que falta
• ¿De quién y / o de qué soy dependiente durante el proyecto?
• ¿Mi cliente estará listo para firmar mi trabajo?

A medida que avanza con el proceso de estimación, también es bueno tener en cuenta estas preguntas:

• ¿Es esto realista? ¿Estoy haciendo los supuestos correctos para estimar esta tarea?
• ¿Quién trabajará potencialmente en la tarea? ¿Son lo suficientemente hábiles para igualar mi estimación?
• ¿Asigné suficiente tiempo para la corrección de errores durante el control de calidad?
• Tenga cuidado al agregar contingencias en el nivel de tarea individual: pueden ser pequeñas pero se suman bastante rápido y pueden hinchar su proyecto de manera significativa.

Estas preguntas se vuelven más relevantes cuando intentas establecer fechas límite y asegurarte de que no te pierdas nada importante:

• ¿Tengo todas mis dependencias contabilizadas?
• ¿Pueden mis recursos funcionar de manera efectiva? ¿Mis recursos van a pisar los pies del otro?
• ¿Planeé suficiente contingencia? ¿Tengo demasiada contingencia?
• Si la duración es un problema, ¿necesitamos todo ese alcance para comenzar?
• ¿Este proyecto va a tener éxito con este cronograma?

Y una vez que haya terminado su proyecto (¡felicidades!), Puede consultar estas preguntas de evaluación:

• La estimación de esta tarea fue correcta, ¿qué la hizo correcta?
• La estimación estaba muy lejos, ¿por qué?
• ¿Cuál de mis riesgos se convirtió realmente en problemas?

Vale la pena señalar que las estimaciones son solo estimaciones, y que lo inesperado siempre ocurrirá. Dicho esto, estas preguntas son excelentes herramientas para las estimaciones de sus propios proyectos, y deberían ayudarlo a ponerse en marcha.

Pulgar mojado al viento.

No hay mejores métodos. Solo una colección de métodos a medias, a medias, a medias, a medias. Cualquiera que profese lo contrario está vendiendo algo.

No pierdas el tiempo buscando una solución. Usa tu instinto y tu experiencia pasada.

Si no tiene experiencia previa, discuta con sus colegas más experimentados cuáles son sus pensamientos sobre cuánto tiempo debería tomar.

Si no tienes agallas … bueno … ¿cómo estás escribiendo software?

¿Qué tipo de empresas compran “herramientas de estimación de costos de software”?
¿Vale la pena recopilar métricas en proyectos de software?

Todos estos días, las herramientas de administración de proyectos solo proporcionaban un estado de finalización del proyecto y las horas presupuestadas asignadas a diferentes miembros / proyectos, pero esta herramienta de administración de proyectos inteligente y sugerente hará todo el trabajo de análisis y saldrá con la sugerencia que proporciona el mejor recurso disponible para Un proyecto específico. Regístrese aquí gratis y aproveche los mejores servicios ahora: http://pinestem.com

Casi todos los proyectos de desarrollo de software comienzan con una pregunta: “¿Cuánto va a costar esto?”

Aquí está el problema: hasta ahora, hay dos respuestas comunes a la pregunta “¿Cuánto va a costar esto?”:

1. No sabemos, y
2. Permítanos estimar y responderle.

A las partes interesadas y los tomadores de decisiones no les gusta la respuesta n. ° 1 porque necesitan desesperadamente una respuesta a su pregunta y no tienen el conocimiento para responderla ellos mismos. Y a los equipos técnicos no les gusta la respuesta n. ° 2, porque la estimación lleva mucho tiempo y a menudo se abusa de ella (las partes interesadas a veces convierten las ‘estimaciones’ en máximas y se enojan si el equipo las supera).

Sin embargo, la verdad es que es responsabilidad del equipo técnico responder la pregunta “¿Cuánto va a costar esto?” ¿Por qué? Porque los equipos técnicos son los que tienen el conocimiento más relevante para responder la pregunta. Si le pregunto “¿Cuánto cuesta construir un estadio de béisbol?” Solo aquellos de ustedes que tienen experiencia de primera mano en la construcción de algo similar realmente pueden responder. El resto de nosotros estamos apuñalando en la oscuridad.

Entonces, ¿cómo puede satisfacer la necesidad de las partes interesadas de saber “¿Cuánto va a costar esto?”

Respuesta: Deje de estimar, comience a presupuestar.

Para aprender a presupuestar de una manera que tome el 20% del tiempo que la estimación, lea Presupuestación vs Estimación para proyectos ágiles

Supongo que, dado que la estimación del tiempo es una cuestión bastante dinámica y que muchos factores pueden influir en si son precisos o no, es difícil hablar de los mejores métodos para las estimaciones de proyectos. Sin embargo, puede componer un conjunto de reglas que su equipo / equipos seguirán para que el proceso sea lo más inofensivo posible. En Netguru, establecimos algunas buenas prácticas que seguimos para que todos conozcan su papel en las estimaciones de tiempo y reciban pautas útiles para hacerlo. Los enumeramos todos en una publicación de blog:

Mitos de estimación desacreditados!

Lea el libro Estimación de software: Desmitificar el arte negro (Mejores prácticas para desarrolladores): Steve McConnell: 9780735605350: Amazon.com: Libros

También puede leer mi reseña / resumen de ese libro aquí
Desearía que Steve McConnell estuviera en Twitter. . . . Reseña del libro de “Estimación de software”

Ese libro es un gran comienzo: el libro cubre muchas de las mejores prácticas y técnicas de uso común. Al final, sin embargo, cada práctica tiene éxito o falla en función de cuánto aprenda su desarrollador de la experiencia.

Recientemente escribí una publicación de blog exactamente sobre este tema, puede encontrar el enlace aquí:

La estrategia más efectiva para estimar el proyecto

Creo que las compañías de software generalmente pueden contar con equipos inteligentes, por lo que hacer un enfoque ascendente con la delegación funciona muy bien.

¡Espero eso ayude!