El « story point » se ha vuelto « main stream » con todas las derivas que ello conlleva. Veamos juntos cómo darle una patada al hormiguero, sin que por ello nos expulsen de las sesiones de planificación y estimación.

Volvamos a los tiempos de las estimaciones pre-agile

Día / mes Hombre

En el mundo de la gestión de proyectos informáticos, está el clásico « día-hombre ». Esa unidad de medida mágica que permite juzgar el rendimiento de un equipo, y sobre todo de sus miembros, ¡individualmente! ¡Qué comodidad! Basta con rellenar diligentemente tu queridísima hoja de Excel, o cualquier otra herramienta de gestión de proyectos, para ver cómo se actualizan tus gráficos y, si hace falta, la alerta sobre el « retraso » del equipo/miembro.

El seguimiento presupuestario y de planificación no es un mal, muy al contrario si queremos evitarnos malas sorpresas. Pero su finalidad se ha pervertido para convertirlo en una herramienta de micro-management y de reproche.

El corolario de este « día-hombre » es el « mes-hombre », unidad utilizada en macro-gestión para evaluar la carga de trabajo global de un proyecto. Con una fecha de fin de proyecto decidida de antemano, una simple división permite dimensionar el tamaño del equipo a reclutar para cumplir los plazos ... en teoría. Ahí es donde el famosísimo libro The Mythical Man-Month nos explica a lo largo, a lo ancho y en profundidad que esta práctica no es realista. La ley de Brooks proviene de este libro, y dice en esencia :

• « Añadir personas a un proyecto retrasado aumenta su retraso »

Las metáforas para explicar, aún mejor, esta ley empírica suelen ser las siguientes :

• « Nueve mujeres no hacen un niño en un mes. »
• « Estando 300 personas en una cocina para hacer un huevo frito, no será posible servir el plato 300 veces más rápido. »

Confusión entre carga y plazo

• Carga : Tiempo necesario para la realización efectiva
• Plazo : Tiempo necesario antes de tener la capacidad de hacer

Estimar en día-hombre favorece enormemente el error que consiste en pensar que la carga y el plazo van a ser idénticos.

(Jefe)-¿Cuánto tiempo para esta tarea?
(Ejecutante)-Eh... ¿2 días?
(J) -¡No, es demasiado! ¡Te doy 1! ¡Hasta mañana!
(E) -Pero ... ( J sale sin esperar la respuesta) ¿y las otras 5 tareas que tengo en curso, qué hago con ellas?

Cualquier parecido con acontecimientos reales no sería más que puramente voluntario.

Esta confusión es una ventaja si se desea mantener una ambigüedad artística en torno al vínculo entre la carga de trabajo y su entrega. Se mezclan 2 incertidumbres que no hacen más que multiplicarse, lo que incita a insertar un margen de error lo bastante enorme para paliar cualquier imprevisto.

ETP

El «ETP» (equivalente a tiempo completo) , es otra unidad de medida, sobre todo en boga en el medio de los jefes o directores de proyecto. Es muy práctica, porque permite evaluar rápidamente el coste global de un proyecto, así como su dimensionamiento.

Es motivo de orgullo tener «muchos ETP» bajo tus órdenes (cualquier parecido con el juego « a ver quién la tiene más grande » no sería más que fortuito). El ETP también puede servir para fijar objetivos a los colaboradores. Por ejemplo, un jefe de proyecto, según su grado, debe tener entre X e Y ETP bajo su mando ; un director de proyecto entre A y B, de lo contrario este colaborador no es « rentable ».

Esta unidad tiene además otra ventaja muy interesante para esta población. Permite ocultar el reparto fragmentado del tiempo dedicado al proyecto distribuido entre distintas personas : 1 arqui al 10% + 2 dev al 60% + 2 becarios (100%) + 1 aprendiz (50%) = 3,8 ETP ! Te dejo adivinar el estado del proyecto tras 6 meses de ciclo en V.

En resumen

Todo esto permite :

