Preocuparnos por la estimación nos vuelve mejores desarrolladores

Creo que se ha escrito mucho sobre estimación de tareas. Metodologías, formas , intenciones, colores, juegos de Azar. Mucho.
Ahora , no he leido todavía las razones por las cuales nos conviene estimar bien a nosotros, los que estamos involucrados mas directamente en el proceso de construcción de software.

Pero primero, qué entiendo por estimación? al menos desde el punto de vista de sistemas; es predecir en función de nuestro buen juicio sobre ciertas tareas que estamos realizando cuanto tiempo nos demandará realizarlas. Debido a que justamente nuestro "buen juicio" es un atributo muy maleable, se han creado distintos métodos para darles una conciencia de mensurabilidad a este criterio ó "buen juicio".


Aparte es sumamente influenciable por cuestiones internas ( "Hoy tengo ganas de trabajar ? ", "Discuti con mi novia / esposa /hijos / padres", "Mi jefe es o se hace, que lo codee él", etc, etc) y cuestiones externas ( "esto tiene que ser entregado para ayer, como venimos ?", "Aparecio un cliente mas, que nos dará un incremento en el tráfico de la herramienta del 500%; estamos preparados para manejar este flujo? deberíamos...", "El proceso requiere para que evolucione mejor un refactor, ya que nos dimos cuenta que esta grilla la vamos a reutilizar, conviene  que sea mas inteligente").

Dados los factores , externos e internos, impactan en un alto grado de falla en nuestro buen juicio en cuanto a los tiempos de implementación, lease estimación y además, son demasiados. Es necesario como desarrolladores , asi como conocer nuevas herramientas y frameworks ( es un must para mantenernos actualizados) debemos conocer esta herramienta soft de la cual somos únicos responsables de mejorarla y conocer sus alternativas.

Solo nosotros conocemos lo que nos  implica llegar a un deadline, debemos poder en un punto poder conocer que grado de imprevisibilidad nos manejamos, y al menos manejar, dar visibilidad sobre los riesgos de dicha cuestión. Saber que nos implica hacer algo y que factores nos afectan nos podrán dar la capacidad para desenvolvernos independientes y la fiabilidad de las personas en quien confía en nosotros un desarrollo.

Una vez que entendemos los factores , deberíamos tener y haber logrado mucha mas firmeza y claridad a la hora de defender nuestra estimación.Para poder defenderla y hacerla menos discutible, debemos entender todos los temas que nos afectan, y eso nos llevará a lograr ganarnos esa confianza.

Nuestra estimación debe estar fuertemente basada en argumentos. No podemos hablar sin fundamentos. No podemos validar nuestra postura sin un test que lo avale; ups ! perdón , se me escapo el TDD developer que soy.. pero , acaso ..no es así ?; Entonces busquemos firmeza en nuestras aseveraciones conociendo y hechando mano a que cuestiones nos afectan para poder ser mejores estimando. Porque cuando mejores somos estimando, mejores desarrolladores somos ( al menos , entre las infinitas cualidades que existen para hablar de ser un buen desarrollador, habremos ganado una muy intangible y poderosa ), ya que conocemos claramente el alcance de hacia donde iremos/llegamos, que impacto vamos a tener en nuestro producto y a futuro mas dueños de nuestras decisiones en cuanto a tiempos.

Que temas nos dan una idea de que sabemos con que grado estamos estimando ?

Voy a tratar de desarrollar en items temas que para mi punto de vista nos dan una evaluación para nosotros del  grado de la calidad de nuestras estimaciones; En la medida que mejor las manejemos, más cerca estaremos de ser precisos.

1.-  Grado de Switch context:
Debemos tener en cuenta siempre el contexto en el que nos movemos. A medida que poseamos mas Señority en nuestra profesión, se nos demandará que estemos menos enfocado en las cuestiones propias de la construcción del proyecto para empezar a ser los referentes de otros ó prestar atención a otros Issues no relacionados al proyecto ( ni hablar si estamos en varios proyectos ). Esto nos afecta claramente la estimación. Tener en cuenta cuanto tiempo pasamos en reuniones antes que enfocados en cómo dar eficiencias al algoritmos, nos da gimnasia en otros temas, pero nos saca foco , tiempo y destreza en esto puntualmente que nos demandan. A la hora de estimar, tener claro esto , y no denostarlo.


2.- Calidad del Producto:
Otra vez calidad ? Hay muchos libros, pienso en "Clean Code" y listo. Pero aquí apunto a lo que cada uno de nosotros entiende por calidad. Si no entendemos el concepto del vamos estamos en problemas y tenemos que empezar a adquirir tal concepto. Si lo entendemos y sabemos por donde pasa, entonces llegamos un punto a saber el status de nuestra "mejor" obra y/ó por donde pasa algo que directamente es una bomba de tiempo. El punto es tener muy claro la deuda técnica que dejamos.

Yo encuentro estos 4 niveles , de peor calidad a mayor:
1.- Código sin testear , con metodos de mas de 20 lineas, y poca modularizacion, Muy acoplado.
2.- Código  testeado, reproducible , aunque con muchas falencias de diseño. Si estamos en objetos se carateriza por muuuchos Ifs.
3.- Testeado , modularizado de a partes, pero con cosas en algún punto repetidas. con funcionalidad de mas.
4.- Testeado. Se usó TDD. Hay los patrones Justos. Arquitectura hexagonal. Una belleza.

En general cada uno de estos niveles, entender los pros y cons, van de la mano del Señority, pero a veces tambien implican mas tiempo. o estamos en un transcurrir del punto 2 al punto 4 ( El refactor de TDD ). Si supimos diferenciar bien nuestros commits, sabremos a que punto llegaremos con tal tiempo. Si la calidad es un compromiso, los commits debe ser nuestra firma. Para poder dar signos de esa firma debemos saber cuando llegaremos a cada compromiso. Esto debe ser claro a la hora de estimar. Cuando la calidad y los puntos de fallos sean casi minimos, contra primeras estimaciones y entregas, es que empezaremos a ganarnos nuestra confianza no solo de nosotros si no de quienes usan nuestro código; Este es el punto donde empezamos a lograr que nuestra estimación no sea cuestionable.

3.- Visibilidad de las tareas, Ser inquisitivos sobre el alcance del proyecto:
Debemos saber qué se pretende y adonde queremos llegar. Trabajar en modo autómata decididamente nos resta a nuestra capacidad. En esta postura solo desarrollamos cosas que no sabemos como funcionan del todo dentro de un contexto de un todo ; Queremos ser un asset que sume al equipo ? indudablemente debemos saber que hacemos y que impacto tiene nuestro trabajo. En función de eso sabremos que grado de entrega haremos , por ende estimaremos mas precisos en función de la necesidad del cliente.


Entiendo que esta lista podría alargarse muchísimo más; ya que la pregunta de fondo que nos podemos hacer es : ¿ Qué cosas son las que nos hacen mejores profesionales en It, y que a la vez nos dejan satisfechos a nosotros con nuestro propio desempeño ? Pero esto es tema quizas de otro post. Por ahora me quedo con la intención , con las ganas de haber logrado que vos , que día a día lidias con la incertidumbre de no saber cuando finalizas tus tareas, apuntes cada día a poder lograr ser más preciso y confiado con tus estimaciones.

Para finalizar, como una vez escuche a una persona que desde mi punto de vista entendía muchísimo por donde venía la mano: " Siempre , no importa el contexto, siempre se puede estimar". Yo agrego: "La precisión nos la dá el contexto"

Gracias!