Agile y el Triángulo de Hierro

Agile y el "Triángulo de Hierro"

¡¡¡ Separando lo inseparable !!!

Jorge Fernández (www.linkedin.com/in/jorgelfernandezalvarez)

 

"La inteligencia es el cuestionamiento del método."

Jiddu Krishnamurti (1895-1986)

 


Reconozco que siempre me llamó la atención todo lo relacionado con el paradigma Agile, pero llevo mucho tiempo dándole vueltas y hay algo que no acaba de convencerme. ¿Realmente  estamos vendiendo/comprando desarrollo Agile? Me cuesta reconocerlo, pero la respuesta en la mayoría de los casos, es no.

Habitualmente, nos conformamos con unas cuantas reuniones de pie, una pared plagada de postits y alguna buena práctica más, pero ¿vale con eso para considerar un proyecto Agile? Si la respuesta vuelve a ser no, ¿qué nos falta para que los proyectos sean realmente Agile?

Yo creo que el problema no está en cómo desarrollamos y adaptamos la metodología en nuestros proyectos, el problema está mucho antes de llegar al propio desarrollo, está en la fase de proposición/negociación/contratación del propio proyecto. Después de años de agilismo, seguimos empecinados en plegarnos al tradicional “El Triángulo de Hierro”, como si eso nos diese la tan buscada tranquilidad y la confianza en el éxito futuro. Nada más lejos de la realidad.

El objetivo de esta trilogía de artículos o reflexiones (inicialmente dimensionado así en mi cabeza, aunque no descarto pueda crecer en un futuro próximo), no es otra que la de expresar sobre un folio en blanco:

las experiencias y frustraciones vividas en la realización de propuestas y proyectos, en teoría desarrollados bajo metodología Agile,

la incansable búsqueda de la utopía, de cambio de visión/realidad a través de ejemplos de la vida real, y por último

la necesaria vuelta a la realidad, materializando algunas de estas ideas en alternativas concretas y viables, que aunque no sacien completamente el deseo de transformación radical de nuestro entorno de trabajo, al menos represente un giro en el día a día y en la percepción de felicidad de todos los actores que intervenimos en el campo del desarrollo de proyectos IT.

En este primer artículo Agile y el “Triángulo de Hierro”, navegaremos por el proceso de construcción de propuestas de desarrollo bajo paradigmas Agile, analizando las variables y los procesos que se llevan a cabo en la estimación/negociación/contratación, tanto en la versión más habitual, como en la versión más comprometida con la filosofía Agile, finalizando con las alternativas de formalización de la relación/compromisos entre los participantes de esta nueva manera de construir acuerdos. 

Las variables

¿Qué factores intervienen a la hora de estimar un proyecto?


Independientemente de la época, del proyecto, de la tecnología, de la metodología, las preguntas que se formulan a la hora de acometer un proyecto, siempre han sido las mismas, ¿qué? y ¿cuánto? (obviamente habrá un ¿por qué? previo, y si nos paramos a pensar detenidamente, estaremos de acuerdo que el ¿cómo?, realmente no es determinante).

Conocemos, o creemos que conocemos, qué queremos y necesitamos saber cuánto nos va costar, tanto a nivel de tiempo como de coste.

Estas preguntas desembocan en las variables a definir y que representan los vértices del “El Triángulo de Hierro”: Alcance, Tiempo y Coste (añadiremos Equipo y Esfuerzo que aunque son parte del ¿cómo?, nos ayudarán a entender el proceso seguido en la estimación).

En la siguiente tabla, se definen las 5 variables principales y los elementos relacionados (subprocesos, variables, constantes, fórmulas, …), que van a permitirnos presentar una aproximación Agile de cada una de ellas.

 

La realidad

¿Cómo funciona habitualmente el proceso de elaboración de una oferta de Desarrollo de Software bajo el paradigma Agile?


Como hemos comentado, lo normal es conocer el Alcance (habitualmente definido como requisitos en formato textual) y probablemente se conocerá también el Tiempo de ejecución máximo y el Coste máximo (sobre todo en Concursos Públicos).

Con estos parámetros de entrada, el proceso que llevamos a cabo para calcular y cerrar los 3 vértices y conseguir de esta forma un contrato/acuerdo de desarrollo de un proyecto, sería el siguiente.

 

