Cómo estimar una tarea de programación si no tiene experiencia en ella [cerrado]

Estoy teniendo dificultades con la administración para solicitar estimaciones sobre tareas de programación que utilizan controles de terceros con los que no tengo experiencia previa.

Definitivamente entiendo por qué querrían las estimaciones, pero siento que cualquier estimación que dé será a) demasiado corta y me hará quedar mal ob) demasiado larga y me hará quedar mal.

¡Qué estimación o respuesta podría darle a la gerencia para que me los quiten de encima y pueda seguir haciendo mi trabajo!

La mejor respuesta que puede dar es pedir tiempo para crear un prototipo rápido que le permita dar una estimación más precisa. Sin alguna experiencia con una herramienta o un problema, cualquier estimación que proporcione no tiene sentido.

Aparte, rara vez hay problemas con dar una estimación demasiado larga. Se producen problemas imprevistos, las prioridades cambian y los requisitos se "actualizan". Incluso si no usa todo el tiempo que solicitó, tendrá más tiempo de prueba o puede lanzarlo "temprano".

Siempre he sido demasiado optimista en mis estimaciones, y eso puede generar mucho estrés en tu vida, especialmente cuando eres un programador joven sin la experiencia y la confianza en ti mismo para decirles a los jefes verdades incómodas.

Te contaré un secreto. Incluso si fuera un experto en esa tecnología, es probable que su estimación sea muy inexacta. Es la naturaleza de la bestia cuando se hace algo que es inherentemente una tarea de I + D. Desafortunadamente, la gerencia a menudo intenta aplicar un modelo de fabricación y exige estimaciones precisas. Para ilustrar mi punto, considere la dificultad de estimar con precisión los siguientes dos esfuerzos:

A) Fabrica otros paraguas 11K que sean exactamente los mismos que los 2K que produjiste el mes pasado. B) Diseñe un nuevo tipo de paraguas y construya el primero.

El desarrollo de software es B, pero piden una estimación asumiendo A.

Lo mejor que puede hacer es dividir la tarea en las partes más pequeñas posibles (no más de 1/2 día cada una) y luego triplicar el número final que se le ocurra (Método Spolsky).

Alternativamente, Steve McConnell tiene un libro completo (posiblemente varios) sobre este aspecto de la ingeniería de software. http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351

Steve McConnell (y otros) habla sobre el cono de incertidumbre . Básicamente, proporciona una estimación que se parece a esto:

El trabajo durará entre 3 y 9 semanas, siendo lo más probable 4 semanas.

A medida que avanza el proyecto, puede refinar su estimación. A medida que haga más trabajo y comprenda mejor el esfuerzo requerido, podrá refinar su estimación para que sea más precisa.

Me ha funcionado, pero puede requerir cierto esfuerzo lograr que otras partes interesadas del proyecto comprendan el proceso.

Es posible que desee considerar dar tanto una estimación como un nivel de confianza, es decir, es 50/50 que tomará de 3 a 6 meses o de 6 a 9 meses o un 75% de posibilidades de hacerlo en 9 meses y un 90% de que será hecho en un año.

Otra cosa que quizás desee considerar es utilizar el enfoque de " sabiduría de multitudes ". Pregunte a 25-50 personas cuánto tiempo creen que les llevará y promedie sus estimaciones. El Planning Poker de Mike Cohn es, creo, muy similar a esto, aunque difícil de planificar con un solo desarrollador.

Divida su estimación en:

• Conocimientos conocidos ; cuánto tiempo tomará hacer lo que sabe hacer. Debería poder dar esta estimación con un alto grado de confianza.
• Desconocidas conocidas ; ¿Cuánto tiempo crees que llevará hacer lo que no sabes cómo hacer? Puede utilizar un método como el de dacracot para brindar diferentes niveles de confianza en esta estimación.
• Desconocidas desconocidas ; este es el agujero negro en tiempo real. Estas son las cosas que se levantan en los momentos más inoportunos y te muerden el culo. Proporcione un rango para la estimación con una justificación basada en los riesgos que anticipa.

Ofrezca ajustar la estimación y ciertos hitos a lo largo del camino. Cualquier incógnita desconocida se convertirá en incógnitas conocidas, las incógnitas conocidas deberían convertirse en conocidas a medida que usted gane experiencia, y la estimación de sus conocimientos conocidos se puede ajustar en función del progreso hasta la fecha. Puede hacer una estimación inicial, luego volver a estimar cuando haya terminado en un 25%, luego nuevamente al 50%, luego nuevamente al 85%. En cada hito, su estimación debería comenzar a converger con el tiempo real que tomarán las tareas.

