Para manejar las estimaciones a nivel de tarea y los informes de tiempo, he estado usando (aproximadamente) la técnica que Steve McConnell describe en el Capítulo 10 de Estimación de software. Específicamente, cuando llega el momento de crear estimaciones a nivel de tarea (justo antes de que comience la codificación en un proyecto), determino las tareas a un nivel bastante granular para que, siempre que sea posible, no tenga tareas con un solo punto. % de estimación estimada superior a cuatro horas. De esa manera, el proceso de estimación de tareas ayuda a construir el software mientras me ayuda a no olvidar las tareas durante la estimación. También tengo un rango de horas posibles para cada tarea, y usando los cálculos estadísticos que describe McConnell junto con mis datos de precisión histórica, puedo generar estimaciones en otros niveles de confianza cuando lo desee. Siento que este método me ha funcionado bastante bien. Estamos obligados a poner las tareas y sus estimaciones en TFS para el seguimiento, por lo que utilizo las estimaciones en el porcentaje de confianza que me dicen que use.
Sin embargo, no estoy seguro de qué hacer cuando olvido una tarea, o termino necesitando hacer un trabajo que no se encuentre dentro de una de las tareas que calculé. Por supuesto, tratar de evitar esta situación es lo mejor, pero ¿cómo puedo explicar las tareas olvidadas / modificadas? Quiero tener los mejores datos históricos que pueda para ayudarme con las estimaciones futuras, pero en este momento, básicamente solo estoy calculando si hice la estimación del 50% de confianza y si la hice dentro de la estimación a distancia.
Estaré encantado de aclarar lo que pregunto si es necesario; hágame saber lo que no está claro.
fuente
Respuestas:
El libro Waltzing With Bears: Managing Risk on Software Projects (por DeMarco y Lister, los autores de Peopleware) tiene un enfoque excelente para esto. Aquí está mi reinterpretación:
Haga una estimación de "todo va perfectamente". Por supuesto, todo rara vez sale perfectamente, por lo que es poco probable que suceda, digamos 0.1 por ciento. En otras palabras, solo un proyecto de cada mil saldrá perfectamente planificado. Esto es lo que la mayoría de la gente usa como su "estimación" que obviamente es una locura.
En cambio, debemos pensar en las estimaciones como distribuciones de probabilidad. Esta estimación del "mundo perfecto" es el punto más a la izquierda en la distribución de probabilidad estimada.
Luego haga una estimación de "si las cosas suceden así para proyectos similares como este". Esta estimación le ayuda a tomar "vista externa" ( http://wiki.lesswrong.com/wiki/Outside_view ), escapando de la falacia de planificación ( http://wiki.lesswrong.com/wiki/Planning_fallacy ).
Luego haga una estimación de "Estoy 90% seguro de que haremos X". Sé muy, muy seguro de que quieres decir 90% seguro. En otras palabras, espera tomar más tiempo que esta estimación solo una vez por cada diez proyectos que realice.
Ahora podemos usar su primera estimación como la estimación de probabilidad del 0.1% y su segunda como la estimación de probabilidad del 50% (temporada al gusto) y la tercera como su estimación del 90%, lo que le dará una buena curva.
Digamos que sus estimaciones de 0%, 50% y 90% fueron el 1 de mayo, el 1 de junio y el 1 de agosto, luego su curva de estimación se vería así:
Observe cómo el crecimiento de la probabilidad se ralentiza con el tiempo. Si alguien le pidió una estimación del 99.9% en este escenario, podría ser el 1 de enero del próximo año.
fuente
En una palabra: contingencia.
La contingencia es la cantidad que agrega por "otras cosas": las cosas que no puede tener en cuenta en otra parte de su estimación. ¿SMc lo cubre en la estimación de software? No puedo recordar y mi copia está en el trabajo (estoy de vacaciones respondiendo esto, qué triste estoy) ...
De todos modos, en general, hay tres tipos de contingencia que recomendaría mirar:
1) Contingencia específica de riesgo : es donde identifica un riesgo específico y agrega una cierta cantidad de tiempo para cubrir el posible exceso relacionado con él. Lo primero que debe quedar claro aquí es qué es un riesgo: es algo que puede suceder, que tendrá un impacto negativo en el proyecto, que está fuera de su control .
Esta última parte es crítica: no se trata solo de "cosas que tardan un poco más de lo que pensaba", es "el módulo de programación de terceros que nos han dicho que tenemos que usar, ya que es un estándar de la compañía que podría no estar a la altura de la tarea". La forma en que calcula cuánta contingencia de riesgo agregar es el porcentaje de probabilidad de que el riesgo pueda pasar expresado como un decimal (50% = 0.5), multiplicado por el impacto de ese riesgo (en el ejemplo, digamos que necesita escribir manualmente CRON trabajos en lugar de usar el planificador y esto llevará 10 días, este número es de 10 días).
Entonces, si hay un 50% de probabilidad de que su riesgo se cumpla, y tomará 10 días de esfuerzo para evitarlo, agrega 5 días. Sume todos los valores para todos los riesgos identificados en el proyecto y agréguelo al total.
2) La mierda sucede con la contingencia : la mejor descripción que he escuchado sobre ella, incluso si no es elegante. Es un proyecto de TI, sucede una mierda. Nunca funciona como crees que será, las cosas tardan más, te las pierdes, etc. En general, SH Contingency estará entre el 10% (mínimo absoluto) y el 25% (aunque puede ser mayor), siendo el 15% aproximadamente típico, el nivel exacto depende del nivel de incertidumbre y riesgo general (traslados de objetivos, requisitos inciertos, etc.) )
Si su PM no acepta SH Contingency (y es posible, es posible que no tenga experiencia en proyectos de TI o sea un optimista ciego), simplemente agréguelo a todas las cantidades individuales. Si sabe lo que está haciendo, tendrá un registro de riesgos propio y te amará por pensar en estas cosas. Ciertamente, si tiene algún tipo de calificación de PM (como PRINCE2), lo sabrá.
3) Cambio de contingencia : aquí es donde está bastante seguro de que el cliente generará cambios pero no quiere que sea un punto de contención. Agregue X días o X% y se coloca en una olla para los cambios que el cliente plantea. Hay dos formas de lidiar con esto: o les dices al respecto y es para que ellos gasten o no les cuentas al respecto.
La primera forma es mejor, pero necesita un cliente bastante educado y justo: las cosas se clasifican como cambios y él puede gastar su bote como lo considere conveniente (según usted estima las cosas a medida que surgen).
La segunda forma en que mencionas que es un cambio, pero no buscas cobrarle más. Debe tener en cuenta todas las cosas en las que lo gasta, por lo que si llega al punto de que se agota y tiene que volver al cliente y pedir más tiempo o dinero y le dicen "espera, yo" "Pagando, bla, bla, bla", puedes señalar todas las cosas que ya han cambiado y que no has cobrado como una señal de que no estás siendo completamente irracional. No siempre funciona, pero casi siempre fortalece tu mano en las discusiones.
Ninguno de esos tres cubre específicamente las cosas que has olvidado, pero creo que entre ellas llenarás muchos de los vacíos que tienes.
fuente
Cuando se le solicite una estimación para una tarea, proporcione una estimación de alto nivel al equipo y obtenga una estimación de bajo nivel para usted, haciendo que siempre tenga tiempo después de completar la tarea para trabajar en algo que quizás haya olvidado mencionar en primer lugar.
fuente
¿Le preocupa que al agregar las tareas adicionales, sesgará su precisión histórica? ¿O crees que no incluir las tareas adicionales sesgará la precisión?
Creo que para lo mejor del proyecto, las tareas deben ingresarse en el sistema de seguimiento. Estoy seguro de que el líder del proyecto podrá ofrecer una explicación adecuada a la gerencia para las discrepancias ...
fuente