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

42

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).

gablin
fuente

Respuestas:

28

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.

aubreyrhodes
fuente
1
Esta. Es la forma más útil de estimar. Para mejorar, se puede hacer un seguimiento del tiempo de las tareas cuando realmente las realiza, por lo que la próxima vez se puede dar una mejor estimación. La estructura de desglose del trabajo es un concepto útil para esto.
Tamás Szelei
3
Esta es una respuesta genial. Me gustaría agregar que, además de tomar notas de sus estimaciones, puede ser útil escribir algún tipo de "registro diario", donde tome nota de decisiones importantes, problemas que encontró y resolvió, etc. Si resulta una estimación para estar apagado en un 50% o más, entonces podría ser útil investigar por qué, y luego estos "diarios" serán de gran ayuda (consulte las páginas 64-69 en "El programador pragmático" para obtener más detalles al respecto). Además, tenga cuidado a quién le muestra sus números; las personas que no entienden lo que estás haciendo podrían tratar de usarlos en tu contra.
Leif
Hago lo que haces, manualmente. Básicamente es una programación basada en la evidencia ( en.wikipedia.org/wiki/Evidence-based_Scheduling ), como fue promovida por Joel e implementada en fogcreek.com/fogbugz
Mawg
18

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.

dsimcha
fuente
2
Odio decirlo, pero esta es probablemente la métrica más simple y efectiva que he visto aquí.
glenatron
3
Me enseñaron la regla de sumar y cuadrar. Si creo que tomará un día, agregue uno hace dos días, cuadrado que lo hace 4 días. Conozco a otros que usan el movimiento de la magnitud hacia arriba pero sin duplicar. entonces un día se convierte en una semana. Dos semanas y media se convierten en dos meses y medio, etc. No importa lo bueno que sea, debe agregar relleno para las incógnitas que ocurrirán.
old_timer
9

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 .


fuente
Lo del póker suena realmente interesante, ¿realmente haces este IRL como se describe en tu enlace? ¿Te ayudó a crear estimaciones más precisas?
Dr. Hannibal Lecter
Sí. ¡Esto hace que la estimación sea divertida! Y muy en serio. Por supuesto, tienes que practicar un poco, pero una vez que "lo entiendes", ya no puedes estimarlo con otros métodos.
¡Realmente suena divertido! :) Para mal, nunca podré vender esto en mi compañía: - /
Dr. Hannibal Lecter
@dr Hannibal Lecter: usa el truco de la tienda de mascotas. Dígales que no es definitivo, que lo usará solo para probarlo. Créeme, será definitivo;)
9

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".
desaparecido en combate
fuente
¿Puedes explicar de dónde viene este indicador del 60% (y el 70% de la utopía)? ¿Hay algún artículo sobre este tema disponible en alguna parte?
krokodilko
7

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.

Alano
fuente
Desde que respondí esta pregunta, también me mudé más al campo "sin estimaciones". Algunas grandes ideas están saliendo de allí.
Allan
5

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.

Miguel Veloso
fuente
3

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.

aufather
fuente
3

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.

glenatron
fuente
1

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.

JB King
fuente
1

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.

Jeremy
fuente
1

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.

Mike Clark
fuente
1

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!

vrdhn
fuente
0

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.

usuario281377
fuente
0

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.

John R. Strohm
fuente