El triángulo de hierro, que siempre que hablo de estimación (ágil) es algo con lo que suelo comenzar, es una antigua creación, que ya hemos tratado alguna vez, del año 69, que se la debemos a un tal Barnes, que habla de que cada proyecto se ve afectado, principalmente, por 3 restricciones (que vendrían a ser los vértices del triángulo):
- Presupuesto, recursos.
- Alcance (lo que hay que hacer).
- Tiempo disponible.
Lo que nos cuenta el triángulo de hierro es que estos tres factores se condicionan, unos a otros. Y nos viene a decir que, hasta cierto punto, se pueden fijar hasta dos de estas tres dimensiones… pero tiene que dejar libre la tercera.
Así, si se fija el presupuesto y el alcance, debe dejar que sea el equipo de creación quien maneje el tiempo. Si se fija tiempo y alcance, se debe ser flexible en presupuesto. Y si fija tiempo y presupuesto, se debe ser flexible en el alcance.
Una de las cosas que nos contaba el triángulo de hierro era que cuando, en las malas gestiones de proyectos (ágiles o no), llevábamos esos tres factores a imposiciones que rozaban lo imposible (pocos recursos, mucho alcance y poco tiempo) aparecía una cuarta variable… la calidad del producto, que saltaba por los aires (la deuda técnica va por ahí).
El triángulo de hierro en agilidad
En el ciclo de vida en cascada, y en los proyectos tradicionales, que fija el alcance (los requisitos), el tiempo disponible (la estimación) y, en consecuencia y en teoría, debiera quedar abierta la tercera variable, los recursos, la dura realidad nos decía que esa variable era muy duro dejarla abierta y al final… también quedaba fijada.
En los «proyectos» (si pasas por aquí, ya debes saber porque pongo comillas a lo de proyecto) ágiles se fijan fechas (entregas a final del Sprint, si bien el número de Sprints queda condicionado al alcance final) y los recursos (equipo estable), mientras que el alcance es la variable más libre (bienvenido el cambio).
Y, es más, aunque a algunos se les olvide, en agilidad se asume que la cuarta variable, la calidad, también queda fijada en unos mínimos (de ahí que el ciclo de vida ágil sea iterativo e incremental), de ahí en control de la deuda técnica en cada Sprint y de ahí que el ciclo de vida no sea solo incremental, que sea también iterativo y que se dedique explícitamente tiempo a ello durante el Sprint (ojo con frenar la velocidad a corto plazo por, supuestamente, ganarla a largo plazo).
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Personalmente, creo que el modelo de 3 restricciones ya está anticuado, y que es más adecuado hablar de mas restricciones.
Por ejemplo, me gusta plantear la calidad o los riesgos como restricciones.
La realidad es que cuando te fuerzan el tiempo y los costes, no te dejan abierto el alcance, también te lo cierran en la parte funcional. Así qué, ¿Qué hace el equipo? Pues a la desesperada afecta a las otras restricciones: Calidad, riesgos, alcance técnico (mantenibilidad del código, herramientas para su explotación, seguridad, etc.). Y ya sabemos todos como acaba eso.