¿Cómo estimar el tiempo de programación?

La estimación requiere práctica. También requiere trabajo. Requiere tanto trabajo que puede ser una buena idea estimar el tiempo que tomará hacer la estimación, especialmente si te piden que estimes algo grande.

Cuando te piden que proporciones una estimación de algo grande, lo más honesto es hacer una pausa. La mayoría de los ingenieros son entusiastas y ansían complacer, y hacer una pausa ciertamente desagradará a quienes están a la espera. Pero una estimación instantánea probablemente no será precisa ni honesta.

Mientras te tomas tu tiempo, puede ser posible considerar hacer o prototipar la tarea. Si la presión política lo permite, esta es la forma más precisa de producir la estimación y hace un progreso real.

Cuando no es posible tomarse el tiempo para una investigación, debes establecer claramente el significado de la estimación. Reafirma ese significado como la primera y última parte de tu estimación por escrito. Prepara una estimación por escrito descomponiendo la tarea en subtareas progresivamente más pequeñas hasta que cada tarea pequeña no sea de más de un día; idealmente, la mayoría debería durar solo un día. Lo más importante es no dejar nada afuera. Por ejemplo, la documentación, las pruebas, el tiempo de planificación, el tiempo de comunicación con otros grupos y el tiempo de vacaciones son todos muy importantes. Si pasas parte de cada día lidiando con situaciones difíciles, incluye un ítem para eso en la estimación. Esto le brinda a tu jefe visibilidad sobre en qué estás utilizando tu tiempo como mínimo, y podría conseguirte más tiempo.

Conozco a buenos ingenieros que inflan las estimaciones implícitamente, pero recomiendo que no lo hagas. Uno de los resultados de inflar es que la confianza en ti puede disminuir. Por ejemplo, un ingeniero podría estimar tres días para una tarea que realmente cree que tomará un día. El ingeniero puede planear pasar dos días documentándolo o dos días trabajando en algún otro proyecto útil. Pero será detectable que la tarea se hizo en solo un día (si resulta ser así), y surgirá la apariencia de descuido o sobreestimación. Es mucho mejor dar una visibilidad adecuada a lo que realmente estás haciendo. Si la documentación lleva el doble de tiempo que la codificación y la estimación lo refleja, se obtiene una ventaja tremenda al hacer esto visible para el gerente.

Realiza un ajuste explícito en lugar de forma implícita. Si una tarea probablemente llevará un día, pero podría llevar diez días si tu enfoque no funciona, indícalo de alguna manera en la estimación si es posible; si no, al menos haz un promedio ponderado según tus estimaciones de las probabilidades. Cualquier factor de riesgo que puedas identificar y al que puedas asignar una estimación debe incluirse en el cronograma. Es poco probable que una persona se enferme en una semana específica. Pero un proyecto grande con muchos ingenieros tendrá algún tiempo de enfermedad, al igual que tiempo de vacaciones. ¿Cuál es la probabilidad de un seminario de capacitación obligatorio para toda la empresa? Si se puede estimar, inclúyelo. Por supuesto, hay incertidumbres unk-unks (desconocidas), o unknown unknowns (Desconocidos desconocidos). Por definición, los unknown unknowns no se pueden estimar individualmente. Puedes intentar crear un ítem global para todos los unknown unknowns, o manejarlos de alguna otra manera que comuniques a tu jefe. Sin embargo, no puedes permitir que tu jefe olvide que existen, y es increíblemente fácil que una estimación se convierta en un cronograma sin tener en cuenta los unknown unknowns.

En un entorno de equipo, debes intentar que las personas que realizarán el trabajo realicen la estimación, y debes buscar el consenso en toda el equipo sobre las estimaciones. Las habilidades, la experiencia, la preparación y la confianza de las personas varían ampliamente. Ocurre una calamidad cuando un programador hábil estima para sí misma y luego se espera que los programadores menos hábiles cumplan con esa estimación. El hecho de que todo el equipo esté de acuerdo, línea por línea, en la estimación aclara la comprensión del equipo, además de permitir la oportunidad de reasignación táctica de recursos (por ejemplo, aliviar la carga de los miembros más débiles).

Si hay riesgos importantes que no se pueden evaluar, es tu responsabilidad afirmarlo con la suficiente fuerza para que tu gerente no se comprometa con ellos y luego se sienta avergonzado cuando ocurra el riesgo. Con suerte, en tal caso, se hará todo lo necesario para disminuir el riesgo.

Si logras convencer a tu empresa de utilizar Extreme Programming, solo tendrás que estimar cosas relativamente pequeñas, lo cual es más divertido y más productivo.

Siguiente ¿Cómo encontrar información?