PROCESO:

1.- Como primer paso, se convierten los requisitos en Historia de Usuario / Épicas, creando el Backlog Inicial, dándole una apariencia Agile al Alcance.

2.- Se realiza una estimación en Puntos de Historia utilizando un método de estimación Agile (Poker Scrum) para tener cuantificado el Alcance (por ejemplo utilizando la escala de Cohn).

En este punto, a menudo se comete el error de transformar los Puntos de Historia en horas, a través de una constante que hemos denominado T2ATF, y de ahí obtener directamente el Coste en función del coste medio por hora y el número total de horas (líneas rojas).

3.- Conocido el Tiempo, se calcula el Número de Sprints, dividiéndolo por la Duración del Sprint (variable de entrada, de valor 2 ó 3 semanas) y se calcula la Velocidad necesaria, dividiendo el Total de Puntos de Historia entre el Número de Sprints. Esta Velocidad permitirá confeccionar el Equipo necesario que tenga como propiedad intrínseca esa Velocidad.

Si no se conoce el Tiempo, se propone un Equipo determinado, con su Velocidad asociada, y se calcula a partir del total de Puntos de Historia, la Duración del Sprint y la Velocidad de dicho Equipo.

4.- Dicho Equipo tendrá un Coste Medio asociado por Sprint, que nos permitirá, multiplicándolo por el número de Sprints, obtener el Coste Total del Proyecto.

 


Cálculo del Alcance de un proyecto Agile, en función de Coste y Tiempo.

 

REFLEXIONES:

Cierre contractual del Alcance antes de abordar el proyecto. Esta pretensión convierte esta actividad en compleja y crítica, requiriendo mucho tiempo y esfuerzo la definición concreta del mismo y complicando cualquier futura modificación por sencilla que sea.

Estimación temprana y con alto riesgo (no se tiene en cuenta el Cono de Incertidumbre de Cohn) y sin intervención del Equipo (de hecho en el momento de la estimación, aún no se ha definido).

¿Qué sucede si el Coste resultante de este proceso no está dentro de las expectativas? La primera tentación es reducir el Coste medio del Equipo, normalmente no teniendo en cuenta que esta reducción, por lógica debería disminuir la Velocidad del Equipo, y por ende, aumentar el Tiempo necesario, manteniendo el Coste total invariable (esta consecuencia no debe ser tomada al pie de la letra, ya que no hay un 100% de proporcionalidad en la relación Velocidad y Coste medio de un Equipo, ya que intervienen diversos factores que siempre dan lugar a largas discusiones cuasi filosóficas). La única solución posible debe ir ligada a la nunca sencilla y viable reducción del Alcance.

 

El deseo (aspiración, anhelo, pretensión, objetivo, utopía, …)

¿Cómo debería ser el proceso de elaboración de una oferta de Desarrollo de Software bajo el paradigma Agile?


Entendiendo que no es posible, por mucho que nos empecinemos, fijar los 3 vértices y que “debemos liberar” uno de ellos variabilizándolo en función de los otros 2, lo más sencillo debería ser fijar el Coste y el Tiempo (que presupuesto se dispone para un periodo determinado).

Con estos idílicos parámetros de entrada, el proceso que se llevaría a cabo para calcular y “cerrar” el 3er vértice (en este caso el Alcance), sería el siguiente (luego veremos cómo se puede formalizar en compromisos esta nueva forma de definir el Alcance).

 

PROCESO:

1.- A partir del Tiempo se establece el número de Sprints necesarios (en función de la Duración del Sprint).

2.- A partir del Coste se obtiene el Coste medio del mejor Equipo que se puede proporcionar. Este Equipo tendrá asociada una Velocidad determinada.

A menudo, se comete el error de transformar el Coste en horas, y utilizando la constante que hemos denominado T2ATF, determinar el Alcance en Puntos de Historia, sin tener en cuenta el Equipo (líneas rojas).

3.- Con la Velocidad del Equipo y el Número de Sprints, se obtiene el número total de Puntos de Historia (Alcance) que se pueden acometer con dicho presupuesto en dicho periodo de tiempo.

