2009-07-08 12 views

Respuesta

14

Si puede hacerlo políticamente: calcule en trozos pequeños, trabaje en iteraciones pequeñas, y centre la atención en lo que causó la desviación del cálculo para hacer mejor el siguiente cálculo.

Una de las principales causas de las malas estimaciones en mi experiencia es la falta de experiencia en el uso de la arquitectura planificada para el proyecto. Ajustando las estimaciones a medida que las cosas se vuelven más concretas y claras, las estimaciones mejoran con el tiempo.

La otra causa principal de las malas estimaciones es estimaciones falsas. Las estimaciones se mantuvieron artificialmente bajas para ganar una oferta. La única forma en que una empresa de consultoría puede romper ese ciclo es dar buenas estimaciones y ganar suficientes proyectos y cumplir con las estimaciones para ganarse la reputación de alcanzar sus estimaciones. Suficientes clientes lo respetarán para hacer negocios razonables con eso, pero construirlo será difícil.

+1

Ese primer "si" es un condicional muy grande. He estado en dos empresas de consultoría que construyeron (y mantuvieron) la reputación de estimaciones precisas para proyectos comerciales, y fue una gran ventaja. Desafortunadamente, ahora estoy haciendo trabajo de consultoría gubernamental, y las estimaciones lowball poco realistas son la norma en toda la industria. – mpez0

7

La ley de Hofstadter no debe tomarse en serio; si fuera fiel a la letra, cada tarea llevaría un tiempo infinito si tomara en cuenta la Ley de Hofstadter.

+1

tal vez eso significa que no debemos hacer nada ... – LB40

+0

¿Entonces no encuentras que tiene sentido? – ripper234

+2

Todavía tiene algo de sentido, pero solo porque es una versión humorística del hecho de que los desarrolladores somos pésimos para hacer estimaciones de tiempo. Puede tomarlo en consideración, pero aumentar ciegamente una estimación de tiempo no es mucho mejor que la estimación original mal concebida. –

1

Base que estima el rendimiento anterior, no en el mejor de los casos. Esto requiere que controle el tiempo dedicado a sus proyectos. No me importa si "sabe" que solo le tomará "6 semanas" terminar, si le tomó 3 meses completar un proyecto similar la última vez, probablemente le tomará 3 meses la próxima vez.

0

+1 para @Yishai - uno de los beneficios de una metodología ágil como el melé es que las personas realmente reciben comentarios sobre la precisión de sus estimaciones.

Nunca vas a mejorar en algo si nunca se sabe si se equivoca ...

+0

Quizás no estés recibiendo todo el asunto de StackOverflow. Puedes presionar la flecha al lado de la respuesta para hacer +1 a alguien y comentar su respuesta si es necesario en lugar de enviar una nueva respuesta. – JohnFx

+1

Y lo hice, pero quería agregar la mención de scrum, y aunque merecía su propia respuesta. – chris

0

me gusta este método:

  1. hacer una estimación honesta de los esfuerzos necesarios para la tarea.
  2. Aplica un multiplicador a la estimación. Al menos 1.5 probablemente 2.0. Con el tiempo comparando el esfuerzo real con el esfuerzo estimado, podrá calcular el verdadero multiplicador.

Recopilar los esfuerzos estimados y reales son clave para mejorar sus estimaciones.

0

La estimación ágil siempre utiliza "horas ideales" que tienen en cuenta implícitamente la ley de Hofstadter. Por lo tanto, no es necesario fudgear.

Si está respondiendo como empleado ...

"Gee, jefe, en un mundo perfecto que tomaría X días. Vamos a añadir un cojín a ella y voy a hacer todo Puedo llamarlo en ese período de tiempo Si la estimación cambia, le informaré de inmediato . "

¡Eso es música para los oídos de un jefe!

Si responde como propietario del negocio ...

Usted solo brinda estimados a sus clientes cuando los respalda en una esquina. Luego, utiliza los días ideales con descargos claros y prepárese para el ajuste, ya que conoce la ley de Hofstadter.

5
  1. Calcule cuánto tiempo llevará algo el código.
  2. Multiplicar por pi.
  3. Sorpréndase con la frecuencia con la que está más cerca de cuánto tiempo lleva realmente.

