project management - management - ¿Cómo le das un tiempo estimado válido para algo que nunca has hecho?

project schedule traduccion (13)

Como nuevo desarrollador que es el único tipo de software en el personal, he enfrentado algunos desafíos, pero posiblemente el más difícil haya sido el de las estimaciones de tiempo. Lucho cada vez que tengo que dar una estimación del proyecto.

Mi pregunta es; Si no tengo ninguna experiencia y no tengo un compañero desarrollador en mi entorno, ¿cómo proporciono una estimación sólida? He leído el artículo de Joel Spolsky sobre la programación basada en la evidencia, pero ¿cómo puede aplicarse si no tengo ninguna evidencia ?

Agradezco cualquier consejo sobre este tema.

Aunque es muy difícil, estimo en Líneas de código. Este parámetro, cuyo significado para la productividad es cercano a cero, todavía le da una idea de la complejidad de un proyecto.

Mida el hecho de que, en promedio, un desarrollador puede escribir alrededor de 200, un máximo de 300 líneas de código por día. Tenga en cuenta que solo para codificar un ejército de un solo hombre:

Se puede hacer un pequeño proyecto de 1000 líneas de código (lógico) en una o dos semanas
Un proyecto de complejidad promedio de 10.000 líneas de código (lógico) podría completarse en dos o tres meses.
Un gran proyecto de 100.000 líneas de código (lógico) requiere al menos un par de años

Para el código lógico, debe agregar la prueba, que ya está incluida en las estimaciones anteriores. Para tener una idea de la complejidad, el Gimp tiene 600,000 líneas de código, un kernel varía en el millón o más.

A esto, agregue el hecho de que si está trabajando en cascada, el tiempo que necesita para desarrollar el código es en realidad una pequeña parte del tiempo necesario para desarrollar las especificaciones y el diseño. Estimo que un tiempo de 2/3 es para especificaciones + diseño, y el 1/3 restante va en codificación, tal vez incluso más en las especificaciones + parte de diseño. Es realmente lento.

Por lo tanto, haga un seguimiento de su estimación de la complejidad, a las líneas de código, tenga en cuenta la mano de obra que tiene y cuánto pueden trabajar en paralelo, y agregue la sobrecarga de especificaciones + diseño, obtendrá una estimación muy aproximada.

Te sugiero el mes hombre mítico . Es un libro fantástico sobre este tema.

Cualquier tarea o trabajo desconocido siempre tiene algo que se sabe hasta cierto punto y es fácil de estimar. Me separé y doy estimados de inmediato por las cosas que sé y por las cosas que siento que sé. El resto honestamente se declara como un punto débil y luego comenzamos a "negociar". Si el dador de trabajo confía en mi competencia, excepto mis estimaciones y riesgos generales, trabajamos juntos. Nunca fue un fracaso, simplemente porque nunca tomaría una tarea que no puedo levantar o correr al suelo (¿presentimiento?). Si el dador de trabajo no confía en mí, siempre recomiendo a quién preguntar y dónde buscar una mejor opción. Entonces, o trabajamos juntos o no. La mayoría de las veces lo hacemos, pero todos están seguros. Hago mi trabajo, "especialista en manchas" obtiene su corte, los gerentes están contentos y el cliente está satisfecho. Tal vez es un poco ingenuo, pero me funciona :)

Hago esto todo el tiempo. Casi todo lo que hago es la primera vez. ¿Cómo calculo? ¡ Supongo ! Y luego supongo de nuevo. Y sigo haciendo eso en cada intervalo delta-tiempo en que un horario se vuelve a trabajar, porque los planes del proyecto son iterativos y usted solo sabe lo que hace cuando lo hace. Mis conjeturas son bastante buenas aunque, después de muchos años, he descubierto lo que "parece" fácil y lo que "parece difícil"

IMO Joel está muy, muy lejos en su artículo, y sus conclusiones y recomendaciones no se basan en ninguna realidad. (Lo siento, Joel) Básicamente, él dice que deberías poder programar tu trabajo en unidades de tiempo de horas o menos incluso antes de que comiences. Pero la realidad es que no se sabe cuáles serán todas esas unidades de trabajo (en sistemas no triviales) antes de ingresar al código. Por lo tanto, no se puede llegar a un desglose de cada hora de lo que vas a hacer antes de que aparezca el capó y que ese desglose refleje lo que realmente sucede con precisión.

Dar una estimación del proyecto es muy difícil si quiere que esa estimación tenga algún valor. Programar con estimaciones precisas es difícil para los programadores porque muy a menudo no descubres todas las complejidades del proyecto hasta que te entiendes.

Entonces, la solución a esto es meterse debajo del capó cuando surjan las estimaciones. Para proyectos más pequeños y correcciones de errores, esto es bastante sencillo:

Replica el error en tu máquina.
Encuentra el código que está causando el error.
Descubre cómo escribir el código que arreglará el error.
Calcule cuánto tiempo le tomará escribir ese código.

Al encontrar el código que debe escribir, necesariamente debe descubrir la mayoría o todas las complejidades que hubieran arrojado su estimación.

Lo interesante de este método es que el tiempo que lleva generar la estimación suele ser el 90% del tiempo total para realizar el trabajo. Prácticamente tienes que hacer el trabajo para calcular un presupuesto. Con correcciones de errores especialmente, la solución suele estar en el orden de una línea de código, por lo que su estimación terminará siendo de 5 minutos. Eso está bien porque los plazos se pueden establecer en torno a estimaciones como esa.

A medida que practiques esto, mejorarás cada vez más al "solo saber" cuánto tardarán las cosas. Al principio, solo podrá "saber" cuánto tardarán los proyectos más pequeños. Pero con el tiempo podrá estimar proyectos más grandes y más grandes.

