2008-09-20 7 views
12

Así que acaba de ser puesto en el lugar por The Boss. Tiene 15 minutos para obtener una estimación del sobre por agregar alguna característica nueva. Su jefe (afortunadamente) reconoce que no puede proporcionar una estimación precisa en ese momento, por lo que espera algo que esté en el orden correcto de magnitud.¿Cómo se hacen estimaciones muy rápidas (y sucias) para las tareas de codificación?

La pregunta es ¿cómo se puede hacer para dar una estimación en el marco de tiempo que es preciso para un orden de magnitud?


Tenga en cuenta que esto está destinado a ser una estimación rápida y sucia, no es algo que podría esperarse de preguntas como this

+1

Voy a cerrar esta pregunta como fuera de tema porque no se trata de programación. –

Respuesta

0

yo personalmente rechazo este tipo de cosas. Pero luego trabajo para mí, así que no respondo a un jefe. Solo un cliente, pero es más fácil hacerles entender que es difícil hacerlo en el momento.

0

En momentos como estos, recuerdo la regla del hermano McKenzie sobre la conversión a la métrica: "Doble y añada treinta".

Por lo general, se me ocurre la rapidez con la que creo que tomará hacer una cosa, luego doblo porque siempre estoy subestimando, y luego agrego 30 para probar, dependiendo de las unidades que estoy usando.

5

Piensa en tareas similares que has hecho en el pasado y cuánto tiempo te tomaron.

Si no has hecho nada similar en todo antes, tratar de romper la tarea en subtareas, entonces cada sub-tarea aún más, hasta que no se deja subtarea que suena como si tomará más tiempo de 1-2 días para crear prototipos de la forma más ingenua posible; si no puede dividir una tarea con una estimación de más de 3 días, esto generalmente implica que no sabe realmente lo que implica hacer esa tarea; hacer una investigación rápida. Una vez que todo esté lo suficientemente dividido, sume el total, duplique el resultado y délo como su presupuesto.

Si no sabes cómo abordar un problema lo suficiente como para hacer lo anterior, y tu jefe te está respirando por el cuello para que no sientas que puedes investigar allí, intenta darle una estimación a tu jefe de cuánto tiempo le llevará realizar la investigación necesaria para comprender el problema lo suficiente como para darle una estimación adecuada.

7

La mejor manera es intentar un desglose rápido de todos los principales subcomponentes, p.

  1. secuencia de actualización de modelo de datos (3 artículos en 2 mesas)
  2. pantalla de Cambio de entrada (3 nuevas entradas)
  3. comprobar la entrada (3 nuevas entradas)
  4. de actualización de datos.
  5. Mostrar resultados etc ...
  6. unidad de compilación de prueba

Asignar un cálculo aproximado en cada uno de estos y si no se puede pensar en una sofocar al menos 2 horas, ya que incluso el más simple el artículo probablemente demorará al menos una hora, pero el 2x permitirá la incertidumbre.

Al menos habrá pensado en todos los elementos que tendrá que hacer para que esté en el orden correcto de magnitud como se solicitó.

+1

Absolutamente. Esta es la manera de Joel, he visto una publicación de blog de él acerca de este enfoque. –

+2

Esto tiene el beneficio de tener también algo que saludar en la cara de los patrones cuando desafía tu estimación: puedes tener una discusión productiva sobre los números relativos. –

17

Coloque el dedo en la boca, lame, agite en el aire e invente un número basado en experiencias pasadas. Entonces doblarlo.

Realmente, es solo una experiencia que cuenta. Imaginas lo que la tarea te obliga a hacer, y sabes cuánto tiempo te llevará hacer eso. Duplícalo para artículos no anticipados. Esta es también la razón por la que nunca le preguntas a los programadores junior por tales estimaciones.

3

No puedo imaginarme una situación en la que realmente no pueda hacer una estimación en absoluto; más a menudo existe el caso donde puedo imaginar múltiples escenarios que darían como resultado plazos de tiempo enormemente diferentes para el proyecto, dependiendo de varias cosas eso podría razonablemente surgir. Y no quiero mentir: lo peor que puedes hacer con tu jefe es inventar cosas.