• separar el grano de la paja, el buen ejecutante del malo, el buen desarrollador del malo,
• montar « dream team », esos equipos vendidos a precio de oro cuyos miembros han demostrado en sus proyectos anteriores rendimientos muy superiores a los de sus congéneres,
• poner en valor a los mejores gestores con sus gráficos más bonitos, sus hojas de cálculo más complejas para detectar la más mínima variación de productividad de cada uno de los ejecutantes afectados.

La revolución del (story) point

Con los nuevos métodos de proyecto, apareció la estimación en «story point».

(Responsable) ¡Qué horror! ¡Se suprime la herramienta principal de medida de la productividad!
(Ejecutante) ¡Qué comodidad! ¡Se elimina la presión de la mala estimación que hay que cumplir!

Con la óptica de responsabilizar a los equipos y aligerar el micro-management, el story point fue adoptado con bastante rapidez en todas las organizaciones que querían hacer agile. Al final, la transición no era tan difícil. Solo se sustituye la unidad, de « dh » en « punto », y colmo de la felicidad, se puede tener una correspondencia de 1 a 1 (o cualquier otra proporción fácil de convertir) .

Las ventajas de esta nueva unidad de medida eran claramente romper todo vínculo entre la estimación realizada y una posible fecha de entrega.

El punto también permite valorar más fácilmente la complejidad de la realización. Pasar 2 días en una realización no significa en absoluto que la cantidad de código producido sea la misma que para la realización anterior, del mismo tamaño. Pero anunciar 2 puntos hace la confusión carga /plazo mucho más difícil, incluso imposible.

El factor de focalización

Esta noción la presenta, entre otros, el famosísimo Scrum and XP from the Trenches. En esencia, el autor explica que el punto debe representar un « día-hombre ideal », es decir, ¡una jornada de trabajo sin descanso ni interrupción! Para luego hacer la comparación rápida con la velocidad real del equipo y obtener un % de focalización. Se deduce muy lógicamente que cuanto más alto es este %, más se encuentra el equipo en condiciones ideales de trabajo. Por tanto, una gran parte de los esfuerzos de mejora del equipo (en sentido amplio) se orienta a menudo hacia la mejora de esta cifra.

¿Veis venir las posibles derivas?

Actualmente, esta noción ya casi no se usa y ello gracias al trabajo de los coachs que machacan que la correspondencia « punto <=> día » es una mala práctica ... con razón.

Salir de tu zona de confort

Ahora que el punto está dominado, es común, está pervertido, quizá sea hora de pasar a otra cosa. Pero no vayamos demasiado rápido ni demasiado lejos, no convendría que los frágiles avances y el impulso de mejora iniciado con los puntos se redujeran a la nada por un rechazo de la dirección/del departamento de TI/del manager que se sentiría aún más perdido.

La unidad personalizada

Llegamos al punto central de este artículo del blog.

La idea es efectuar un simple cambio semántico, abandonamos el término « punto » por… (redoble de tambor) … ¡lo que tú quieras!

¡Sí, personaliza el término! ¡Apodérate de él! ¡Juega con él! ¡Haz malabares con él!

Concretamente, un proyecto cuyo objeto principal es el seguro de hogar podría tomar el término « ladrillo ». El que gestiona la fabricación de coches puede muy lógicamente tomar « coche ». Así, ya no hablas en una unidad abstracta, lejos de todo, sino con un término más cercano al negocio, portador de sentido. Sabiendo que muy a menudo los proyectos llevan nombres no necesariamente evocadores, es un elemento que permitirá situar mejor el contexto del proyecto.

¿Por qué este (simple) cambio semántico?

Quizá me repliques que este cambio ínfimo no tendrá influencia, que es « solo » semántica. Quizá tengas razón en algunos casos, pero para los demás, puede cambiarlo todo. Es lo que se llama un « nudge », un « empujoncito ». Los objetivos detrás de esta idea son múltiples :

