Algunos consejos del lado oscuro de alguien que aprendió de la manera más difícil.
Los requisitos no están claros. Nadie ha hecho un análisis en profundidad de
Todas las implicaciones.
No hagas una estimación en este punto. Uno no calcula cuántos soldados se necesitan para ganar una batalla sin tener idea de los números enemigos. La estimación se realiza después de la exploración. Esto es a menos que ya hayas luchado contra este enemigo.
La nueva función probablemente romperá algunas suposiciones que hiciste en tu
código y empiezas a pensar inmediatamente en todas las cosas que podrías
Hay que refactorizar.
Esta es su responsabilidad de tener en cuenta a menos que espere que otros tengan experiencia en esta área.
Usted tiene otras cosas que hacer de asignaciones anteriores y tendrá que
elabore una estimación que tenga en cuenta ese otro trabajo.
Igual que el anterior, incluso para el trabajo no anticipado que fue creado por un compañero de equipo slob a tu lado con un procedimiento de prueba casi inexistente que hace que tu código falle y que no puedas predecir perfectamente de antemano. Es un pronóstico del tiempo.
La definición de "hecho" probablemente no esté clara: ¿cuándo se hará?
'Hecho' como acaba de terminar de codificar, o 'hecho' como en "los usuarios están
usándolo "?
Comprenda el requisito de fin de usuario aquí, piense como un usuario. No haga lo que hacen sus compañeros si estiman que algo se "haga" simplemente porque alguna funcionalidad básica con un flujo de trabajo de barebones que ningún usuario pueda tolerar es lo que consideran "hecho" . Piénselo desde el punto de vista del usuario, ya que ese es el único cliente por el que está haciendo la estimación y que comprenderá. Calcule hacia los requisitos completos de usuario final, no hacia los requisitos técnicos de barebone. Y tenga en cuenta que sus clientes que solicitan estimaciones serán totalmente inexactos aquí acerca de cómo expresan las cosas y entienden los aspectos técnicos de lo que usted dice.
No importa cuán consciente seas de todas estas cosas, a veces tu
El "orgullo del programador" te hace dar / aceptar tiempos más cortos que tú.
originalmente supongamos que podría tomar. Especialmente cuando sientes la presión.
de plazos y expectativas de gestión.
¡No hagas esto! Pareces un trabajador muy motivado y posiblemente uno que cede fácilmente a la coacción.
El problema aquí es el siguiente: digamos que usted y Joe hicieron estimaciones de tiempo para la misma tarea (pero entre dos empleados separados, sin conocer ambas estimaciones al mismo tiempo). Usted estima valientemente, "una semana" . Piensa que está bien, trabajará más de 100 horas a la semana, horas extra sin pagar. Ahora llegas tres días tarde.
Mientras tanto, Joe estima 5 meses. Si crees que esto es ridículo, crees que puedes lograrlo en una semana. ¿Cuánto trabaja Joe? 10 horas a la semana? ... excepto que termina a tiempo en exactamente 5 meses.
¿Adivina quién es percibido como el burro? Así es, usted. Joe parece un gran trabajador, ahora pareces poco confiable. No importa tanto que podría haber logrado un resultado aún mejor en aproximadamente el 7% del tiempo que Joe tomó. Lo que importa es que tenías 3 días libres de una estimación de una semana.
Nunca errar en el lado de la estimación más estricta. Err en el lado de la estimación más flexible. Hay una reputación que construir en su empresa y no se basará en la longitud de sus estimaciones, sino en la exactitud de sus estimaciones. Es fácil ser preciso con una estimación demasiado larga, solo tienes más tiempo para resolver el problema y resolverlo mejor. Un cálculo demasiado corto no deja espacio para respirar, lo satisfaces desesperadamente o estás jodido.