¿Cómo aprender a hacer mejores estimaciones? [cerrado]

Soy un asco en las estimaciones. Cuando alguien me pregunta cuánto tiempo tomará algo, ni siquiera me atrevo a adivinar, ya que estaré completamente fuera de lugar. Por lo general, soy demasiado optimista, y probablemente debería multiplicar mi suposición con algún factor X grande ...

¿Cómo puedo aprender a hacer mejores estimaciones? No se enseña en mi universidad, y aunque tenemos plazos para todas las labores, nunca pienso en cuánto tiempo llevará algo realmente. Lo cual debería. Por el bien de todos (especialmente el mío).

Todavía no soy bueno en eso, pero he descubierto que rastrear cuánto tiempo estimas para las tareas y cuánto tiempo realmente tomas puede ser de gran ayuda. De esa manera, puede tener una idea sólida de cuán lejos está generalmente. El software de gestión de problemas con seguimiento de tiempo (Jira en mi caso) o una hoja de cálculo puede ser de gran ayuda con esto.

Creo que más que nada es una experiencia.

Ley de gestión del tiempo de Murphy: para calcular cuánto tiempo tomará algo , calcule cuánto tiempo debe tomar y duplíquelo.

Luego, sube a la siguiente unidad de tiempo más alta. Por lo tanto, asignamos dos semanas para un proyecto de un día.

Puedes aprender haciéndolos colectivamente .

Yo uso Planning Poker . Es una técnica de estimación basada en el consenso .

Su estimación debe ser rastreada y comparada con lo que efectivamente ha hecho. Obtendrás la velocidad .

Cada vez que estima algo, multiplique por su velocidad reciente para obtener una estimación precisa .

La estimación de software de Steve McConnell (MS Press) es una buena lectura.

Lo principal con la estimación del software se resume en lo siguiente

Sin información histórica, sus estimaciones son inútiles.

Esta es una razón por la que creo que los proyectos iterativos tienen mucho más éxito que los grandes proyectos en cascada en fase. No están tratando de elaborar un plan para un año a la vez con poca información que no sea un vudú de caja negra de lo que creen que debería ser. Cada iteración, están reestimando / replanificando y tienen las últimas iteraciones para basar sus estimaciones.

Algunos otros puntos a tener en cuenta:

1. Solo se hará más lento . La aplicación de la regla 80/20 significa que el trabajo más duro vendrá más adelante a menos que la gestión de su proyecto sea muy disciplinada.
2. Estimación! = Planificación. La estimación es el proceso de calcular el esfuerzo requerido para hacer algo. La planificación es el proceso de adaptarlo a un horario.
3. El 60% de eficiencia es todo lo que puedes esperar. El 70% es utopía. Si calcula en días, incorpore esto. Si calcula en horas, no olvide aplicarlo más tarde.
4. Recuerda la larga cola . Las estimaciones son una aproximación aproximada de cuánto tiempo "probablemente" tomará ajustado para cierto nivel de riesgo e incógnitas. La larga cola entra en juego porque la cantidad real de trabajo requerida nunca será inferior a 0. OTOH, la cantidad máxima de tiempo que tomará solo está limitada por el tiempo que esté dispuesto a gastar en ella antes de darse por vencido. Como dijo un ex jefe mío "todas las estimaciones son +/- x% y nunca es menos".

Me sorprende que nadie haya mencionado la técnica de estimación de estilo PERT que se describe en The Clean Coder, de Robert Martin . En ese método, calcula cuánto tiempo tomará 3 escenarios: optimista ( O), nominal ( N) y pesimista ( P). Entonces la duración esperada = (O+4N+P)/6y obtienes una desviación estándar de (P-O)/6.

Esto parece funcionar bastante bien, y lo he usado varias veces cuando la administración realmente se preocupa por cuánto tiempo probablemente tomará algo.

Como han comentado otros, también he hecho estimaciones examinando datos históricos ("¿Cuánto tiempo se tardó en hacer algo similar?").

Pero mi método favorito es no hacer estimaciones de tiempo en absoluto, y solo hacer estimaciones puntuales y obtener una velocidad sobre las iteraciones. Si un equipo es bastante consistente en dimensionar y completar el trabajo (historias de usuarios), entonces ahorrará un montón de tiempo sin siquiera preguntar cuánto tiempo tomará cada cosa.

Las estimaciones de horas son terriblemente difíciles de acertar, y requieren mucho trabajo para dividir las cosas en trozos lo suficientemente pequeños como para medir de manera efectiva. Y aun así, rara vez son correctos porque hay demasiadas variables y nos olvidamos de tener en cuenta cosas como enfermedades, vacaciones o incluso distracciones.

Si tengo que hacer estimaciones de horas, trato de hacerlas solo para tareas pequeñas dentro de una iteración. Mido todo en estimados de medio día (4, 8, 12 horas) a menos que sepa que podría ser menos. Pero rara vez calculo algo en menos de 1 hora.

