¿Cómo se da un cálculo de tiempo válido para algo que nunca se ha hecho?

Question

Como un 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 en Evidence Based Scheduling, pero ¿cómo puede aplicarse si no tengo ninguna evidencia ?

Agradezco cualquier consejo sobre este tema.

Answer 1

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

Si usted lo hace muy claro que:

• No se puede dar una estimación precisa
• Es totalmente razonable que no se puede dar una estimación precisa porque es un trabajo diferente a lo que has hecho antes
• podrás actualizar la estimación conforme pasa el tiempo y se llega a conocer mejor el tema

Creo que debería estar bien. Sin embargo, tiene que hacer que esas cosas sean muy claras, por escrito, para que no se quede con sus estimaciones aproximadas más adelante.

Answer 2

se le permite decir "No sé, no tengo suficientes pruebas"

entonces algunos prototipos para obtener algunas pruebas.

A continuación, responda la pregunta.

Por lo tanto, es posible que pueda dar una estimación de cuándo podrá dar la estimación.

Answer 3

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 muy claro que se trata de una estimación aproximada basada en su comprensión del problema y la forma de resolverlo.

Además, no proporcione ninguna estimación aproximada en incrementos muy precisos. 4.5 horas no es una estimación aproximada. Medio día es una estimación aproximada.

Answer 4

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 desea que esa estimación sea de 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.

Por lo tanto, la solución a esto es entender el problema a la hora de calcular las estimaciones. Para proyectos más pequeños & corrección de errores esto es bastante sencillo:

• Repita el error en su 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 habrían arrojado su estimación.

Lo interesante de este método es que el tiempo que se tarda en 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 practique con esto, obtendrá cada vez mejor "saber" cuánto tiempo llevará. Al principio, solo podrá "saber" cuánto tardarán los proyectos más pequeños. Pero con el tiempo podrá estimar proyectos mayores de &.

Answer 5

En lo personal, me imagino una estimación de una distribución estadística - y tratar de comunicar la idea de desviación estándar con ella:

10 es 'que tiene una probabilidad del 50% a ser de 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.

(También, una estimación no debe ser un compromiso en resultados - de lo contrario, se rellena hasta la muerte y se vuelve inútil)

Answer 6

Aunque es muy áspera, calculo de 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. Mantenga en cuenta que sólo para la codificación de un solo hombre del ejército:

• Un pequeño proyecto de 1000 líneas de código (lógica) puede realizarse en una o dos semanas
• Un proyecto medio complejidad de 10.000 líneas de (lógica) podría completarse en dos o tres meses.
• Un gran proyecto de 100.000 líneas de código (lógico) requieren 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, realice un seguimiento de su estimación de la complejidad, las líneas de código, considere 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 aproximada.

Sugiero the mythical man month. Es un libro fantástico sobre este tema.

Answer 7

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.

Answer 8

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 antes 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.

Answer 9

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

Identifique una estrategia sobre cómo abordará 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úe con la primera iteración y aplique lo que sepa sobre los supuestos que realizó. ¿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.

Answer 10

Hago esto todo el tiempo.Casi todo lo que hago es la primera vez. ¿Cómo calculo? I 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, descubrí qué se ve y qué parece difícil

Answer 11

Probar Function Point Analysis. 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íjese que FPA es malo en software algorítmicamente pesado, y se basa en PROMEDIOS, lo que significa que probablemente sobreestimar o subestimar cada proyecto.

Answer 12

mi compañero de trabajo siempre dice, primero estima la longitud del proyecto, luego multiplícalo por dos suma 1 y luego agrega 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.

Answer 13

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 :)