• Lúdico : El hecho de elegir su unidad al inicio del proyecto participa en la construcción del equipo y en su cohesión.
• Romper los códigos : Hay que salir regularmente de la zona de confort para explorar nuevas vías que, a la larga, pueden aportar mucho al equipo/proyecto/empresa.
• Evitar las comparaciones : Tener el punto como unidad de medida en todos los proyectos incita, voluntariamente o no, a hacer comparaciones entre equipos, a buscar correlaciones. Cuando es imposible comparar coles y zanahorias, ladrillos y patinetes.

¿Un paso más?

Pero no nos detengamos en tan buen camino. ¿No podríamos prescindir de los puntos y quedarnos solo con la unidad? ¿Por qué limitarse a un solo término? ¿Por qué no hacerse una escala de valores completa? Si retomo los ejemplos anteriores, podríamos obtener algo así :

La equivalencia en punto está ahí únicamente para darnos una idea, pero nuestra nueva escala de punto puede muy bien estar completamente desvinculada de ella. ¡Tengo una ilustración perfecta que demuestra que esta etapa está al alcance de todos! Una consultora bien conocida ha editado un juego de cartas para el poker planning que se parece a esto : En él encontramos una escala de valores, correspondiente ciertamente a los clásicos puntos, pero la idea está ahí.

Inconvenientes

Evidentemente, esta solución no es perfecta, tiene algunos defectos, pero no me parecen insalvables.

• Desestabilización : ¡Otro nuevo método de evaluación! Si ya los puntos no han sido fáciles de adoptar y utilizar correctamente, aquí incluso los desarrolladores van a tener dificultades para acostumbrarse.

No sería tan categórico. Ciertamente, hará falta acompañamiento, pero a la larga debería volverse natural. Para asegurar la transición y la integración de nuevas personas, respaldarse en una descripción rápida de lo que representa cada unidad ayuda enormemente. Para todo lo que concierne a la problemática de seguimiento y previsión, no está tan alejado de lo que se hacía con los puntos, usar la meteo de la víspera debería permitir hacer proyecciones razonables, quizá no a muy largo plazo, pero suficiente en lo que concierne a los métodos ágiles.

• Tanteo : ¿Cómo se hace en la práctica? ¿En qué nos basamos? ¿Qué taller debemos hacer?

Pregunta a tu Scrum Master o a tu coach, cada receta debe ser única. No es una práctica necesariamente fácil ni para poner en todas las manos, pero si llegas a este nivel, sabrás qué hacer.

• Herramientas de seguimiento : ¡Y mi herramienta de gestión de proyectos! ¿Cómo hace para generarme mis gráficos? ¡Mi burndown! ¡Mi burnup!

Es en efecto un problema más complicado. Es necesario adaptar las herramientas para que puedan explotar este tipo de escala no numérica evitando, precisamente, hacer aparecer claramente una conversión a numérico. Actualmente solo conozco una única solución que lo permitiría. ¡La gestión visual! Toma papel y lápiz y hazlo tú mismo. Pero estoy de acuerdo, no es fácil para equipos a distancia.

Para ir aún más lejos

¿Y por qué no ir aún más lejos? ¿No podríamos sucumbir al atractivo movimiento del « No Estimate »? La marcha es todavía demasiado alta para muchas empresas. Por eso un primer paso con una unidad personalizada para cada proyecto es una opción aceptable y que va en el buen sentido.

Conclusión

Hacer agilidad, al estado del arte, es a menudo muy complicado e inconcebible para muchas estructuras. Liberarse de los « días/meses hombre » y pasar a los « story point » ya es una buena iniciativa, pero no hay que caer en los defectos descritos más arriba. Una vez que la empresa ha adquirido esta cultura de la agilidad y quiere empujar más lejos la experiencia, romper las comparaciones posibles entre puntos es un primer peldaño alcanzable sin demasiado esfuerzo antes de intentar lanzarse al baño del «No estimate».

PS : Este texto fue escrito inicialmente en mayo de 2020, lo he dejado voluntariamente tal cual, porque al final, sigo compartiendo esta opinión.