Utilizo un sistema de etiquetado definido para mis estimaciones ... clase A, clase B y clase C.

La estimación de la clase C es la primera que obtienen. Se indica abiertamente como más o menos 50% debido a incógnitas. Si quieren que continúe dándoles una clase B, entonces necesito dinero para investigar.

La clase B es más o menos 25%. A veces esto es lo suficientemente bueno y me dan el dinero para construir. Si no, menos dinero y más investigación.

La clase A es más o menos un 10%, la final y pasa o no pasa. Si es un intento y me desvío demasiado de la estimación, lo confieso a menudo y temprano.

Creo que si elimina la frase "que utilizan controles de terceros con los que no tengo experiencia previa", es posible que tenga una mejor descripción de su problema más amplio.

Si "Agile" nos ha enseñado algo, es que, si la gerencia espera que usted, de manera continua, calcule los proyectos de esa manera, y "quedará mal" si dice que no se puede proporcionar porque no tiene suficiente información, estás en la autopista hacia FALLAR.

El mayor problema serán los problemas sobre los que no tienes control y que aún no has identificado. ¿Con qué frecuencia ha mirado hacia atrás y se ha dicho a sí mismo "Bueno, presioné mi estimación directamente en el botón - en el tercer intento, después de que descubrí que ... y que necesitaba una versión ... y que el dba estaría encendido vacaciones por una semana y que el Project Manager me necesitaría para ... por una semana y que mi esposa estaba embarazada y ... ".

Me esforzaría mucho en decir: "Puedo identificar los factores de riesgo críticos y elaborar una lista de verificación de entregables para probarlos en xx días. En ese momento, le daré otra estimación incremental".

Y sería muy bueno si pudiera sugerirles que deberían "Por favor, insista en que nunca trataré de darle una estimación creíble de ese tipo en el futuro. Despídame si lo intento".

(Exagerado, pero solo un poco).

Ni siquiera intentes estimar. No hay forma de que su estimación sea correcta. Después de todo, es solo una estimación.

En cambio, recomendaría que divida la función en partes pequeñas (no más de, digamos, 1-2 días) y trate de entregar estas partes como un código funcional, completo, comprobable y valioso para el cliente / gerente. De esa manera, verá por sí mismo su progreso en el día a día. Esto también significa que, de hecho, puede decidir detener el desarrollo una vez satisfecho y considerarlo completo, aunque no haya alcanzado todos los objetivos.

Eche un vistazo a las prácticas ágiles "Planificación de versiones" y "Planificación de iteraciones" para obtener información más detallada sobre este enfoque.

Tenga en cuenta que si solicita una estimación de tiempo mayor pero lo hace con menos tiempo, se ve mucho mejor que subestimar y tener que solicitar una extensión.

Intentaría simular un prototipo para que tengas una mejor idea del tiempo que llevará. Sea honesto con su gerencia para que puedan presupuestar retrasos inesperados en la curva de aprendizaje.

EDITAR: También puede ver si puede obtener una fecha límite más "iterativa". En "Pensamiento y aprendizaje pragmático", Andy Hunt hace un buen punto de que las personas son expertas en proyectos más cerca del final del proyecto y menos informadas al principio. No tiene mucho sentido hacer todo el diseño y la estimación del tiempo desde el principio, cuando todos son los que menos conocen el proyecto. Si "itera" los plazos y resuelve el problema por partes, tendrá más éxito.

Mucha estimación precisa es el autoconocimiento. Si ha escrito mucho código, si ha tenido que aprender muchas API, comienza a familiarizarse con preguntas como:

• ¿Cuánto tiempo me toma aprender una nueva API?
• ¿Cuánto tiempo me toma aprender un nuevo idioma?
• ¿Cuánto tiempo me toma aprender un nuevo conjunto de herramientas (compilador / enlazador / IDE)?
• ¿Cuánto tiempo me toma implementar una tarea típica?
• ¿Cuánto tiempo me toma probar mi trabajo?
• ¿Cuánto tiempo me toma implementar mi trabajo?

A lo largo de eso, debe tener una idea de cosas como:

• Cuántos errores típicos crea y cómo se clasifican (es decir, fácil, difícil, imposible)
• Cuántas complicaciones se introducen (es decir, es necesario refactorizar debido a la falta de API de terceros o API con errores; necesidad de rediseñar debido a un malentendido de la capacidad; herramientas / procesos de compilación no estándar)
• Cuánto tiempo se pierde debido a interrupciones / problemas externos

