Estaba leyendo un artículo de Rodrigo Corral sobre estimaciones y de cómo se convierten en compromisos a veces, y bueno lo primero, estoy totalmente de acuerdo con Rodrigo y me han parecido artículos muy interesantes, y esto, también me lleva a pensar en uno de los grandes peligros a la hora de ajustarnos a las estimaciones para que sean lo más cercanas posibles a la realidad, y que es cómo muchas veces las estimaciones de los desarrolladores se ven influidas por las especulaciones que como desarrolladores hacemos, cuando los desarrolladores nos ponemos a pensar "ahhh ¿y si aquí meto esta funcionalidad X que seguro que va a ser necesaria en el futuro?", con lo que la estimación (que me reitero una estimación NO es un compromiso) ahora sí que está perdida, ya que además de hacer la funcionalidad planteada en un principio, vamos a hacer otra, que nadie nos ha pedido.

Esto es extremadamente peligroso a la hora de realizar un proyecto, ya que, lo primero, es que estamos modificando la planificación sin haber consultado previamente si es necesario, lo segundo, muy probablemente acabemos haciendo trabajo de más, que nuestro cliente no necesitaba y no va a apreciar, y que tercero, es posible que por esto, dejemos de hacer trabajo que nuestro cliente SI necesitaba, y esto es un gran problema.

Este tipo de especulaciones se tienen que evitar siempre, cualquier funcionalidad que detectemos durante nuestro trabajo como desarrollador (ahora estoy con la gorra de desarrollador puesta), siempre, siempre, se tiene que verifica con el jefe de producto/cliente, ya que él es el que tiene la visión del negocio de la aplicación que estamos desarrollando, lógicamente estamos asumiendo que tenemos un jefe de producto/cliente que está dispuesto a colaborar a la hora de la toma de decisiones en cuanto a funcionalidad se refiere, y esto es lo que hay que hacer entender a los clientes a la hora de la implicación en un proyecto, no es válida la posición de, voy, tomo los requisitos en dos horas, me vuelvo a mi sitio, y me estoy dos meses desarrollando lo que yo creo que es la visión de negocio. Siempre tenemos que apoyarnos en el jefe de producto/cliente a la hora de decidir que funcionalidad es necesaria y prioritaria y cual no.

Por supuesto, esto tiene mucho que ver con los principios del manifiesto ágil ("Customer collaboration over contract negotiation"), y para poder conseguir esto se tienen que dar algunos condicionantes como tener siempre cerca al responsable de la toma de decisiones sobre funcionalidad.

Planificar en iteraciones también es muy importante respecto a esto, lo primero es que nos van a ayudar a hacer mejores estimaciones, ya que siempre es más sencillo estimar un conjunto pequeño de funcionalidades y a corto plazo, y favorecerá el que surjan menos especulaciones durante ese plazo de tiempo ya que tenemos que decidir que es lo que se va a hacer, concretando todas las dudas al principio de la iteración.

Por supuesto, y como siempre digo, es importante rodearse de buenos desarrolladores, que eviten caer en la tentación de la especulación, y se centren en entregar buen software, y si no es posible que todos sean buenos desarrolladores y con experiencia (nadie nace sabiendo y hay que aprender en el camino), sí que es necesario que al menos haya uno que sea un poco el "cabeza" de grupo, y en el que se apoyen el resto de desarrolladores con menos experiencia o conocimientos.

Bueno, esto es un poco lo que me rondaba la cabeza y quería escribir, y que se resume en NO hacer especulaciones sobre lo que no estamos cualificados para hacer, y que corresponden a otras personas, y centrémonos en hacer software de calidad.