Opcionalmente, se pueden convertir los requisitos en Historia de Usuario / Épicas, creando de esta forma el Backlog Inicial. A partir de estas Historias, se realiza una estimación en Puntos de Historia utilizando un método de estimación Agile (Poker Scrum) y se define el Alcance en Historias de Usuario a desarrollar. Este punto se recomienda definirlo durante la Fase de Inception del Proyecto.

 

 

Cálculo del Alcance de un proyecto Agile, en función de Coste y Tiempo.

 

REFLEXIONES:

Alcance abierto pudiéndose variar durante la ejecución del proyecto, sin que aparezcan los habituales problemas (con la salvedad de que no sea del del Sprint en curso).

Estimación tardía y realizada con la intervención Equipo.

Coste dentro de las expectativas.

 

El compromiso

¿Cómo vincular contractualmente un proyecto de Desarrollo de Software bajo el paradigma Agile?


¿Dónde radica la dificultad para la implementación de este nuevo proceso? La mayoría de las ocasiones, es inviable/impensable para el Owner del proyecto, abordarlo con el Alcance, es decir el qué, no suficientemente cerrado y especificado a sangre y fuego, pero,  ¿realmente el proceso anterior no cierra/compromete los 3 vértices? Sí, los 3 vértices están cerrados, pero la percepción no suele ser esa, ya que este cambio en la definición del Alcance, genera muchos temores sobre las funcionalidades o requisitos reales que finalmente se implementarán bajo el acuerdo alcanzado.

Entonces, ¿Cómo implementamos los compromisos en el acuerdo formal? Las 3 alternativas posibles en función de donde situemos el foco y los riesgos del proyecto, serían: 

 

Alcance cerrado definido en Historias de Usuario (MVP)

En esta alternativa se definirá el Backlog (Alcance), incluyendo aquellas historias que sean prioritarias para conseguir el MVP y que sean compatibles con las variables Coste/Tiempo definidas. (Fase de Inception previa al comienzo del Proyecto).

Una vez fijadas las 3 variables para este escenario, el compromiso será la realización de las historias de usuario definidas en dicho Alcance (MVP)

Esta aproximación es ideal, pero es costosa y difícil de llevar a cabo durante el proceso de competición/selección, siendo una alternativa habitual cuando existe una relación de confianza previa.

 

Alcance cerrado en Puntos de Historia

En esta alternativa, a partir del Coste/Tiempo disponible, se establecerá el Equipo, con su velocidad asociada, calculando el Alcance a realizar definido como Puntos de Historia a realizar.

Una vez fijadas las 3 variables para este escenario, el compromiso será la realización de los puntos de historia acordados, no siendo necesario definir las historias a desarrollar en el momento inicial, permitiendo además, definirlas/cambiarlas a lo largo del proyecto, dentro de la fase de planificación de cada Sprint.

No quiero pecar de ingenuo, ni hacer trampas al solitario, soy consciente de que el mayor riesgo/temor de esta aproximación, es que el acuerdo depende de forma directa y crítica de la posterior estimación de las Historias de Usuario, y su conversión a Puntos de Historia. Esta labor normalmente la realiza el ofertante, convirtiéndose, durante el proceso, en juez y parte.

 

Asistencia Técnica (Time&materials)

En esta alternativa, a partir del Coste/Tiempo disponible, se establecerá el Equipo, con su Velocidad asociada, y se realizará el proyecto definiendo las historias a realizar en cada Sprint dentro de su fase de planificación.

El compromiso será la realización del mejor producto posible, imputando solamente el esfuerzo real realizado en cada Sprint.

Esta alternativa denota una desconfianza inicial nada recomendable a la hora de aventurarse en una próspera relación. Además, obliga a realizar tareas de control (micromanagement) nada deseables.

 

La clave está en la CONFIANZA, si no se cree que se va a realizar el mejor producto posible para dicho Tiempo y Coste, lo mejor es no acometer el proyecto y buscar otras alternativas de mayor confianza.

 

En el próximo artículo analizaremos un caso real de un proyecto fuera del mundo IT, enmarcado dentro de la primera alternativa definida en este artículo (MVP) y sus posibles analogías aplicables a nuestro entorno. Por último, para cerrar esta trilogía intentaremos profundidad en la difícil tarea de medir la confianza para realizar la mejor selección previa.