Enlace al post Estimación software, una breve introducción (2/4)
“No se puede controlar lo que no se puede medir” (Tom De Marco)
Vistos en post anteriores los métodos de estimación de esfuerzo y de cálculo de tamaño, normalmente, todo proceso de estimación sigue un esquema como el de la siguiente figura:
Lo normal es empezar estimando el tamaño. El tamaño suele estimarse en función de la funcionalidad que se espera que tenga el software (con PF, contando requisitos, etc.). Muchas veces las estimaciones iníciales se hacen sobre requisitos muy ambiguos (un pliego de pocas líneas) y ahí se aplican PF ligeros o, por ejemplo, se estiman los casos de uso para aplicar puntos casos de uso, y siempre se trabaja con un error mayor de estimación (ver en el post de mañana el cono de incertidumbre y las unidades de estimación).
Estimado el tamaño, se estima el tiempo de proyecto (los meses de duración) y el esfuerzo (las horas hombre). Con los anteriores, ajustando el plazo en el que quiero terminar un proyecto, variando las personas que trabajarán en él, etc., se calcula el plan real (con fechas reales aproximadas) y el coste.
Sobre cómo dado un esfuerzo total (por ejemplo 12 meses hombre) y un tiempo de proyecto (me gustaría tener el proyecto en 4 meses) se ajusta el número de personas del equipo (por ejemplo si son 12 meses hombre, se puede suponer que poniendo 3 personas el proyecto durará 4 meses) habría que escribir otros cuatro post. Esto es uno de los puntos más serios y complicados, y donde más errores se comenten. Hay quien piensa que metiendo más gente tardará menos el proyecto, pero eso no es siempre así (hacer software no es poner ladrillos en una obra), ya que a más gente más organización y canales de comunicación, por lo que la relación no es directa. También se dice que no se puede bajar del 25% de la temporalidad estimada metiendo gente. Y en cualquier caso, ya os digo que esto es un tema de profundidad, y os recomiendo leer al respecto todo y cualquier cosa escrita por Brooks.
Enlace al post Estimación software, una breve introducción (4/4)
- Quieres que tus equipos cambien, pero pasan de ti + Nuevo video OKRs con IA + Cumplo 24 años de Doctor en Informática #LaNewsletterdeJavierGarzas - 26 septiembre, 2024
- Amazon: la IA nos ahorra 4.500 años de programación + 3 familias de ESTIMACIÓN + Video creando Videojuegos con Hija e IA #LaNewsletterdeJavierGarzas - 19 septiembre, 2024
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
Pingback: Bitacoras.com
Pingback: Una breve introducción a la estimación software. Recomendaciones y buenas prácticas (4/4) - Javier Garzás, sobre calidad software y otros temas relacionados
Pingback: Los puntos función. Una breve introducción a la estimación software (2/4) - Javier Garzás, sobre calidad software y otros temas relacionados
Excelente post!!! me identifico con lo que dices de que donde mas errores se comenten es en pensar que si un desarrollo tarda cierto tiempo, incluyendo mas personas se puede terminar antes. Muchas veces me pedían estimar y luego me decían que incluyera a otro compañero en la tarea, pero eso requiere coordinación adicional, ademas, de que si trabajamos mas personar en un mismo desarrollo, implica mas cuidados en la integración de lo que desarrolló cada uno, que nos costo mucho tiempo que se creía, nos íbamos a ahorrar.
Es bastante interesante y útil la información que nos presenta, muchas gracias por compartirla.
Tengo una duda al respecto y me gustaría saber su opinión.
Una vez realizada la estimación de costos por alguna de las técnicas propuestas. ¿Seria recomendable informar al cliente un costos con un porcentaje de holgura y cuál sería este porcentaje?