¿Buscando precisión en las estimaciones?

Estimación ágil, estimaciones

 

Uno de los principales temas que preocupa y ocupa a muchos equipos de desarrollo de software es ser más precisos en la estimación de las tareas que habrá que ejecutar en cada iteración de trabajo.

 

La estimación es vital para una buena planificación, y ésta es necesaria, más allá de lo mucho o poco que nos guste dicha actividad. Los inversionistas de un proyecto requieren algún marco de planificación para considerar los riesgos, al menos a gran escala. Es usual escuchar discusiones (inclusive polémicas) respecto si es necesario planificar o no. Mi opinión personal es que resulta un esfuerzo estéril discutir si hay que hacerlo o no. ¿Acaso es necesario explicar y discutir acerca de la necesidad de tener cobrar o no por el trabajo que se realiza? Podemos hablar acerca de las formas de retribución y cuáles son los medios para percibirla, pero no de la necesidad de hacerlo.

Durante mis más de veinte años desarrollando proyectos de software he invertido tiempo en comprender qué incide en la planificación, y empíricamente he aprendido que el método que se utilice para estimar es valioso pero secundario. En la Universidad nos enseñaron a estimar en base a COCOMO pero hoy día existen otras técnicas diferentes, por suerte. Las metodologías Ágiles han intentado cambiar el paradigma y poner la discusión en otro lado, mirando desde otro ángulo este tema. Tal es así que hay varios colegas que promueven “¡No estimarás!”.

Existen varios métodos para hacerlo, pero aprender un método u otro es como aplicar una receta de cocina, y cuando se utiliza varias veces se mecaniza, y luego de un tiempo nos sentimos que necesitamos saber algo más para seguir progresando y mejorar.

Espero que la expectativa del lector no sea que le hable de Wideband o Planning Poker, de ser así tal vez se sientan defraudados si siguen leyendo. Como mencioné algunas oraciones antes, tener un método de estimación es relativamente importante, pero lo más importante es comprender los factores psicológicos que inciden en los seres humanos cuando tenemos que “estimar”, “predecir”, “adivinar el futuro”, “comprometernos” o cualquier otro sinónimo que se use para darle nombre a este asunto.

Es frecuente encontrar en una misma empresa equipos que estiman “muy bien” y otros que estiman “no tan bien”. ¿Pero en qué se basa alguien para hacer semejante valoración? Generalmente se hace un juzgamiento en función de la percepción de la satisfacción de expectativas.

Voy a citar algunas frases al azar para reflexionar en función de ellas:

“Este equipo anda como un relojito suizo, lo que estiman lo cumplen siempre”

“Ya van varios sprints que el equipo no cumple lo planificado”

“Hace demasiado tiempo que la velocidad del equipo no cambia, pero cumplen siempre con lo planificado”

“No cumplen con lo planificado, pero han mejorado la velocidad”

“Siempre cumplen con lo planificado pero siento que son conservadores”

“Aunque no cumplen con lo planificado siento que el resultado de cada sprint me agrega valor de producto”

“Este equipo es muy predecible, pero no puedo tomar su velocidad para hacer pre-venta”

“No importa qué tan predecible sean, me ayudan en conocer el riesgo que asumo en cada nuevo proyecto”


¿Cuáles de las siguientes frases son aplicables al equipo que estima “muy bien” y cuáles son las del otro equipo que no lo hace “tan bien”?

Si aprendemos a observar el comportamiento de quienes estiman tal vez podamos ayudarlos a que dicho comportamiento cambie. Para ello me basaré en algunas teorías y conceptos:

La teoría llamada “Planning fallacy” de  Daniel Kahneman y Amos Tversky brinda información útil a este propósito. Basados en un estudio científico han demostrado que hay dos grandes tendencias en quienes estiman:

  1. Subestimar tiempos, costos y riesgos.
  2. Sobreestimar los beneficios de algunas acciones.

Si estas afirmaciones les parece que ocurren en los proyectos de software, estos dos profesionales lo han demostrado de forma general.

Ambas tendencias se refuerzan con otras teorías también conocidas, como ser la “Parkinson’s Law” también llamada “Ley de la trivialidad” que dice lo siguiente:

  1. “El trabajo se expande hasta llenar el tiempo que se dispone para hacerlo”.
  2. “Los gastos aumentan hasta cubrir todos los ingresos”.
  3. “El tiempo destinado a cualquier actividad es inversamente proporcional a su importancia”.

Y esto aparentemente ocurre en el resto del mundo, no solamente en nuestro país.

Cuando consideramos trabajo en equipo, debemos entender el “Pygmalion effect”. Básicamente describe como la creencia que tiene una persona influye sobre otra, en términos prácticos se puede estar en presencia de profecía auto-cumplida; “Te dije que era una tarea que nunca se había hecho y no podíamos puntuarla porque se necesitaba investigar antes y la investigación no se puede calcular, por eso no llegamos al fin de sprint.”

Si a las anteriores le sumamos “Zeigarnik effect” la cual describe que tendemos a recordar las tareas interrumpidas o incumplidas y a olvidar aquellas que fueron completadas y exitosas podemos decir que tenemos un cocktail perfecto para no hacer buenas estimaciones; “Ah, sí, sí, lo hicimos hace algunos sprints atrás, estuvo buenísimo. Pero no recuerdo exactamente cómo lo hice, pero salió al toque”.

Después de varias decenas de proyectos, con diferentes equipos y clientes entendí que el resultado que logran los equipos cuando estiman “bien” es construir confianza. La confianza es el timón del riesgo para las partes involucradas.

Mi conclusión personal es que no se llegará a “estimar mejor” buscando ajustar el mejor método de estimación o de planificación, se llegará a estimar adecuadamente cuando cambie la conducta y el comportamiento de los involucrados en la estimación.

Este comportamiento tiene que ser genuino, congruente con los valores de trabajo y los principios en los que se fundan las metodologías que propiciamos, por eso puede ser útil prestarle mucha atención a los siguientes síntomas que son los enemigos de una “buena estimación”:

  • Expresiones que tienden a comparar un equipo con otro para generar una competencia de cumplimiento.
  • Sentir que hay subestimación de la importancia de los diferentes actores.
  • Sentir que la planificación es tomada como un “contrato amenazante”.
  • Menosprecio de la tarea técnica.
  • Actores no técnicos que opinan sobre cómo hacer las cosas.
  • Se le resta importancia al impacto que producen las interrupciones dentro del sprint.
  • Hay integrantes que no se animan a explicar el porqué de sus estimaciones.
  • Hay integrantes con posiciones muy dominantes.
  • Hay más preocupación por cumplir el plan que por el resultado del producto que se está desarrollando.
  • El cliente está cansado que el equipo le rechace cada cosa nueva que pide.
  • El equipo no se preocupa por la calidad del producto.
  • Hay rezongo, excusas y pretextos en lugar de feedback constructivo.

Si trabajas con equipos que utilizan metodologías ágiles debes aprender a “escuchar” la armonía del equipo (cliente + desarrolladores), y entender que un equipo sin armonía es como una orquesta que desafina, no importa que tan afinado tenga cada uno su instrumento, si están fuera de ritmo y tempo.