(Esto es también para no ser tomado como un método científico, pero es otra manera de expresar lo difícil que es para estimar correctamente el tiempo. Realmente lo uso a veces, aunque ...)

:)

Editar:
Un método que es un poco más científico: especifique un tiempo para el tiempo absoluto mínimo y máximo para una tarea, por ejemplo, que definitivamente tardará entre 5 y 30 horas. (Divida en subtareas para posiblemente reducir el lapso de tiempo). Obtiene un lapso de tiempo muy amplio, pero al menos es más confiable que una estimación.

+0

Esto a menudo funcionó para mí, aunque utilicé un número más alto. –

+0

Interesante. Voy a comenzar a probar esto, solo para compararlo con los tiempos de proyecto terminados. Usted podría estar en algo. =) –

+0

Es gracioso, durante muchos años de mi experiencia, estimar un multiplicador 3x es sorprendentemente preciso tanto para mí como para otros programadores que me han funcionado. Tal vez es una constante universal. – JohnFx

4

Mientras "Ley de Hofstadter" es un poco la lengua en la mejilla, hay un par de prácticas que pueden ayudar, en particular, para la estimación elemento de primer paso/grande:

  • Estimación de relativa tamaños. Lo que significa que no dice que un elemento toma X veces, dice que un elemento A es dos veces más grande que el elemento B, y ese elemento B es aproximadamente 4 veces más grande que el elemento C.

  • Recopila datos de anteriores estimando rondas y usándola como una línea de base. Entonces, cuando estás estimando un proyecto, y notas que el ítem A es tan grande como el ítem B de una iteración/proyecto anterior, y sabes que el ítem B ha tardado 2 días, sabes que el ítem A probablemente tomará como largo

  • Utilice "sabiduría de las multitudes" para obtener estimaciones de mayor calidad. He usado Planning Poker en un par de proyectos y los resultados son bastante buenos.

Si quiere saber más sobre este puede comenzar por la presentación del reloj Mike Cohn (Part 1 y Part 2) y/o leer su book. Si bien no se trata de una estimación total, sí presenta algunas buenas prácticas y, lo mejor de todo, el razonamiento detrás de las prácticas.

0

Estimar es un arte, como saben y hay un arte secundario que es el arte de estimar la contingencia. :) Para estimar adecuadamente la contingencia (generalmente un% de una estimación total), uno debe comprender risks and mitigations. Básicamente, multiplicas el riesgo de que algo ocurra con el daño que puede hacer para llegar a un factor de riesgo. Luego, resume todos sus factores de riesgo y calcula su riesgo total. La contingencia debe oscilar entre 15% para proyectos de muy bajo riesgo (nunca voy por debajo del 15% de contingencia) hasta 50% para riesgo muy alto (según mi experiencia, muy pocos clientes recibirán una estimación de contingencia superior al 50%).

0

La ley de Hofstadter es solo otra implicación de lo notorio que es la autorreferenciación ... el humor sutil tiene efectos de gran alcance.En retrospectiva, esta ley confirma que cada ley/principio/axioma que está estructurado por lógica, es incompleta (como Godel), por lo tanto, incluso teniendo en cuenta esas leyes, la lógica puede no ser completa. El sentido del infinito es nuevamente una jugada de la paradoja de Zenón (tortuga contra Aquiles) ... tiempo infinito para que Aquiles complete la carrera ... etc ... estas son ilustraciones del mal omnipotente de la auto referenciación que contamina toda estructura lógica afín.

3

He usado los dados. Abiertamente. En frente de mi manager. Normalmente utilizo 3 dados estándar de seis caras.

Jefe: "¿Cuánto tiempo va a tomar esto?"

Yo: (rolls) "Alrededor de 11 días."

Jefe: "No, en serio".

Yo: "Oh, en serio." (rollos) "Alrededor de 7 días".

También solía tener un póster en mi pared que decía "Plazos de entrega Amuse Me". Toma de eso lo que quieras.

+0

¡Hilarante, simple y llanamente! ;) –

+0

Es cierto también. Por supuesto, hice esto frente a un gerente que conocía muy, muy, muy bien. Él estaba haciendo toda la rutina de actuación mientras luchaba por regañarme. Falló. –

Cuestiones relacionadas