Técnicas de estimación ágil

Resumen

La estimación del esfuerzo de trabajo en los proyectos ágiles es fundamentalmente diferente de los métodos tradicionales de estimación. El enfoque tradicional consiste en estimar utilizando una técnica «ascendente»: detallar todos los requisitos y estimar cada tarea para completar esos requisitos en horas/días, y luego utilizar estos datos para desarrollar el calendario del proyecto. Los proyectos ágiles, por el contrario, utilizan un enfoque «descendente», empleando técnicas de estimación de nivel grueso sobre conjuntos de características, y luego empleando métodos de elaboración progresiva y planificación por oleadas para profundizar en el nivel de las tareas sobre una base de tiempo justo, descubriendo iterativamente más y más detalles en cada nivel. En este artículo se explicarán dos técnicas habituales de estimación ágil (el póquer de planificación y la agrupación por afinidad), y se explicará cómo los resultados de estos ejercicios proporcionan información para la previsión del calendario y el presupuesto.

Top-down vs. Bottom-up

El método tradicional de estimación de proyectos consiste en dedicar varias semanas o meses al principio de un proyecto a definir los requisitos detallados del producto que se va a construir. Una vez que se han obtenido y documentado todos los requisitos conocidos, se puede elaborar un diagrama de Gantt que muestre todas las tareas necesarias para completar los requisitos, junto con la estimación de cada tarea. A continuación se pueden asignar recursos a las tareas, y acciones como la carga y la nivelación ayudan a determinar la fecha de entrega final y el presupuesto. Este proceso se conoce como método ascendente, ya que todos los detalles relativos al producto deben definirse antes de poder estimar el calendario y el coste del proyecto.

En la industria del software, el uso del método ascendente presenta graves inconvenientes debido a la velocidad de cambio actual. La velocidad del cambio significa que la velocidad de las nuevas herramientas de desarrollo y la velocidad de acceso a los nuevos conocimientos es tan grande que cualquier retraso en la entrega deja a uno abierto a las alternativas de la competencia y en peligro de entregar un producto obsoleto (Sliger, 2010).

El método descendente aborda esta cuestión clave, utilizando la información actualmente disponible para proporcionar estimaciones a nivel bruto. A continuación, se utiliza la planificación por oleadas para incorporar nueva información a medida que se va conociendo, perfeccionando las estimaciones y elaborando iterativamente más detalles a medida que avanza el proyecto. Este método de aprender lo suficiente para empezar, con un plan para incorporar más conocimientos a medida que los resultados del trabajo evolucionan, permite al equipo del proyecto reaccionar rápidamente a la adversidad y a los cambios en la demanda del mercado.

Técnicas de estimación

Las técnicas de estimación a nivel bruto son utilizadas por los equipos que utilizan enfoques ágiles como Scrum y Extreme Programming, y este documento cubrirá dos de las técnicas más populares: Planning Poker y Affinity Grouping. También se examinarán las unidades de estimación utilizadas, ya que estas unidades deben ser tales que no puedan confundirse con el tiempo.

Planificación del Póker

La técnica más popular de estimación a nivel bruto es la Planificación del Póker, o el uso de la secuencia de Fibonacci para asignar un valor en puntos a una característica o elemento (Grenning, 2002). La secuencia de Fibonacci es una serie matemática de números que se introdujo en el siglo XIII y se utilizó para explicar ciertos aspectos formativos de la naturaleza, como la ramificación de los árboles. La serie se genera sumando los dos números anteriores para obtener el siguiente valor de la secuencia: 0, 1, 1, 2, 3, 5, 8, 13, 21, etc. Por motivos de estimación ágil, se han cambiado algunos de los números, dando como resultado la siguiente serie: 1, 2, 3, 5, 8, 13, 20, 40, 100.

Estos números se representan en un conjunto de cartas de juego (ver Anexo 1). Los miembros del equipo juegan al «póquer de la planificación» (Anexo 2) para proporcionar una estimación en forma de valor en puntos para cada elemento. Estos son los pasos:

• Cada miembro del equipo recibe un juego de cartas.
• El propietario de la empresa (al que NO le toca estimar) presenta el elemento a estimar.
• Se discute el elemento.
• Cada miembro del equipo selecciona en privado una carta que representa su estimación.
• Cuando todos están listos, se revelan todas las tarjetas seleccionadas al mismo tiempo.
• Si todos los miembros del equipo seleccionaron la misma tarjeta, entonces ese valor en puntos es la estimación.
• Si las tarjetas no son iguales, el equipo discute la estimación haciendo hincapié en los valores que quedan fuera:
  • El miembro que seleccionó el valor más bajo explica por qué seleccionó el valor.
  • El miembro que seleccionó el valor más alto explica por qué seleccionó el valor.
• Seleccione de nuevo hasta que las estimaciones converjan.
• En caso de que se produzcan conversaciones prolongadas o «en la maleza», los miembros del equipo pueden utilizar un cronómetro de dos minutos para limitar el tiempo de la discusión, seleccionando de nuevo cada vez que se agote el cronómetro, hasta que se produzca la conversión.
• Repítalo para cada elemento (Cohn, 2006, pp. 56-57).

Hay varias razones por las que se usan los números de Fibonacci, y se usan en este formato. La primera es la idea de que una vez que los equipos eliminan el tiempo como base de la estimación, es menos probable que exijan más detalles y rellenen las estimaciones. Estos números representan el tamaño relativo, no el tiempo. En consecuencia, el ejercicio de estimación es bastante rápido. Los equipos suelen dedicar unos dos minutos a cada elemento, lo que permite estimar una cartera de 30 elementos en una hora. El hecho de que los equipos estén limitados a sólo 9 opciones (es decir, valores de puntos o tarjetas) también ayuda a acelerar el proceso.

La secuencia también proporciona el nivel de detalle adecuado para las características más pequeñas y mejor comprendidas, al tiempo que evita una falsa sensación de precisión para las estimaciones más altas. Por ejemplo, un elemento con una estimación alta (20 o más) significa que el elemento es grande y aún no se entiende bien. Debatir si el artículo es un 20, un 19 o un 22 sería una pérdida de tiempo, ya que simplemente no hay suficientes datos disponibles. Una vez que el elemento se acerca a la iteración en la que se trabajará, puede dividirse en partes más pequeñas y estimarse en números más granulares (1-13). Los elementos con estimaciones de puntos de 1 a 13 generalmente pueden completarse en una sola iteración (de 1 a 4 semanas).

Es importante tener en cuenta que los puntos no tienen el mismo significado en todos los equipos; por ejemplo, el «cinco» de un equipo no es igual al «cinco» de otro. Por lo tanto, la velocidad del equipo, que se deriva de los puntos, no debe utilizarse para comparar la productividad entre equipos.

Agrupación por afinidad

Una forma aún más rápida de estimar, y que se utiliza cuando el número de elementos a estimar es grande, es la agrupación por afinidad. Los miembros del equipo simplemente agrupan los elementos que tienen un tamaño similar, lo que da como resultado una configuración similar a la de la ilustración 3. El método es sencillo y rápido:

