Tecnicas de estimacion tradicional versus agil

Técnicas de estimación: tradicional versus ágil

A través de mi experiencia como Agile Coach en diversas organizaciones, he observado que cuando se produce una migración del enfoque tradicional hacia el agilismo, uno de los problemas más frecuentes es el cambio en la manera de estimar el esfuerzo de los proyectos.

 

Planificación inicial de un proyecto tradicional

Tradicionalmente, lo que hacemos es montar un plan antes de comenzar a trabajar. Recurrimos a un analista funcional para redactar una lista de requerimientos. Luego, desglosamos estos requisitos en tareas de alto nivel, y mediante juicio de expertos o estadísticas de proyectos anteriores del mismo tipo, obtenemos la cantidad de horas necesarias, y las discriminamos por perfil técnico. En un diagrama de Gantt apuntamos todas las actividades por ejecutar, sus fechas de inicio y de finalización. En muchos casos, añadimos un 20% extra por posibles contingencias. Decidimos el mejor momento para incorporar perfiles específicos, con la meta de minimizar costes. Sometemos esta estimación a aprobación y renegociamos. En este proceso, no participan las personas que van a construir el producto.

 Al avanzar la ejecución, suele ocurre lo siguiente

  • Aparecen tareas no previstas
  • Algunas personas abandonan el equipo
  • Algunas tareas nos llevan más tiempo que el planificado
  • El cliente nos pide cambios

 Técnicas tradicionales de estimación

Para entender mejor por qué no funciona este modelo, repasemos las técnicas tradicionales de estimación:

Juicio de expertos: un analista funcional estima todo el trabajo. Generalmente, es un profesional experimentado, y la previsión resulta optimista porque con su conocimiento le resultaría fácil ejecutar la tarea. También, debe estimar tareas que nunca ha realizado.

Análisis cerrado: creamos un documento muy técnico y extenso (muchas veces en UML), y obligamos al cliente a firmarlo. El inconveniente es el coste (en tiempo y dinero) que requiere redactarlo. No es flexible a cambios posteriores. En general, esta limitación no agrada a los clientes, pero en numerosas ocasiones funciona correctamente.

Base de datos de proyectos: extrapolamos información histórica para calcular un trabajo futuro. La idea es buena, pero los proyectos suelen ser muy diferentes y resulta difícil aplicar una métrica común.

Como consecuencia de esta forma de trabajar, suele ocurrir que

  • Los planes fallan
  • Las expectativas fallidas generan frustración, en el cliente y en el equipo
  • La frustración conduce a sobreesfuerzos, estrés, mal ambiente, renuncias y despidos

 

Las tres verdades de los proyectos

  • Es imposible recopilar todos los requerimientos antes de comenzar un proyecto
  • Cualquier requisito capturado cambiará
  • Siempre queremos hacer más de lo que el tiempo y dinero nos permiten

Nuestro objetivo no debe ser protegernos de los cambios y la incertidumbre, sino aprender a ejecutar proyectos en estas condiciones.

 

Metodologías ágiles

Una vez que hemos comprendido que por más tiempo y esfuerzo que dediquemos, no vamos a poder determinar todos los requisitos ¿tiene sentido realizar un análisis funcional completo antes de comenzar el desarrollo? La respuesta es no. Resulta inútil intentar predecir y controlar todo lo que ocurrirá con muchos meses de antelación. En cambio, podemos planificar sólo las primeras semanas y pronosticar una entrega temprana de un producto con unas funcionalidades elementales. Este es, el enfoque iterativo e incremental que propone Scrum.

Durante los sprints iniciales, resulta imposible establecer predicciones de fechas. A medida que avanzamos en el Cono de incertidumbre, y establecemos la velocidad del equipo, estaremos en mejores condiciones de conocimiento y experiencia para estimar plazos.

La aproximación que más reduce el riesgo es realizar entregas frecuentes, cada dos o tres semanas, de características completas. Estas deben ser priorizadas por valor de uso y de negocio. Desarrollamos primero aquello que mayor utilidad aporta a la organización y al usuario final. Recordemos que en los proyectos cuyo alcance está cerrado de antemano, el 45% de las funcionalidades no son usadas nunca por los usuarios, y el 19% solo alguna vez. Entonces, no invertimos recursos en elementos que luego nos aportarán poca o nula valía.

 En cada entrega inspeccionamos el producto, intentando validar o corregir la hipótesis. Planificamos las semanas siguientes e incorporaremos cambios en función del aprendizaje que hemos ido obteniendo, tanto en el aspecto técnico como de negocio. Esto nos ayuda a gestionar las expectativas y a evitar la frustración.

El enfoque tradicional de proyecto implica que existe un punto en el cual estará todo terminado. En agilismo esto no es así. Un producto nunca contiene todas las características posibles. Siempre podemos añadir mejoras o nuevas ideas y funcionalidades a lo largo de su ciclo de vida. 

 

 Técnicas ágiles de estimación

 Con este marco de trabajo ágil, necesitamos también determinar cuánta funcionalidad podemos incluir en cada iteración o sprint. El agilismo propone estimaciones grupales, basadas en métodos Delphi. Estas serán relativas y no absolutas. Valoramos el diversity score del equipo, evitaremos la influencia de unos miembros en otros, y por sobre todas las cosas, las entenderemos siempre como un pronóstico de mejor esfuerzo, y no como un contrato. 

 Dentro de las dinámicas habituales, podemos nombrar

  • Poker planning
  • Tallas de camiseta / T-Shirts
  • Animales
  • Muro de afinidad / Affinity grouping
  • Grande/Pequeña/Incierta / Big Small Uncertain
  • Cubo de estimación / Bucket system

 En próximos artículos hablaremos más en detalle sobre la ejecución de estas técnicas