Para un programador experimentado, que al menos conoce el sistema y tiene un conjunto de requisitos razonables frente a ellos, "no sé" no es una respuesta válida. Si dices que no sabes que tu PHB se apagará y aplicará su 1337 h4x0r sk1lz y harás una estimación en el orden de "eso suena como un pedazo de pastel, ¿qué tal 1 hora?".

Debería poder descomponer el problema en una serie de pequeños problemas que haya resuelto anteriormente y obtener un número razonable para cada parte. Señale que es muy difícil y podría explotar considerablemente una vez que llegue al análisis completo del problema.

Se llaman ''estimaciones'' porque son difíciles. Se mejora al estimar haciéndolo más y aprendiendo a aprovechar la experiencia pasada tanto como sea posible. Recuerde tener en cuenta la contingencia (interrupciones, cambio de tareas, posibilidad de estar enfermo, posible reproceso, etc.). Generalmente, agregar 50% hace que la estimación se acerque más a la marca.

Personalmente, me imagino una estimación como una distribución estadística, e intento comunicar la idea de la desviación estándar con ella:

10 es ''tiene un 50% de probabilidad de estar entre 8 y 12''

Es difícil ser mucho más preciso que eso para las estimaciones generales del proyecto. Es perfectamente posible ser más preciso (dividir en historias independientes individuales, estimar colectivamente cada una, y otras prácticas ágiles), pero tiene un costo.

(Además, una estimación NO debe ser un compromiso con los entregables; de lo contrario, se amortigua y se vuelve inútil)

Primero baso mi estimación en la complejidad percibida del problema. Que tan grande es el problema. Cuántas piezas podría tocar o requerir Esto me da una pauta general. Luego, siempre me aseguro de agregar un factor de dulce de azúcar del 15-25% porque te vas a perder algo.

Finalmente, deja en claro que se trata de una estimación aproximada basada en su comprensión del problema y en cómo podría resolverlo.

Tampoco proporciones estimaciones aproximadas en incrementos muy precisos. 4.5 horas no es una estimación aproximada. Medio día es una estimación aproximada.

Proporcione una estimación aproximada y sea muy claro al respecto.

Identifica una estrategia sobre cómo abordarás el proyecto. Identifique especialmente las piezas del sistema que puede entregar como versiones intermedias de trabajo. Preste especial atención al más cercano de estos que pueda liberar completamente funcional y, si es posible, descanse el resto del alcance (conserve una lista de estos y cualquier cosa que surja, que se programará como un proyecto de seguimiento).

Use iteraciones cortas. Considera / analiza cómo encajan las versiones intermedias en iteraciones de 2-6 semanas. Tenga en cuenta los aprendizajes que esto le brinda, y ajuste la estimación general.

Continúa con la primera iteración y aplica lo que aprendas sobre las suposiciones que hiciste. ¿Qué tan apagado estás en las primeras iteraciones generalmente apuntan a un problema en las estimaciones. Resista la tentación de considerar la desviación en la parte de las estimaciones de la sobrecarga inicial, ya que probablemente retrase el momento en el que se da cuenta de que las estimaciones están desactivadas. Tenga en cuenta que entiendo / acepto que la velocidad del proyecto aumenta con el tiempo, pero pensar en eso tiende a ocultar / retrasar los problemas.

Pruebe el análisis de puntos de función . Para las cosas de CRUD da buenas figuras de estadio. Su principal ventaja es que no se basa en lo que va a implementar, sino en lo que el usuario ha pedido. Sin embargo, necesitará averiguar cuál es su productividad de PF. Puede usar proyectos anteriores en el mismo idioma para hacer eso.

Puede utilizar la productividad promedio para el idioma de destino si no puede construir un conjunto de datos históricos. Le dará algo, no necesariamente se acerca a la realidad, pero al menos le permitirá comparar esfuerzos para diferentes proyectos.

Ahora, fíjate que FPA es malo en software algorítmicamente pesado, y depende de PROMEDIOS, lo que significa que probablemente sobreestimarás o subestimarás cada proyecto.

Puedes decir "No sé, no tengo suficiente evidencia"

Luego haz algunos prototipos para obtener pruebas.

Entonces responda la pregunta.

Entonces, de hecho, puede dar una estimación de cuándo podrá dar la estimación.

Si se niega a dar un presupuesto por algo que nunca ha hecho, probablemente lo haga toda su vida. Primero divide la tarea tanto como sea posible, esto te ayudará a aclarar cómo vas a hacerlo. Hay más posibilidades de que pueda comparar un fragmento de la tarea con algo que haya hecho antes. No dude en comunicar su grado de certeza a su gerente.

Usted no proporciona una estimación sólida. Usted da la mejor respuesta posible y le explica que es solo una estimación aproximada y por qué es tan difícil.

Si dejas muy claro que:

No puedes dar una estimación precisa
Es completamente razonable que no puedas dar una estimación precisa porque es un trabajo diferente al que has hecho antes
Actualizarás la estimación a medida que pase el tiempo y podrás conocer mejor el tema

Creo que deberías estar bien. Sin embargo, debe dejar esas cosas muy claras, por escrito, para que no se deje llevar por sus estimaciones aproximadas más adelante.

mi compañero de trabajo siempre dice: primero calcule la duración del proyecto, luego multiplíquelo por dos, agregue 1 y luego agregue las siguientes unidades más altas. entonces, si tu respuesta es de 3 días, entonces dirías 7 semanas. eso es una broma a medias, una idea sería primero estimar el proyecto y luego, cuando termine de ver qué tan lejos estuviste, tal vez estés constantemente fuera por un múltiplo de 2 o 3, o lo que sea.