Con base en todas estas cosas, podrá desarrollar una idea de cuánto tiempo tomará algo y podrá enunciar sus suposiciones ("Suponiendo que la API es sana ...") incluso frente a información lamentablemente incompleta.

Estime cuánto tiempo necesita para aprender lo suficiente para hacer una mejor estimación, por ejemplo, "No sé: nunca he trabajado con esto antes. Probablemente me llevará insertar su estimación aquí para calcular qué necesitas aprender sobre esto, lo cual yo tendría que saber antes de poder darte una buena estimación para usar esto para terminar tu proyecto ".

Al programar, siempre he tomado lo que realmente pensé que me llevaría y lo multipliqué por 3 para proporcionar una estimación. Si creo que puedo hacer un trabajo en 1 semana, le digo al cliente que tomará 3; si creo que realmente me tomará 3 semanas, le digo al cliente 9 semanas.

Al hacer esto, me preparé para "bajo promesa, sobre entrega": si puede hacer esto con éxito, su vida será mucho mejor y sus clientes estarán extremadamente felices.

En su caso, seguramente querrá obtener al menos ALGUNA comprensión de en qué se está sumergiendo antes de proporcionar una estimación. Tal vez incluso necesite proporcionar una estimación sobre cuánto tiempo llevará proporcionar una estimación. Multiplicar por 3 mantiene contentos a los clientes.

Divídalo en cosas con las que tenga alguna experiencia. El acto de cortarlo le dará una mejor idea de lo que sabe y lo que no sabe.

Una vez que las piezas sean lo suficientemente pequeñas como para que puedan verse como tareas definidas individuales, algunas de ellas serán completamente inestimables. Para esos, prototipo primero, o simplemente déjese una cantidad de tiempo razonable, dependiendo del tamaño de la pieza. Si encuentra que tiene piezas poco estimables de más de 2 a 4 semanas de trabajo, vuelva a cortarlas primero.

Con el tiempo, llegará a algunas soluciones tecnológicas muy extrañas (que cree que deberían funcionar, pero no está seguro), y mucho trabajo por hacer para respaldar esas cosas, una vez que funcione. Habrá algunos fragmentos de diseño que faltan, por lo que es mejor elegir alguna biblioteca conocida o un algoritmo muy simple para la versión inicial.

Si no puede dividir las tareas, entonces debe contratar a alguien con suficiente experiencia que pueda (ya que su falta de experiencia también lo perseguirá de otras maneras). Si no puede contratar a alguien, entonces debería negociar por un período aleatorio largo (de 6 meses a 2 años) y dirigirse directamente a un prototipo desordenado (hasta que haya logrado tener suficiente experiencia para saber qué es lo correcto y qué incorrecto). Pero, si terminas dándote golpes, es importante no engañarte y pensar que lo estás haciendo de la "manera" correcta. Los prototipos estaban destinados a desecharse. Con suerte, una vez que se complete la cuenta regresiva del prototipo, estará listo para construirlo de verdad.

Pablo.

Simplemente adivine un número externo y comience a evaluar de inmediato, hágales saber que la información futura puede afectar sus estimaciones, pero que las mantendrá actualizadas.

Mientras evalúa, manténgalos informados, ya sea a través de un documento publicado en la web o actualizaciones semanales, pero siempre incluya una "fecha de finalización estimada" actualizada y los motivos (si los hubiera) de las extensiones.

La mayoría de los gerentes deben entender que, al pedir fechas de finalización, en realidad están diciendo "danos una idea de cómo podemos planificar nuestro horario" y "no solo tardes una eternidad".

Si termina extendiendo más de una o dos veces, reevalúe todo su horario en función de su nuevo conocimiento que apesta al estimar.

Agregaría a lo que dijo RB, cuando me encuentro en esta situación, estimo cuánto tiempo me tomaría con las herramientas con las que estoy familiarizado, y luego duplico esa estimación para construir una curva de aprendizaje.

La parte importante es la comunicación con la gestión que la estimación es una conjetura , si se presiona para una estimación más precisa o si intentan - Dios mío - vender que un límite de tiempo (seguramente sólo va a tomar usted 2 días para construir la nave Enterprise, eres bueno, eres) PEGATE A TUS ARMAS , no comprometas tu estimación o el hecho de que no es confiable.

Si la gerencia lo anula y marca el tiempo de la tarea, por ejemplo, "Bueno, tiene que hacerse en 2 días", hágales saber nuevamente que esa es su estimación, que es exactamente tan confiable como la suya.

Anote todo esto por escrito.

Me ocupo bastante de la estimación en mi trabajo y es un verdadero desafío. Uno de mis mayores desafíos es estimar cuánto tiempo le tomará a un desarrollador diferente realizar una tarea sin saber qué tan hábil será ese desarrollador.