Así que explico cada una de las posibilidades. Por supuesto, esto solo funciona con un jefe comprensivo, pero si su jefe es tan ignorante o insensato que se niega a escuchar la explicación completa, usted tiene otros problemas.

Por ejemplo, así es como lo hice para un caso reciente en el que realmente tuve que hacer exactamente esto.

x264, el codificador de video en el que trabajo, implementa una forma muy primitiva de codificación entrelazada elegida únicamente porque es muy fácil de implementar. Queríamos implementar la forma completa de esta codificación, pero no tenía idea de cuántas de las suposiciones hechas para la versión simplificada fallarían en tal caso.

Así que pensé en los distintos niveles de cosas que tendrían que cambiarse, e hice un cálculo aproximado, bueno, en el mejor de los casos, podría estar casi funcionando, pero eso es dudoso. Y en el peor, hay una tonelada de cosas que deben cambiarse. Así que, le dije a mi jefe, probablemente era mejor asumir lo peor aquí, ya que la especificación era muy complicada y, a pesar de no saber nada de esa complejidad, sospeché que dada la gran falta de código relacionado en el programa, casi nada de esa complejidad fue realmente implementada. Al final tenía razón, los cambios requeridos terminaron siendo bastante complicados, y subcontrataron el proyecto a un contratista con más experiencia en las complejidades de la codificación entrelazada H.264.

1

Si me veo forzado a proporcionar estimaciones sin suficiente tiempo para investigar adecuadamente el tema en cuestión, tiendo a sobreestimar masivamente. La solución es casi siempre más difícil de lo que creo que va a ser. Si creo que algo tomará un día, entonces digo dos días. Si digo que algo tomará una hora, entonces digo un día. Lo que estoy tratando de ilustrar con estos comentarios es que para todas las tareas menos mundanas como los errores de ortografía, incluso un pequeño cambio de código puede explotar en un día completo. Para cualquier cosa que creo que podría tomar un día o más doblo la estimación. Sé que puede ser difícil hacer esto. La gerencia quiere números pequeños. Quieres lucir inteligente y capaz frente a otro desarrollador. Consulte también Scotty Factory.

Incluso si tiene miembros del equipo de control de calidad que probarán su código, debe recordar que también es su trabajo probar el código. Asegúrese de incluir eso en cualquier estimación. Eso es algo que he visto a muchos desarrolladores dejar fuera de su proceso de estimación.

2

Si realmente necesita estimación muy rápida, puede hacer la estructura de desglose del trabajo con cada tarea durante 1-2 días o menos y después de esto estimar cada tarea proporcionando valores estimados mínimos y máximos.

suma de valores mínimos y máximos que especifican el intervalo para toda la tarea. Esto le da información sobre los riesgos a su jefe, lo cual siempre es muy útil.

Obtendrá algún intervalo, p. 12-15 días o 5-30 días: esto es mucho más útil que 16 días en lugar de los intervalos mencionados.

Le puede ser útil un buen libro de Steve McConnel Software Estimation: Demystifying the Black Art.

+1

Lo intenté una vez. Mi jefe, agregó todas mis fechas mínimas, y esa fue la fecha de entrega requerida. – EvilTeach

+0

En tales casos, es bueno decir el límite superior del intervalo solo para el jefe, y tener en cuenta los intervalos para saber qué tan bueno eres. – sergtk

0

Por lo general, descompongo la tarea en unas pocas piezas, pero no estimo para este tipo de cosas en bloques de tiempo de menos de medio día. Siempre que haya al menos 5 o 6 piezas en la función después del colapso, creo que los errores se equilibran en su mayor parte (algunas tareas demoran menos de una hora, etc.)

Por supuesto, la división de tiempo mínima y el número de piezas requeridas para cierto nivel de comodidad debe variar según el dominio del problema; al menos 5 o 6 partes de medio día parecen ser las correctas para las cosas que me han preguntado últimamente, pero eso debe revisarse cada pocos meses.

