La estimación, ese diablo que se cuela en las vidas de cualquier equipo de software. Las estimaciones dan pesadillas a los desarrolladores porque entienden que si dan una fecha están asumiendo un compromiso.
¿Qué problema tienen las estimaciones? Las estimaciones en sí, no tienen ningún problema, el dar una fecha aproximada no es un problema siempre que gestiones bien la expectativa con la persona que recibe la información. En el mundo determinista, donde la incertidumbre es muy baja, las estimaciones ayudan muchísimo ya que tienen un % de fiabilidad muy elevado y nos ayuda a planificar.
Estimar en un mundo complejo
Sin embargo, el mundo del software es complejo como vimos en este artículo. El ser complejo hace que haya demasiadas variables que no controlemos (ni siquiera conozcamos) a la hora de estimar por lo que nuestra estimación es muy poco fiable. Además, cuanto más lejos pensemos en estimar menos fiable será nuestra estimación. Esto nos lo explica muy bien el cono de incertidumbre
¿Eso significa que no podemos estimar nunca? No es cierto, en el mundo de Scrum por ejemplo si que estimamos ¡Y muchas veces!. Solo que en vez de tratar de estimarlo todo al principio, estimamos cada vez que empieza un Sprint y con un horizonte temporal de unas pocas semanas. Si queremos saber el futuro de nuestro producto a más distancia temporal entonces lo que hacemos es esperar a tener evidencias. Esto significa, que cuando ya tenemos experiencia podemos empezar a hablar de mayor distancia, nuestro cono se reduce y podemos pensar a largo plazo ya que ganamos en fiabilidad.
¿Las estimaciones son erróneas?
Hay una frase que oigo en muchos equipos software que es la siguiente “nos equivocamos con la estimación”. Esta frase me parece incorrecta. Nadie se equivoca con la estimación porque precisamente es eso ¡Una estimación!. Estimar es por definición predecir el futuro y por tanto es equivocarnos. Las estimaciones se hacen en base a la información que tenemos en ese momento y por tanto es normal que a medida que afrontamos la realidad veamos que nuestra estimación no era correcta. ¡Pero no hay que frustrarse!
Otra de los grandes problemas de las estimaciones es cuando se ven influenciadas por el negocio. Frases como “esto tiene que estar antes de navidad, ahora haz una estimación” acaban matando al software. Si tiene que estar en navidad no merece la pena estimar, lo que podemos hacer es trabajar cuanto antes para tener la mayor cantidad de software que aporte valor para esa fecha pero estimar no tiene sentido.
Lecciones Aprendidas
Muchas veces tenemos problemas al construir un producto, aún así, adquirimos experiencia y nos decimos a nosotros mismos “la próxima vez que me enfrente a esta situación voy a usar estimaciones más grandes para evitar problemas”. En principio esta es la cultura del PMP, donde las lecciones aprendidas en un proyecto sirven para proyectos futuros. El problema es que, si eres realista y transmites una estimación muy elevada, puede ocurrir que tu cliente rechace tu proyecto en favor de otro proveedor. A veces tomamos la decisión de reducir la estimación para luego “arregarlo con management”. Esto suele ser un dolor de cabeza para tod@s ya que acabamos por entrar en discusiones sobre quién hizo aquel web service fuera de tiempo o quien no validó esa pantalla que no ayudan a poner el foco en lo importante ¡generar valor!
¿Qué alternativa tenemos para las estimaciones?
Con el tiempo he aprendido que no hay una técnica correcta para estimar. Tradicionalmente se ha dado un enfoque de Estimation Based Management. Es decir, hacemos gestión de software en base a estimaciones; en un mundo donde las estimaciones no son fiables esto es un suicidio. El enfoque debería ser Evidence Based Management, esto es, gestión basada en la evidencia, en la experiencia. El EBM está basado en el método científico y básicamente es empezar cuanto antes, aprender, y mejorar constantemente.
Scrum nació con este pensamiento empírico y por eso funciona cuando las estimaciones no gobiernan el día a día. A los equipos no les recomiendo que no estimen, pero que tampoco se vuelvan locos estimando. Una cosa que he comprobado es que a muchos Development Teams les preguntas ¿En qué consiste una Sprint Planning? y te responden “estimar”. Cuando la respuesta debería ser “Planificar”.
En Scrum se utiliza la velocidad como dato para predecir el futuro del equipo. Esta velocidad debe estar basada en los datos reales que el equipo ha tenido hasta la fecha y no en estimaciones por eso la predictibilidad de los equipos aumenta a medida que tenemos más información.
Podéis encontrar más información de Evidence Based Management en este paper que publicaron desde Scrum.org. En futuros post hablaremos de ello ya que el software exitoso es aquel donde sus pilares son la experiencia y no pájaros en el aire hechos con estimaciones.
Y tú ¿Cómo gestionas tus equipos software?
