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 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.
No hay comentarios:
Publicar un comentario