Teoría de la probabilidad y planificación de proyectos

Question

Estoy administrando un proyecto que debe ser estimado, de acuerdo con los requisitos y especificaciones generales. Debido a eso, las estimaciones sobre las características y tareas específicas se establecen de valores discretos, en lugar de un solo valor discreto (por ejemplo, entre 10 y 20, en lugar de exactamente 17).

Tengo curiosidad, si quiero tener una idea de la probabilidad aproximada de terminar alguna tarea dentro de la estimación más baja, ¿cómo debería abordar esto? Por favor, por el bien de la discusión, hacen caso omiso de factores como mis habilidades de estimación, la plataforma utilizada, etc.

Estaba pensando acerca del uso de Poisson distribution, con λ = (bajo + alto)/2, en el supuesto de que la probabilidad para cada una de los valores propuestos se atienen a la ley de eventos raros/distribución normal. Esto no tiene en cuenta el hecho de que salir de mis límites de estimación es más improbable que probable, pero aún así ...

¿Qué opina de eso y qué enfoque elegiría para dicho experimento?

Answer 1

Evidence Based Scheduling

Básicamente la idea es observar la cantidad que se necesita en su equipo para completar tareas similares para estimar cuánto tiempo podría tomar para otro de esos que ser terminado.

Answer 2

Poisson se ha realizado tantas veces, con la misma tasa baja de éxito. Superviso la programación basada en pruebas, porque se autocorrige y funciona en datos reales.

Answer 3

Recomiendo leer Waltzing With Bears por Tom DeMarco y Tim Lister - va dentro del cronograma de cálculo con cierta profundidad.

Como regla general, diría que la probabilidad de terminar cualquier proyecto dentro del tiempo estimado más bajo es aproximadamente cero. Esto es tanto del análisis que dan en el libro, como de la experiencia personal.

Answer 4

No creo que tenga la información para hacer esa llamada. Para hacerlo, necesitaría saber si la curva de probabilidad estaba normalizada (probablemente) y si estaba sesgada (casi con certeza) más los diversos valores estadísticos asociados (media, desviación estándar, etc.).

Si tiene esas, no creo que las pregunte. Además de su habilidad para estimar, las suposiciones que ha realizado, su precisión, etc., son todos factores, la mayoría de los cuales son muy difíciles de cuantificar.

Es por eso que la programación basada en la evidencia es buena, no es necesario que entiendas exactamente por qué las cosas tardan cierto tiempo, simplemente sabes que lo hacen.

Un par de cosas simples diría que debe pensar:

1) En mi experiencia, las posibilidades reales de que sea su estimación más baja son aproximadamente cero. Mierda sucede en proyectos de software, la mayoría de las personas no son tan buenas para estimar y las cosas saldrán mal. Si quieres una buena estimación, entonces sigue con eso.

2) Piense cuidadosamente sobre para qué quiere el número. Si va a dárselo a un cliente o a la mayoría de los gerentes, entonces:

(a) no recordarán las advertencias, el no recordará el extremo superior del rango y no recordará las probabilidades o la teoría Recordarán el buen número bajo que les diste y el resto es solo "wah wah wah".

(b) los clientes y gerentes desean tener certeza, por lo que debe proporcionarles algo de lo que esté seguro. Si supone que su cálculo se distribuye normalmente y tiene los mejores y los peores valores posibles, si les da un promedio de los dos, perderá su fecha límite el 50% del tiempo. Desde la perspectiva de los gerentes eso es malo. Si quiere alcanzar su fecha límite el 95% del tiempo, entonces debe dar la media + 2 desviaciones estándar. De nuevo, si quiere una estimación aproximada, su peor caso es probablemente el número más fácil de obtener.

En general, bajo promesa y entrega excesiva. Sea el tipo que nunca pierde plazos y, a menudo entrega temprano. Eso no implica cambiar la forma en que trabajas, solo tienes que gestionar las expectativas.

Answer 5

Sugiero usar Three Point Estimating. Asigne el mínimo, el más probable y el tiempo máximo y el tipo de distribución aleatoria (Pert, Triangle, Beta, etc., según las características o los datos históricos) a cada una de sus tareas dentro del proyecto. Simule con Monte Carlo varias veces (por ejemplo, 5000 veces) y vea qué se suma. También puede ir más allá incorporando el elemento de riesgo (y también la correlación entre los riesgos si lo desea) para obtener una mejor idea de lo que podría suceder. Una herramienta como Palisade @Risk podría ayudarte.