• Se lee el primer elemento a los miembros del equipo y se coloca en la pared.
• Se lee el segundo elemento y se pregunta al equipo si es más pequeño o más grande que el primero; la colocación en la pared corresponde a la respuesta del equipo (más grande es a la derecha, más pequeño es a la izquierda).
• Se lee el tercer elemento y se pregunta al equipo si es más pequeño o más grande que el primero y/o el segundo; la colocación en la pared corresponde a la respuesta del equipo (más grande es la derecha, más pequeño es la izquierda). Sin embargo, una forma más rápida es hacer que cada miembro del equipo seleccione un elemento y lo coloque basándose en su propia comprensión. Esto se hace con todos los miembros del equipo trabajando en paralelo hasta que todos los elementos hayan sido evaluados y colocados en la pared. Se pueden estimar varios cientos de elementos en un tiempo relativamente corto. Una vez colocados todos los elementos en el muro, el equipo revisa las agrupaciones. Los elementos que un miembro del equipo cree que están en el grupo equivocado se discuten y se cambian de lugar si es necesario.

  Una vez que se ha completado la agrupación por afinidad, se pueden asignar los valores de las unidades de estimación, como los puntos. En la ilustración 3, el primer conjunto del extremo izquierdo se etiquetaría con un valor de 1 punto, el segundo conjunto sería de 2 puntos, el tercer conjunto de 3 puntos, el cuarto conjunto de 5 puntos y el último conjunto de 8 puntos.

  La agrupación por afinidad también puede realizarse para otras unidades de estimación, como las tallas de las camisetas. La ilustración 4 muestra un ejemplo de elementos agrupados por afinidad etiquetados con tallas de camisetas en lugar de puntos.

  

  Exhibición 3. Ejemplo de agrupación por afinidad

  

  Exhibición 4. Agrupación por afinidad utilizando las tallas de las camisetas (Gráfico cortesía de Chris Sterling. Todos los derechos reservados.)

  Unidades de estimación

  El uso de las tallas de las camisetas (Extra Small , Small , Medium , Large , Extra Large ) es otra forma de pensar en los tamaños relativos de las características. Se trata de una desviación aún mayor del sistema numérico y, como todas las unidades de estimación de buen nivel bruto, no puede asociarse en modo alguno a una duración específica.

  Otras fichas arbitrarias de medida son los ositos de goma, las NUTS (Unidades Nebulosas de Tiempo) y los pies-libra. Los equipos pueden crear sus propias unidades de estimación y, como puede verse, a menudo se divierten haciéndolo.

  Este documento no cubre el uso de unidades basadas en el tiempo, como los días y/o las horas ideales de desarrollo. Éstas ya son comunes y se entienden bien, por lo que no se han incluido sus explicaciones. Sin embargo, vale la pena señalar que la estimación a nivel bruto tiene el potencial de ser más exitosa cuando se desvincula de la noción de tiempo. Dado que las estimaciones de tiempo suelen convertirse en compromisos por parte de la dirección y la empresa, los miembros del equipo se sienten más presionados para ser lo más precisos posible. En consecuencia, piden cada vez más detalles sobre el elemento que se está estimando. Esto convierte la estimación a nivel bruto en una estimación a nivel de detalle que consume más tiempo y anula la intención y el propósito originales.

  Previsión del calendario y el presupuesto

  Una vez que se determinan las estimaciones a nivel bruto y la velocidad del equipo, se pueden prever el calendario y el presupuesto. Los equipos determinan su velocidad sumando el número total de puntos de todos los elementos que han completado en una iteración. Por ejemplo, un equipo puede haber seleccionado cinco elementos con un valor total de 23 puntos (véase la ilustración 5). Al final de su iteración de dos semanas, sólo pudieron completar cuatro de los cinco elementos. Su velocidad es de 15, es decir, la suma de los valores de los puntos del 1 al 4. Los equipos no obtienen «créditos parciales» por completar partes de un ítem, por lo que aunque hubieran empezado el ítem 5, no contaría, ya que no fue completado.

  

  Exhibición 5. Determinación de la velocidad del equipo

  Determinación del cronograma

  La velocidad media de un equipo se utiliza en la previsión de un cronograma a largo plazo. La velocidad media se calcula sumando las mediciones de velocidad de las tres últimas iteraciones del equipo y dividiendo ese total por tres. Así, si un equipo completó 15 puntos en su primera iteración, y 20 puntos en cada una de las dos iteraciones siguientes, la velocidad media del equipo es 18 (15+20+20 / 3). Si un equipo puede hacer 18 puntos en una iteración de media, y hay 144 puntos de trabajo por completar en el proyecto, el equipo tardará ocho iteraciones en completar el trabajo (144 / 18). Si cada iteración dura dos semanas, la previsión de finalización es de 16 semanas. Este método nos permite responder a la pregunta: «¿Cuándo terminaremos todo este trabajo?»

  Si el equipo tiene un historial de datos de velocidad, es posible determinar la fecha de finalización más optimista, la más pesimista y la más probable. El número de velocidad media del equipo se utiliza para calcular el escenario más probable, mientras que los números de velocidad de las iteraciones de peor rendimiento del equipo se utilizan para calcular la fecha de finalización prevista más pesimista. El uso de la velocidad de las iteraciones en las que el equipo fue capaz de completar más de lo esperado proporciona la previsión más optimista.

  También podemos utilizar estos números para responder a la pregunta: «Debemos entregar algo para esta fecha, de estas características, ¿cuántas habremos hecho para entonces?» Véase en la ilustración 6 un ejemplo de la previsión de la cantidad más probable a completar, la previsión pesimista y la previsión optimista. Este ejemplo es para un equipo cuya velocidad media es de 20, y que tiene una velocidad de peor rendimiento de 12 y una velocidad de mejor rendimiento de 25. Teniendo en cuenta esto y sólo seis semanas (tres iteraciones), ¿cuánto se puede completar? La previsión pesimista es que sólo los puntos 1 a 8 se harán en seis semanas. La previsión optimista es que se completarán los puntos 1-18. Y la previsión más probable, basada en la velocidad media del equipo de 20, es que los elementos 1-13 se completarán en seis semanas.

  Si los equipos utilizaran unidades de estimación no numéricas, como las tallas de las camisetas, los algoritmos de previsión serán más complejos. Se recomienda convertir las tallas a un sistema numérico para generar más fácilmente datos similares. Por ejemplo, una Pequeña podría convertirse a una NUT de 3, una Mediana a una NUT de 5, y así sucesivamente. También se pueden convertir a rangos de tiempo (un Pequeño podría ser de 1 a 3 días, por ejemplo) pero esto es inherentemente arriesgado, debido a los problemas ya citados en la sección de Unidades de Estimación.

  

  Exhibición 6. Ejemplo de previsión para la finalización de partidas

  Determinación del presupuesto

  En este apartado se trata de responder: «Sólo tenemos esta cantidad de dinero: ¿cuánto durará y cuánto habremos hecho antes de que se nos acabe?» En primer lugar, se utiliza una fórmula sencilla para determinar el coste por punto:

  Σ (salarios cargados del equipo para el periodo n) / puntos completados en el periodo n

  Toma la suma de los salarios del equipo (cargados) para un periodo de tiempo, digamos tres iteraciones de dos semanas, y divídela por el número de puntos que el equipo completó en el mismo periodo de tiempo. Así, un equipo cuyos salarios cargados totales son de 240.000 dólares durante seis semanas, y que completó 60 puntos de trabajo en esas tres iteraciones, tendría un coste por punto de 4.000 dólares. Ahora utilice la siguiente fórmula para determinar el presupuesto:

  (Coste por punto x valor total de puntos a completar) + otros gastos = presupuesto previsto

  Muy a menudo no se definen todas las características de un producto al inicio de un proyecto, lo cual es lo esperado para los proyectos ágiles. Así que las estimaciones presupuestarias se basan en lo que sabemos hoy, más un algoritmo de previsión que se basa en datos históricos o en la orientación de expertos. Por ejemplo, digamos que hasta ahora sólo hay 20 características, pero la empresa no podrá aportar ninguna solicitud de características adicionales o perfeccionamientos hasta después de ver cómo recibe el cliente la primera versión. El presupuesto del proyecto, que está previsto para tres versiones, sólo dispondrá de datos de previsión para la primera versión y no para todo el proyecto. El equipo podría utilizar el algoritmo anterior para pronosticar el presupuesto para la primera versión, y luego asumir un 20% adicional para la segunda versión y un 5% adicional para la última versión, basándose en la experiencia pasada.

  Al igual que la velocidad, las previsiones de presupuesto y las previsiones de calendario se revisan en cada iteración. Esto forma parte del proceso de planificación por oleadas al que se adhieren los proyectos ágiles.

  Palabras finales

  En particular, no se ha tratado en este documento la falta de técnicas de estimación estructuradas que se utilizan en los enfoques lean, como Kanban. En lugar de gastar (perder) tiempo estimando elementos, el ciclo medio y los tiempos de entrega se calculan basándose en las tasas de rendimiento reales del equipo. Kanban utiliza el teorema matemático de la Ley de Little como base para sus fórmulas. Utilizando los cálculos de los plazos de entrega derivados de los diagramas de flujo acumulativo, los equipos prevén los calendarios de los proyectos sin tener que dedicar tiempo a la preparación de las estimaciones. Se anima al lector a realizar una investigación independiente sobre este tema, que podría constituir un artículo aparte por sí mismo.

  Los proyectos ágiles pretenden entregar un producto o incrementos de producto pronto y con frecuencia, con el fin de incorporar los comentarios de los clientes y otros aprendizajes en la siguiente versión. Al dedicar más tiempo a la experimentación, la ejecución y el aprendizaje, y menos a la especulación, se reduce el tiempo del ciclo de entrega. Los equipos ágiles son más capaces de competir en el mercado y seguir el ritmo de la creciente velocidad del cambio.