¿Cómo puede estimar el tiempo para las tareas que consisten principalmente en resolver un problema?

53

Si bien es relativamente posible para un desarrollador con experiencia estimar cuánto tiempo tomará implementar el código cuando se comprende bien el patrón y el problema que el código está resolviendo, ¿cómo puede hacer una buena estimación de cuándo, mientras que el objetivo final es bueno? entendido, ¿la implementación es 95% teórica / resolución de problemas y tiene muy poca implementación?

Mi trabajo a menudo consiste en tareas para lograr objetivos bien definidos, sin embargo, tengo que encontrar la manera de alcanzar ese objetivo y hasta que no entienda la solución, no tengo claro qué barreras adicionales puede haber. Más específicamente, a menudo trabajo en la generación de código o en herramientas automatizadas de manipulación de código. Una vez que la solución esté totalmente resuelta y la herramienta perfeccionada, hará el 95% de los cambios reales muy rápidamente. Sin embargo, no tengo ninguna manera de estimar cuántos problemas adicionales deben resolverse para que la generación o la herramienta de análisis se ocupen de casos de borde imprevisibles.

Para propósitos de planificación, mi compañía quiere una mejor idea de cuánto tiempo tomará, pero como no sé cuántos problemas adicionales pueden surgir al resolver cada paso de la solución. No estoy seguro de cómo puedo acercarme para dar una mejor estimación.

    
pregunta AJ Henderson 21.03.2014 - 23:35

5 respuestas

40

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.

    
respondido por el user40980 22.03.2014 - 00:13
15
  

Jefe : AJ, tenemos 3 perros, 2 conejos, una catapulta y una monja. Necesitamos encontrar una manera de colocar los 7 (sí, la catapulta también) sobre una pared de 20 pies y al lago al otro lado sin que los perros coman conejos y sin ahogar a la monja. ¿Cuánto tiempo le llevará llegar a la solución?

Vea, el problema para estimar cuánto tiempo tomará resolver un problema es que le lleva a diferentes personas un tiempo diferente. Si tiene un historial de resolver problemas similares, puede estimar en función del tiempo que le ha llevado en el tiempo anterior. Si no lo haces, entonces no estás estimando, solo estás adivinando.

Además, el problema puede que ni siquiera tenga una solución aceptable. O tal vez la solución requerirá una autorización adicional que podría deshacer todo el proyecto. O tal vez la solución cambie toda la naturaleza percibida del problema, de modo que la solución se vuelva completamente innecesaria.

La moraleja de la historia es que, si no tiene suficiente información para hacer una estimación razonable, no . Aún no. Obtener mas informacion. Investiga más. Por lo general, está perfectamente bien decir: "Me pondré en contacto con usted en 2 días con algunos números más sólidos".

Al diseñar una solución para mi cliente, no firmaré un contrato hasta que haya completado el diseño general, por lo que sé cómo se verá la solución y cuánto tiempo tomará el proyecto. Esto significa que estoy en riesgo de haber realizado el trabajo de diseño inicial por el que no me pagan (si el proyecto no se lleva a cabo), pero eso es mejor que estar en riesgo de una facturación insuficiente por el trabajo que se está realizando. .

    
respondido por el tylerl 22.03.2014 - 00:17
4

Le sugeriría que intente algo a medio camino entre las respuestas de tylerl y MichaelT con lo siguiente:

  • divide el trabajo a realizar en 3 o 4 fases. Las fases deben ser:
    1. Análisis de problemas
    2. solución de prototipos
    3. solución del mundo real
    4. Evaluación de la salida (prueba)
  • proporcione una estimación solo para la fase 1 (análisis) según su experiencia, o en las fases 1 + 2 (análisis + prototipo) para su administración. Luego, bríndeles un estimado para las fases 3 + 4 cuando se completen las fases 1 y 2 del problema (o al menos lo suficientemente avanzado para que pueda tener confianza en su estimado).

La razón detrás es que sabes por experiencia que necesitas X días para analizar una base de código determinada (probablemente dependiendo de su tamaño) y tener un juego de herramientas básicas o scripts ejecutándose (y tal vez fallando). Luego, la cantidad de errores debería proporcionarle información sobre la dificultad real de la tarea en cuestión.

Puede que esto no sea exactamente lo que quiere la administración, pero creo que siempre es mejor hacer estimaciones que realmente cumplirás.

    
respondido por el sansuiso 26.03.2014 - 11:24
1

Como esta pregunta es principalmente sobre tipos de trabajo de investigación, preguntar a los desarrolladores de software es un enfoque valiente, una métrica común es que el desarrollador de software demora el doble de lo que su estimación probablemente sea un buen desarrollador. Sin embargo, dicho esto, las tareas de investigación (y diseño de arquitectura) son una parte muy importante de la programación, y a menudo se omiten / minimizan. También suelen ser difíciles de estimar.

La primera pregunta que me haría, ¿es este un problema que se puede resolver? Este no es un problema del intelecto o del cerebro, sino uno de realidad práctica. A menos que esté en el mundo de Google moon shots, donde el fracaso es un resultado esperado, la dura realidad es que se espera que entregue this , sea lo que sea this ser. Parece ser una regla general. ¿Ya sabemos cuál es el 90% de la solución?

La segunda pregunta que me gustaría hacer, ¿qué otra cosa sería útil saber al pensar en la solución? Esta es realmente una manera de verificar dos veces, sabemos lo suficiente como para encontrar una solución. eso sera aceptable Puede generar una serie de tareas de búsqueda de datos que ayudan a definir mejor cuál debe ser la solución, cada una de las cuales suele ser bastante fácil de definir y estimar.

La tercera pregunta es, ¿quién es el más adecuado en el equipo para este tipo de problema? Quienquiera que obtenga esta tarea complementará el resultado con su propio estilo. Dar este tipo de problema a un programador que tiene 10 millones de preguntas al inicio de una tarea, y luego desaparece y entrega algo por primera vez (aunque lentamente) puede ser una mejor opción que darle al programador que ejecuta la implementación rápidamente , pero cuando hay un problema, solo se descubre al final del proceso.

Entonces, la tarea real sería pensar en posibles soluciones, implementaciones y enfoques, y tener una escala de tiempo fija en la que deben informar.

Cuando vuelven a informar, entonces tiene la opción de obtener un conjunto más amplio de soluciones posibles, dar el visto bueno para implementar una solución o reflexionar, ya que la solución aún no está lo suficientemente clara

    
respondido por el Michael Shaw 26.03.2014 - 11:58
1

Con preguntas de investigación en las que no está claro si hay una respuesta, y mucho menos una idea clara de lo que se debe hacer, generalmente propongo dedicarle una cantidad de tiempo x para comenzar.

"No tengo idea de si esto es posible, pero podría pasar dos días investigándolo. Eso probablemente no nos dará una solución, pero quizás pueda descartar algunas cosas y probablemente tener una idea de lo que podrían ser algunos próximos pasos concretos y qué tipo de inversión de tiempo significarían. Luego podemos decidir si tiene sentido dar otro paso ".

Entonces, ponga la incertidumbre en la otra dirección: la estimación es bastante precisa (pasaré dos días), simplemente no se especifica qué se logrará para entonces.

Timeboxing, básicamente.

    
respondido por el RemcoGerlich 21.04.2015 - 11:43

Lea otras preguntas en las etiquetas