Planificar y estimar

Prácticas que no se deben descuidar

Algunos equipos se contentan con establecer la organización Ágil y los rituales de los que ya hemos hablado y se lanzan de cabeza al desarrollo, diciéndose que de todas maneras se irá adaptando a medida que avance, en función de lo que se produzca en los Sprints.

Olvidan que Scrum no significa anarquía. No porque el método se construya alrededor del empirismo y la adaptación hay que olvidar la planificación y la estimación.

Por lo tanto, este capítulo abordará todas las nociones necesarias para la implementación de prácticas de estimación y planificación eficaces.

Por qué la planificación tradicional falla

Como dijo Mark Twain (o Niels Bohr a menos que no sea Pierre Dac…):

"La predicción es un arte difícil, sobre todo en lo que respecta al futuro"

Más seriamente, lo que podemos constatar en primer lugar es que en los métodos clásicos se planifica por tipo de actividad (especificación, diseño, desarrollo, pruebas, etc.) y no por la funcionalidad. Sin embargo, lo que al final queremos es que las funcionalidades estén terminadas, lo que el enfoque clásico no garantiza en absoluto.

Otra razón es que tenemos tendencia a olvidar totalmente que la estimación va inevitablemente unida a un grado de incertidumbre. Todos hemos vivido proyectos en los que se nos pide encargarnos de manera precisa de contenidos de Releases y fechas de entrega, mientras que las funcionalidades esperadas todavía no se han analizado en el detalle y, evidentemente, los que dan las órdenes consideran que el plan inicial está grabado en piedra.

La siguiente gráfica (que se llama cono de incertidumbre) es el resultado de la observación de proyectos reales:

Se ve claramente que cuanto más precisa es la definición del sistema a realizar, menor es la incertidumbre de la estimación. De esta manera, en el estado del concepto inicial, tenemos un grado de incertidumbre del orden de 1 a 8 entre estimaciones mínimas...

Horizontes de planificación

Si se ha entendido Scrum correctamente, vemos que las capacidades de adaptación que ofrece solo son realmente eficaces si se inscriben en una visión global.

Para conseguir este objetivo, al menos nuestro proyecto Scrum deberá entender los siguientes horizontes de planificación:

La/las Release(s): a este nivel se da una visión macroscópica de lo que se espera entregar por los grupos del Sprints.
El Sprint: es la planificación bien conocida de los Sprints (a nivel de Story).
La jornada: es lo que se aborda durante el "Scrum Meeting" diario (lo que puede afectar a las tareas de cada uno).

Según el caso, podemos añadir niveles "estratégicos" encima de estos, pero en este estado es inútil complicarnos la vida, estos tres niveles de visión del plan son más que suficiente.

Herramientas de estimación

Si ya ha estado implicado en la gestión de proyectos en modo "tradicional", estará familiarizado con el uso del concepto días/hombre (d/H más adelante) o de sus derivadas (meses/hombre, horas/hombre, etc…), que sirven para sus estimaciones. Además, muy probablemente no se haya imaginado nunca utilizar otra unidad para estimar.

Pues bien, en el mundo Ágil va a ver que dispone de otras opciones muy interesantes.

1. T-Shirt sizing

Esta escala se usa habitualmente para proyectos en los que el nivel de definición de las funcionalidades/Stories está en un estado macroscópico, lo que impide un trabajo de estimación muy fino.

Simplemente se utiliza (lo que es muy intuitivo), la analogía de los tamaños de una camiseta: XS, S, M, L, XL, etc.

Aunque suene absurdo, una Story "XL" es muy grande y una Story "S" es pequeña, aunque solo se busca tener un factor de conversión entre "T-Shirt size" y d/H.

Nada le impide inventar su propio método en función de sus gustos y, sobre todo, en función de la eficacia sobre sus proyectos (habrá equipos que utilicen razas de perro para estimar el esfuerzo a producir: el chihuahua para las User Stories correspondientes a un esfuerzo bajo y el san Bernardo para aquellas que necesitan un esfuerzo importante).

Por otra parte, esto permite introducir la noción de estimación "relativa": concretamente se identifica las Stories "de referencia" que corresponden a los diferentes "tamaños" y el resto se cuantifican por analogía. Se estima que dos Stories de tamaño "M" necesitan un esfuerzo de desarrollo comparable.

2. Los story points

El story point es la unidad de estimación por excelencia de las Stories en los proyectos Scrum (pero aunque finalmente es bastante fácil de usar, a menudo se controla muy mal o se descuidan con facilidad). De esta manera, es importante entender correctamente cómo funciona esta noción.

Un Story point sirve para estimar el esfuerzo necesario que le llevará a un equipo para implementar una User Story, teniendo en cuenta:

el esfuerzo para el desarrollo (y las pruebas),
la complejidad del desarrollo (y las pruebas),
el riesgo/el desconocimiento.

Veamos cómo estos tres factores afectan a la estimación...

Planificación de Release

Los elementos metodológicos de los que acabamos de hablar se aplican evidentemente cuando hablamos de planificación a una escala "global" (proyecto o Release), y no simplemente para los Sprints. Aunque no sea estrictamente necesario, como va a ver esta práctica le puede permitir fijar muchos elementos estructurados del proyecto.

1. Tener un objetivo claro

Lo primero que es necesario para la planificación de una Release es definir un objetivo claro: ¿cuál será su objetivo?

Este objetivo es la línea directriz de la Release y guiará fundamentalmente la elección de las User Stories que hay que asignar a los diferentes Sprints que la componen.

2. Tener un Product Backlog priorizado

Dando por hecho que vamos a utilizar la noción del Sprint, los Sprints se deben alimentar por las User Stories. Es necesario disponer de un Product Backlog que tenga un tamaño suficiente para alimentar varios Sprints. Por supuesto, todas las User Stories no necesitan tener la misma granularidad. Aquellas que se encuentran en el primer Sprint deben ser más precisas que las que integran el cuarto o quinto Sprint. Por lo tanto, esto necesita una priorización del Product Backlog.

3. Estimar el Product Backlog

Para poder integrar las User Stories en los Sprints, es necesario que el equipo de desarrollo las estime. No volveremos sobre los métodos de estimación...

Conclusión

Aunque para algunos este capítulo pueda parecer un poco técnico, nos parece realmente importante poner el acento en la explicación de las buenas prácticas de planificación y estimación Scrum, porque su implementación es fundamental para tener éxito en sus proyectos.

Por otro lado, se pone claramente de manifiesto, contrariamente a ciertas ideas preconcebidas, que desarrollar según este método no significa controlar los proyectos "por encima" sin prever nada, sino al contrario, adaptar su plan (por lo que es necesario tener uno) a medida que evoluciona el proyecto o el Sprint.