Cuando me preguntan a estimar en nombre de otra persona, me resisto un poco más y seguir una práctica similar con un generoso sistema de relleno ("doble y añadir x" como se mencionó anteriormente es probablemente una buena aproximación)

0

El factor n. ° 1 es lo desconocido, y tienes razón, no puedes conocerlos a todos. Sin embargo, generalmente sabrá algunas preguntas importantes que nadie puede responder por usted en ese momento.

El factor n. ° 2 es la dificultad percibida y la disponibilidad de herramientas y recursos disponibles.


Resultado = aproximadamente el doble de su estimación

1
  • dividir la tarea en partes y asignar a cada parte una vez

  • trabajo en unidades de no menos de media al día. Esto evitará la microprogramación

  • El gran problema con la estimación del proyecto es la subestimación. Si conoce bien la tarea y casi puede ver el código, pondere la tarea por 1. Si hay alguna incertidumbre o la tarea requiere una tecnología desconocida, multiplíquela por un factor mayor, según el nivel de incertidumbre

  • No se preocupe demasiado por la precisión de cada parte. Los errores tienden a cancelarse ya que lo único que realmente importa es la duración total

Siempre existe el buen viejo recurso de tomar la escala de tiempo optimista y multiplicándolo por PI. ¡Funciona más a menudo de lo que debería!

3

Además del desglose necesario: un consejo que aprendí de los programadores pragmáticos es expresar estimaciones de más de 15 días en semanas y estimaciones de más de 8 semanas en meses; para que la unidad refleje la precisión de la estimación. Ten mucho cuidado durante 30 semanas.

También puede basar sus estimaciones en tareas similares que ya haya realizado.

0

de estimar en el orden correcto de magnitud, es necesario:

  • sin introducción de nuevas tecnologías o marco para la función deseada;
  • separar su estimación del tiempo de desarrollo puro y disponibilidad de los desarrolladores (y cliente y probador ..;
  • para obtener información sobre sus estimaciones anteriores;
  • un tamaño de característica en su rango de estimación segura (no 2 veces tan grande con 2 veces más personas)
  • un equipo de desarrollo estable.
  • ningún inicio del proyecto por encima.
  • a única estimación para el trabajo que haces a ti mismo.
2

Piense en un número, duplíquelo y luego vuelva a doblarlo (es decir cuatro veces el primer número que aparece en su cabeza)

Cuando un jefe dice "cuánto tiempo completar" un proyecto, se refiere al momento en que se completa y se implementa en vivo para los usuarios. Un programador (por supuesto) solo pensará en el tiempo necesario para completar la programación (el tiempo para escribir físicamente la solución al problema), por lo que normalmente se estima por debajo de lo previsto.

Una regla de oro sería:

El 'primer número' es el número de días que usted piensa que le llevará a completar la tarea en función del alcance de la tarea como se acaba de describir. (Pero por supuesto, no te han dicho todo).

El primer múltiplo es el tiempo adicional necesario para recodificar después de la primera demo/prototipo dado al jefe y le dice: "Bueno, muy bien. Pero se puede añadir ..."

El segundo múltiple es el momento necesario para recodificar el recodo hasta el estándar correcto para la producción.

El tercer múltiplo es el momento de la prueba, la documentación & implementación y todas las otras cosas de administración que necesita hacer para realmente sacar el disco y en vivo.

Y el cuarto múltiplo es su contingencia para lo anterior.

Esto debería darle una estimación segura. Por supuesto, debe insistir en que se realice un ejercicio de planificación y estimación más exhaustivo.

0

Creo que la respuesta siempre es "de seis a ocho semanas".

0

"seis a ocho semanas" funciona muy bien, otra cosa que funciona se basa en el modelo de datos.

Imagine el número de tablas de bases de datos (o similares) necesarias para la aplicación, multiplique eso por el número de días que necesita codificar los modelos, CRUD, UI, etc. para cada tabla y agregue entre 30% a 50% de tiempo además de eso.

Cuestiones relacionadas