Alfonso Arias Aguilera - ©PMP
No se vosotros, pero yo no hago más que oír la palabra Agile en mi entorno laboral. Aunque las metodologías ágiles o Agile tienen más de 10 años, el manifiesto agile fue publicado en 2001, ha sido durante los últimos años cuando este fenómeno se ha vuelto casi viral.
Pero, ¿qué es Agile? Agile es una metodología de desarrollo software basada en doce principios. No enunciaré aquí los principios, podéis leerlos en el manifiesto agile: http://www.agilemanifesto.org/iso/es/, pero trataré de resumirlos en una sola idea: entregar valor al usuario de forma recurrente y en plazos cortos.
La metodología Agile se ha desarrollado sobre todo en el entorno de las tecnologías móviles, es decir, apps para tablets y teléfonos móviles, donde el time to market es una ventaja competitiva, se trata de sacar algo que funcione y guste al usuario en un espacio muy breve de tiempo porque si no gusta y no se consume hay que desecharlo y desarrollar otro producto. No en vano ya hay más de 1 millón de apps en Google Play y Apple Store respectivamente.
Detengámonos un poco en el proceso de generación de estas aplicaciones. Son aplicaciones desarrolladas para millones de usuarios, no hay un usuario que nos dicte los requisitos de la aplicación, más bien se desarrolla algo con la esperanza de que guste a los usuarios. Esto supone un cambio radical en el paradigma del desarrollo software tradicional. Los requerimientos no parten de los usuarios, los usuarios tan solo deciden si lo que se les entrega les vale o no y en consecuencia estos proyectos tienen una gran incertidumbre. ¿Os acordáis de la triple restricción? Tiempo, plazo y alcance, pues en este tipo de proyectos el alcance es primordial. Como la incertidumbre es tan grande no interesa invertir mucho tiempo en el desarrollo antes de saber si al usuario le va a gustar o no, por lo que los desarrollos deben ser cortos con el fin de entregar al usuario una versión temprana de la aplicación y luego ir añadiéndole características según el feedback que nos den los usuarios. Es por esto que en Agile se habla de desarrollos de 2-3 semanas (sprints) y entregas al usuario incrementales (iteraciones). El usuario proporciona feedback al equipo de desarrollo, bien directamente, mediante reseñas o indirectamente, analizando el uso que hace de la aplicación. Por eso el principio Agile es hacer entregas que aporten valor al usuario de forma incremental y todo el esfuerzo se centra en definir el producto mínimo viable a entregar en cada sprint.
Como podéis comprender no tardaron mucho tiempo en intentar aplicar esta metodología a otro tipo de desarrollos software, pasando de dispositivos móviles a páginas web. ¿Y dónde está ahora el reto? Pues en aplicar esta metodología a desarrollos en el backend. Digamos que casi todas las infraestructuras software se basan en un modelo de 3 capas: front-servicios-backend. Agile se aplica con éxito en la capa front y se está empezando a aplicar en la capa de servicios ¿será posible aplicar Agile también en la capa de backend? En grandes organizaciones, cada una de estas capas suele estar estrechamente relacionada con una tecnología concreta. Por ejemplo, el front se suele desarrollar en tecnologías distribuidas (.NET, Java, etc.), la capa de backend en tecnologías Mainframe y la capa de servicios en tecnologías mixtas (distribuidos y Mainframe).
¿Qué desafíos nos encontramos al aplicar Agile en las capas de servicios y de backend? En primer lugar, no hay nada visual que enseñarle al usuario, por lo que definir cuál es el producto mínimo viable resulta una tarea un tanto infructuosa. La solución generalmente adoptada es ver a la capa front como usuario de la capa de servicios y a la capa de servicios como usuario de la capa backend. En segundo lugar, entregar desarrollos en plazos de 2 semanas se torna casi imposible en estas capas, no tanto por la tecnología usada sino porque esta suele ser un reflejo de cuán grande es la organización en la que se trabaja. Quiero decir, que si hablamos de Mainframe es porque estamos hablando de organizaciones muy grandes y complejas donde los procedimientos internos de la organización impiden desarrollar en plazos de 2 semanas. En este sentido, la solución que se está adoptando es la metodología SAFe (Scaled Agile Framework) que se podría resumir brevemente en agrupar las entregas de 2 semanas (sprints) en releases de 2-3 meses.
Recapitulemos, agile se centra sobre todo en desarrollos cortos e incrementales, es decir, en descomponer el problema en partes muy pequeñas que puedan ser construidas en plazos de 2-3 semanas. Si el desarrollo es corto implica que el equipo de trabajo no es muy numeroso, entre 5 y 10 personas y eso a su vez implica que la gestión de equipos es más sencilla y eficiente. Como además en 2-3 semanas entregas al usuario un producto, la planificación del proyecto no es muy complicada, no hay que dedicar un gran esfuerzo en la gestión del cronograma, paralelizando actividades, calculando la ruta crítica, etc. Además el equipo suele ser multidisciplinar, es decir, hay una persona especializada para cada tarea de manera que no tengan dependencias externas y sean autónomos. Claramente esto supone un gran desafío para organizaciones grandes que tengan implantada una arquitectura SOA, aplicaciones producto verticales y aplicaciones de infraestructura transversales altamente interconectadas y dependientes. En estos casos se hace muy difícil construir equipos autónomos. Resolver este problema sin cambiar la arquitectura supone en la mayoría de los casos transformar la organización. Un caso típico de esto último son las factorías de construcción y de pruebas. Un proyecto agile debería tener un equipo autónomo, que construyera el software y lo probara, es más, en un modelo ideal, el equipo agile debería integrar en sus funciones todas aquellas funciones que hay delegadas en los diferentes departamentos que intervienen en el CVP, ciclo de vida productivo: QA, Certificación, Gestión de Entornos, etc.
Por último, ¿es Agile recomendable a todos los proyectos? La respuesta es no. Solo aquellos proyectos con un alto grado de incertidumbre son buenos candidatos a desarrollarse con esta metodología. Si los requerimientos están claros no tiene mucho sentido hacer entregas parciales al usuario para que las valide. Por el contrario, si los requerimientos no están claros, las entregas parciales del producto posiblemente ayuden al usuario a definirlos mejor.
En conclusión, a día de hoy son muchas las organizaciones de gran tamaño que están introduciendo la metodología agile en su ciclo de vida productivo. A pesar de todas las dificultades ya comentadas: modelo de tres capas, arquitectura SOA, factorías de construcción, gran cantidad de departamentos interviniendo en el CVP, etc. ¿Serán estas organizaciones capaces de adoptar Agile como metodología? Creo que en breve lo sabremos, hasta entonces habrá que esperar.