Primero y más importante, debes definir un proceso y seguirlo. Incluya la revisión del plan al final de cada fase del proceso. También puede revisar el proceso, pero de manera ordenada.

En segundo lugar, hacer algún tipo de diseño. El diseño es el primer paso para la planificación, no se construye una casa sin dibujos.

Tercero, el tiempo de seguimiento (esfuerzo). Al menos debe diferenciar:

• Análisis
• Diseño
• Código
• Prueba unitaria (incluye defectos de fijación)
• Prueba de integración (incluye defectos de reparación)

• Prueba de aceptación, con el usuario (incluye defectos de reparación)

  Sería genial si midiera el esfuerzo de reparación de defectos para cada tipo de prueba, pero agrega complejidad, por lo que puede hacerlo más adelante.

Cuarto, identifique los elementos base clave para estimar. Por ejemplo:

• Número de procesos a automatizar (Análisis)
• Número de entidades del modelo de dominio (diseño)
• Número de formularios e informes (Código)

Quinto, correlacionar elementos básicos y esfuerzo. Por ejemplo:

• Esfuerzo de análisis = X horas-hombre / proceso a automatizar
• Esfuerzo de diseño = Y horas-hombre / entidad modelo de dominio
• Esfuerzo de código = Z horas-hombre / formulario (o informe); número de formas = A * entidades del modelo de dominio
• Esfuerzo de prueba de unidad = M% * Esfuerzo de código
• Esfuerzo de prueba de integración = N% * Esfuerzo de código
• Esfuerzo de prueba de aceptación = P% * Esfuerzo de código

Sexto, realizar un seguimiento del rendimiento y la desviación de las estimaciones para cada proyecto. Para que pueda ajustar sus factores de correlación.

Séptimo, repetir y mejorar. Obtendrá una gran cantidad de información justo al final del primer proyecto, en el tercero se sentirá cómodo al planificar y estimar.

Echa un vistazo a http://en.wikipedia.org/wiki/Personal_Software_Process , realmente funciona.

Siempre que encuentre un problema de estimación, intente dividirlos en partes más pequeñas. Luego vea si ya ha hecho cosas similares a las piezas. Si es así, ya debería tener una idea justa de cuánto tiempo lleva cada pieza. Si no lo hace, debe comenzar a realizar un seguimiento activo del tiempo necesario para diversos tipos de tareas. Esto lo ayudará en futuras estimaciones.

El tiempo total necesario será más que la suma de las piezas individuales, ya que necesita algo de tiempo para la integración y las pruebas.

Si no ha hecho algo similar, probablemente pueda confiar en la experiencia de otras personas y obtener una estimación de ellos. Sin embargo, no tome esto al pie de la letra. Nada te enseña como la experiencia.

Es como disparar a un objetivo. Los disparos previos en la estimación deberían decirle qué tan fuera de la marca se encuentra, para que pueda corregirlo.

Me resulta más fácil hacer el proceso de división a las tareas mínimas como se mencionó anteriormente, resolver cada una y luego duplicar esa estimación. Luego los sumo y agrego el cincuenta por ciento. Eso me da un tiempo aproximado del proyecto en condiciones ideales. Si el trabajo prácticamente va a suceder en paralelo con otros, necesitará más tiempo. Si va a tener que esperar a otras personas, espere que tarden el doble de lo que cree. Esperar contenido o comentarios u otra información a menudo lleva mucho más tiempo de lo que parece posible.

Donde trabajo, calculamos una estimación del mejor caso / caso esperado / peor caso para cada paso del proceso, lo cual es útil como guía y también para evaluar cómo han funcionado sus estimaciones.

La técnica nunca es tan importante, excepto que debe ser capaz de combatir la tentación del programador de subestimar las tareas, pero lo importante es ser conservador sobre cuándo puede entregar algo. Si le lleva siete semanas construir algo y prometió ocho semanas, puede llegar un poco más temprano y verse bien o hacer algunas pruebas adicionales y estar seguro de su confiabilidad. Si prometiste seis semanas, puedes verte mal incluso si no es tu culpa. En caso de duda, adivine conservadoramente.

Podrías intentar crear un historial de lo que fue la estimación y lo que fue real para varias tareas para construir un registro suficiente para luego saber qué multiplicador tener para cosas específicas que se repiten en tu lista. De acuerdo, este es un ejercicio de prueba y error, pero me ha funcionado bien. También hay algo que decir para muchos ensayos antes de que el patrón surja probablemente. Es probable que esto sea similar a muchas otras respuestas que dirían que uno podría reducirse a "¡Solo hazlo!" ya que así es como la mayoría de nosotros desarrollamos la habilidad. ¿Es un gran dolor ver cuán equivocado puede estar uno al hacer estimaciones? Sí, pero si las estimaciones mejoran, todos pueden ser felices eventualmente.

