Antes de llegar demasiado lejos, permítame decir que Estimación de software: desmitificar el Arte Negro es un excelente recurso Para gente que mira y piensa en estimaciones. Las dos imágenes a continuación son de ese libro, ya que son el núcleo de las ideas que se presentan a continuación.
Como ha señalado, las estimaciones son una parte importante para poder predecir y planificar el trabajo con precisión. No tener estimaciones hace que el negocio sea ciego acerca de cuánto tiempo tomará algo. No es raro que las empresas tengan una idea completamente equivocada sobre cuánto tardarán las cosas: lo que creen que es fácil lleva de seis a ocho semanas y lo que se cree que es difícil es un truco de la tarde del viernes.
Lo primero es dar una estimación. Una estimación en sí misma no es un solo número, eso es un compromiso. "¿Cuánto tiempo tomará ABC" - > "Alrededor de 5 días" significa que son aproximadamente 5 días. Sin embargo, una buena estimación es un rango en el que tiene un 90% de confianza de que lo tendrá en ese rango. Si quiere decir "Estoy seguro al 90% de que tomará entre 1 y 5 días", dígalo. No trabaje desde "Creo que tomará entre 1 y 10 días, por lo que 5 días es probablemente promedio", eso no es una estimación y se equivocará el 50% del tiempo.
Bueno, el 50% o más del tiempo, los programadores son notables subestimadores para los tiempos de tarea.
Considere el cono de incertidumbre:
enlace
Imagen de enlace : artículo completo en enlace
Tenga en cuenta que la primera estimación en ese rango es 16x. Esto es como decir "Creo que tomará entre una tarde y dos semanas", pero todavía no lo sabes. A medida que avanza con el diseño un poco, el rango se reduce a 4x. Esto significa que no significa que tomará una semana, significa que en cambio estaría diciendo "después de ver esto un poco, tomará entre tres semanas", sí, la estimación aumentó, pero También el rango de la estimación bajó.
Con cada estimación que da, necesita estar seguro al 90% de que la estimación está dentro de ese rango. Puede estar equivocado: el 10% del tiempo caerá fuera de ese rango.
Hay muchas formas de estimar el tamaño de los proyectos. Comparándolo con proyectos anteriores, usando un proxy (creo que tomaría 1000 líneas de código que tardaría tanto en escribir), usando puntos de función (para convertir en LOC ...), obteniendo estimaciones de un número de personas y luego refinado iterativamente ... algunos trabajos para algunos proyectos, algunos trabajos para otros proyectos.
Un muy importante capítulo en este libro que mencioné en la parte superior es el # 23 que trata sobre la política de la estimación y el trato con los gerentes y ejecutivos.
La clave para una estimación es el proceso iterativo de refinarla después de trabajar un poco en ella.
Dar una estimación demasiado precisa demasiado pronto en el proceso puede ser muy propenso a errores. Si no está seguro de ello, proporcione la estimación general y luego vuelva con otra estimación después de un período de tiempo para obtener más información sobre el problema y posiblemente esbozar cómo lo hará, mirando la cantidad de código en que lo escribió. el último problema similar y otros factores que afectarán la estimación.
Las estimaciones requieren un poco de reflexión: no emita las estimaciones del manguito. Estos a menudo tienen errores enormes asociados con ellos en comparación con lo que se necesita cuando uno lo piensa un poco.
De Cómo responde cuando se le pide un presupuesto?
Qué decir cuando se le pide un presupuesto
Dices "Me pondré en contacto contigo"
Casi siempre obtiene mejores resultados si retrasa el proceso y pasa algún tiempo siguiendo los pasos que describimos en esta sección. Las estimaciones dadas en la máquina de café (como el café) volverán a atormentarte.
Del Capítulo 4 de Estimación de software:
Tenga en cuenta que en esto, las estimaciones después de un poco de revisión son sistemáticamente menos descabelladas y propensas a errores que las estimaciones fuera del manguito. No hagas las estimaciones del manguito. Siéntese y piense acerca de la tarea y estimela luego de pensarlo un poco.