Si bien es posible que vea algún éxito inicial con el método de "menos promesa, más de entrega", descubrirá que con el tiempo otras personas que siguen la escuela de pensamiento de "más de promesa, menos de entrega" le superan en la oferta. La falta de precisión volverá a morderlo de cualquier manera. La precisión está muy ligada a la experiencia y limita el número de incógnitas con la tecnología.

Una cosa que sugeriría es tener una idea del tipo de presupuesto en el que funcionará su estimación. Si tiene un presupuesto pequeño, no se vuelva loco con la tecnología desconocida y apéguese a lo que sabe. Si su presupuesto es un poco más flexible, puede permitirse experimentar un poco.

También reconozca que habrá algunas tareas en las que todo lo que puede proporcionar es un Wild Ass Guess (WAG). Para estos, debe establecer un tiempo mínimo para su estimación y dejar en claro que no sabe cuál es el máximo. A menudo, este tipo de estimación es motivo suficiente para que la administración elimine ciertas características / requisitos.

Esa es una habilidad indispensable que tanto el gerente de proyecto como el programador pueden tener (¡y por supuesto pueden dominar!). Encontré un artículo, Estimación de tareas de desarrollo de software hechas (un poco) más fáciles , que espero que ayude a una mejor estimación de las tareas del proyecto.

Todas las respuestas anteriores han cubierto prácticamente todo lo relacionado con la elaboración de la estimación en sí.

Una cosa que me gustaría enfatizar es realizar un seguimiento de su estimación (una pequeña hoja de cálculo de Excel a la Joel, o incluso un documento de Bloc de notas si es muy simple), y al final de cada día actualícelo a las cifras más precisas que ahora puede proporcionar . Incluso si no necesita transmitir esto a sus jefes, mantenerlo actualizado le da una mejor idea de cómo están progresando las cosas y, lo que es más importante, tendrá una buena idea de por qué. su estimación cambia a medida que avanza el trabajo. .

Hacer esto le ayudará a hacer mejores estimaciones en el futuro, tanto para esta tecnología específica como para otras que no ha usado antes, simplemente porque requiere que en algún nivel se dé cuenta cuando sus expectativas cambian a intervalos regulares y averigüe por qué sucedió eso. .

Calcular cuánto tiempo va a tomar algo es parte de su trabajo. Siempre que se entienda que es una estimación en lugar de una fecha límite, no debe tener nada de qué preocuparse. No hay nadie mejor posicionado para proporcionar una estimación que la persona que va a escribir el código. Si no puede proporcionar una buena estimación, entonces debe informar a la gerencia del riesgo asociado a su mala estimación para que puedan reconsiderar si vale la pena correr el riesgo de programar contra estos controles de terceros desconocidos.

Esa es una situación muy común: la necesidad de lidiar con lo desconocido. Una forma útil de abordar esto es darse cuenta de que, además de las tareas de programación reales, tiene algo que aprender, y la gerencia debe ser consciente de eso.

Cuando te encuentras en una situación como esta, el proyecto de repente se convierte en un proyecto de I + D y un tiempo más largo de lo normal no te hará quedar mal, ya que estás aprendiendo y produciendo programas. No sé qué tan rápido está aprendiendo o qué recursos tiene para lidiar con cualquier problema que pueda encontrar (Stack Overflow es una de las opciones que tiene).

Yo diría que debería estimar como de costumbre y luego multiplicar por 1,5 (si aprende rápido y tiene acceso a recursos para resolver sus preguntas) o por 2,5 si es un alumno medio y confía solo en usted mismo.

¡Espero que esto ayude!

Haga todo lo posible para dividir la tarea en partes manejables. Con algo de suerte, hay tareas específicas que están relacionadas con el componente de terceros involucrado y otras que están menos acopladas (y por lo tanto más fáciles de estimar). Entregue a la gerencia las estimaciones divididas y señale dónde se encuentran las estimaciones más inciertas.

Estoy totalmente de acuerdo con quien sugirió jugar y hacer prototipos. Establezca un plazo fijo para la actividad de creación de prototipos. ("Necesito dos días primero para mejorar esta parte de mi estimación").

¿Puedes dar un rango? 40-60 horas, ¿algo así?

Cuanto más pequeñas sean las tareas, más difícil será, si las puede agrupar, tendrá un poco más de "pendiente" ya que los errores pueden equilibrarse al final del proyecto.

Mire cualquier área en la que tenga experiencia y utilícela como guía. "La última vez que necesité crear una función que cambió la base de datos me llevó X". Buena suerte.