Si puede descomponer el proyecto en tareas más pequeñas y hacer estimaciones para ellas, será más preciso en general. Cualquier tarea mayor que un par de días debe desglosarse aún más. Si no puede dividirlo más de lo que probablemente tenga una brecha de requisitos. Si tiene que hacer una estimación de la parte posterior de la servilleta para un requisito de una línea bien ... nada realmente puede ayudarlo mucho. Lamentablemente, muchas tiendas trabajan de esta manera la mayor parte del tiempo.

En lugar de escribir un libro sobre él, solo ofreceré un pequeño consejo sobre cómo usar el método de estimación "descomponer":

• Divide tu tarea en tareas de componentes más pequeños. Estime cada tarea lo mejor posible.

• Agregue una tarea para la planificación y el diseño (que incluye lo que está haciendo ahora). Estímelo.

• Si aún no tiene una, agregue una tarea para "unir las tareas". Esta tarea puede no parecer útil al principio. Sin embargo, cuando utiliza este método de estimación "desglosado", siempre hay cosas que requieren mucho tiempo para hacer que "caen entre tareas" y que "unen las tareas". Este puede ser complicado de estimar. Haz tu mejor esfuerzo.

• Agregue una tarea para pruebas y documentación. Es posible que su tarea no requiera muchas pruebas y documentación, pero al menos debería pasar un poco de tiempo pensando en ello.

• Sume las estimaciones de tareas para obtener una estimación general.

• Siga adelante y multiplique esa estimación total por dos ††. Esto le dará tiempo de relleno para:

  1. Termina las cosas que pasaste por alto en tu lista de tareas original
  2. Termina cosas que no podrías haber sabido hasta que empezaras
  3. Incorporar comentarios de otras personas y hacer cambios.
  4. Ser interrumpido por otras cosas que suceden a tu alrededor, como reuniones
  5. Termine antes de la estimación más a menudo que detrás

Y por último, pero no menos importante, no tengas miedo de esbozar estimaciones que probablemente estén totalmente equivocadas. A veces, esbozar todo, sin importar cuán potencialmente inexacto sea, puede ayudarlo a comenzar el camino para tener una mejor idea de lo que está involucrado.

†† A medida que adquiere más y más experiencia, este "factor fudge" puede ajustarse para adaptarse a su estilo personal y su entorno de trabajo.

La fórmula que funciona cuando trabajo para mí:

1. haga un desglose de todo a una granularidad de 1 a 4 horas. Me parece que generalmente soy exacto con estos

2. el 'factor de incógnitas': multiplique por un factor de 2 elevado al número de incógnitas. Es decir, si va a desarrollar una aplicación couchdb, pero ahora sabe algo acerca de javascript y http ... agregue 2 ^ 2 como factor múltiple.

3. factor de cambio de contexto: múltiple por 1.5 si trabajará en un entorno perfecto (en casa, en la esquina del estudio, etc.), o 2.5 si trabajará en un entorno impreciso (oficina / lugar concurrido, etc.)

¡Encuentro que esto está dentro de +/- 20% del tiempo real tomado!

Aprende tu propio sesgo. Si su última estimación ha sido demasiado baja por el factor dos, la próxima vez, duplique su estimación inicial. (Por supuesto, la ley de Hofstadter hace que sea difícil hacerlo bien ...)

También es siempre una buena idea recordar cuánto trabajo se necesitaba después del lanzamiento inicial del trabajo anterior, y agregarlo a la próxima estimación. Por ejemplo, su última tarea tardó 2 meses en completarse, pero después de la puesta en marcha, el soporte, las revisiones y los cambios adicionales le han costado otro mes, por lo tanto, la próxima vez calcule 3 meses para una tarea similar.

Para los abridores, lea "Software Engineering Economics", de Barry Boehm, y "Controlling Software Projects", de Tom DeMarco. Después de leer y digerir esos dos, lea "Estimación de costos de software con COCOMO 2", de Barry Boehm.

Por lo que tengo que decir a continuación, te ayudará MUCHO haber tomado una clase de probabilidad y estadística, incluso una clase básica de libro de cocina.

Ninguna estimación es perfecta. Hay alguna probabilidad de llegar temprano y alguna probabilidad de llegar tarde. El modelo COCOMO original detallado de Boehm dio predicciones que resultaron estar dentro del 30% del resultado real, mejor que el 60% del tiempo. Eso fue mucho mejor de lo que era común cuando escribió y publicó el libro.

Cuando haces tu mejor suposición (y eso es todo un estimado), estás incluyendo esas probabilidades. Si obtiene la estimación, aumentará la probabilidad de llegar tarde. Si aumenta la estimación, aumentará la probabilidad de que llegue temprano o termine a tiempo. La cantidad que lo empuje hacia adentro o hacia afuera controla cómo cambia la probabilidad y debe depender necesariamente de las penalizaciones por llegar temprano o tarde. (Inserte historias de terror aquí, ¡y ha habido MUCHAS de ellas a lo largo de los años!)

DeMarco aborda esto hasta cierto punto. También señala que hay una "región de imposibilidad": algunos horarios son demasiado ajustados para hacerse, sin importar qué tipo de heroicidad se intente.