Cómo Estimar el TIEMPO de PROGRAMACIÓN

La estimación toma práctica. También conlleva trabajo. Requiere tanto trabajo que puede ser una buena idea estimar el tiempo que tomará hacer el estimado, especialmente si se te pide estimar algo grande.

Cuando se nos pide proporcionar un estimado de algo grande, la cosa más honesta por hacer es detenerte. La mayoría de los ingenieros son entusiastas y propensos a agradar, y el que detengas ciertamente desagradará al detenido. Pero un estimado al
vuelo probablemente no será preciso ni honesto.

Mientras estás en standby, puede que sea posible considerar el hacer un prototipo de la tarea. Si la presión política lo permite, esta es la forma más exacta de producir el estimado, y constituye un progreso real.

Cuando no es posible tomarse tiempo para alguna investigación, deberías establecer primero el significado del estimado muy claramente. Replantea ese significado como la primera y última parte de tu estimado escrito. Prepara un estimado escrito
descomponiendo la tarea en subtareas progresivamente más pequeñas hasta que cada una de esas pequeñas tareas no exceda más que un día; idealmente a la mayoría en duración. Lo más importante es no dejar nada fuera. Por ejemplo, la documentación, la prueba, el tiempo para la planeación, el tiempo para comunicarse con otros grupos, y las fechas de vacaciones son también todas muy importantes. Si pasas una parte de cada día lidiando con cabezas duras, incluye un ítem para eso en el estimado. Ello le da a tu jefe la visibilidad de en qué está usándose tu tiempo hasta el mínimo, y podría procurarte más tiempo.

Conozco buenos ingenieros que rellenan estimados implícitamente, pero te recomiendo que no lo hagas. Uno de los resultados de rellenar es confiar en que pueden reducirte. Por ejemplo, un ingeniero podría estimar tres días para una tarea que realmente piensa que tomará un día. El ingeniero puede planear el pasar dos días documentando, o dos días trabajando en algún otro proyecto útil. Pero será visible que la tarea fue hecha en solamente un día (si resulta ser así), y nacerá la apariencia de flojera o sobreestimación del tiempo. Es mucho mejor brindar una apropiada visibilidad de lo que realmente estás haciendo. Si la documentación toma dos veces más tiempo que la codificación y el estimado así lo dice, se gana una tremenda ventaja al hacer esto visible al administrador.

En su lugar rellena explícitamente. Si una tarea probablemente tomará un día---pero podría tomar diez si tu método no funciona---has notar esto de algún modo en el estimado si puedes; si no, al menos haz un promedio ponderado por tus estimados de las probabilidades. Cualquier factor de riesgo que puedas identificar y asignarle un estimado debería ir en el calendario. Es poco probable que una persona pueda estar enferma en alguna semana dada. Pero un proyecto grande con muchos ingenieros tendrá algún tiempo de enfermedad; al igual que tiempo para vacaciones. ¿Y qué hay de la probabilidad de un seminario de entrenamiento obligatorio para toda la compañía? Si puede ser estimado, inclúyelo. Existen por supuesto, desconocidos desconocidos, o unk-unks (del inglés unknown-unknowns). Los unk-unks por definición no pueden ser estimados individualmente. Puedes intentar crear un ítem global para todos los unk-unks, o manejarlos de alguna otra forma para que puedas comunicárselo a tu jefe. No puedes, sin embargo, permitir que tu jefe olvide que ellos existen, y es endiabladamente fácil para un estimado convertirse en un programa sin que sean considerados los unk-unks.

En un entorno de equipo, deberías tratar de tener a la gente que hará el trabajo de elaborar el estimado, y deberías intentar tener un consenso con el equipo en general sobre los estimados. La gente varía ampliamente en habilidad, experiencia,
preparación, y confianza. La calamidad golpea cuando un programador fuerte estima para él mismo y luego se le mantiene este estimado a los programadores débiles. El hecho de tener de acuerdo al equipo completo en una base de línea por línea del
estimado clarifica la comprensión del equipo, al igual que permite la oportunidad para la reasignación táctica de recursos (por ejemplo, intercambiar carga de trabajo de miembros del equipo más débiles a otros más fuertes).

Si existen grandes riesgos que no puedan ser evaluados, es tu deber establecerlos lo suficientemente fuerte como para que tu administrador no se comprometa a ellos y luego se avergüence cuando sucedan los riesgos. Hopefully en tales casos se hará lo
que sea necesario para disminuir el riesgo.

Si puedes convencer a tu compañía de usar la Programación Extrema, solamente tendrás que estimar cosas relativamente pequeñas, y esto es tan divertido como productivo.