Primera respuesta: las metodologías ágiles son formas de organizar el trabajo cotidiano en los equipos de desarrollo de software tendientes a producir los mejores resultados posibles en lapsos de tiempo fijos. No son fórmulas mágicas, no son ni involucran tecnologías o herramientas complejas; se trata simplemente de conjuntos de prácticas y principios que, en base al sentido común, buscan sacar el mayor provecho posible del tiempo y los recursos disponibles.
Así como los adeptos al parkour buscan desplazarse de un punto a otro en la forma más eficiente y rápida que sea posible, y manteniendo un flujo constante de movimiento, en las metodologías ágiles se busca comenzar a generar software productivo desde los primeros días de un proyecto, y mantener un flujo constante de producción de software hasta tanto se logre cubrir la gran mayoría de los requerimientos pedidos por el cliente o el usuario. ¿Por qué “la gran mayoría” y no simplemente “todos” los requerimientos? Por que, a veces, lo mejor es enemigo de lo bueno, y la búsqueda de la perfección nos puede desviar de nuestro real objetivo. Pero no nos adelantemos.
¿Cómo nació el agilismo?
Como dice un famoso refrán: “aquellos que no estudian su historia están condenados a repetirla”, así que repasemos la historia de las metodologías ágiles. En los albores de la programación –allá por la década de 1960– no había metodologías. La forma de trabajar era muy simple: el programador recibía una especificación (un pedido, digamos) y, en base a ella, escribía un programa que le entregaba al usuario. El usuario lo probaba, y si le encontraba errores, se lo devolvía al programador para que los corrigiera. El programador los corregía y le daba una nueva versión al usuario. Este ciclo se repetía hasta que el programa no tuviera más errores. Simple.
Hoy a esa metodología primigenia se la conoce como “code and fix” (codificar y corregir). En teoría suena bien, pero lo que termina pasando es que, cuando un programa se vuelve medianamente complejo, en cada ciclo de codificar y corregir la cantidad de errores aumenta en lugar de reducirse, y esa supuesta metodología se transforma en un círculo vicioso del que se hace imposible salir.
“¿Cómo resolvemos eso?”, pensaron los programadores de aquel entonces. Y en lugar de tratar de inventar algo nuevo, decidieron espiar la forma de trabajar en ramas más tradicionales de la ingeniería; por ejemplo, la ingeniería civil. Y resolvieron crear la ingeniería del software, basándose en los principios de las ingenierías más maduras. “Al fin y al cabo, si ellos pueden construir puentes que no se caen, ¿por qué nosotros no podemos desarrollar sistemas que no fallan?”, habrán pensado esos primeros ingenieros de software.
Entonces empezaron a definir nuevas formas de trabajar más maduramente. Para empezar, se necesitaban planos (llamémoslos diagramas) y documentos de especificación del software a desarrollar, para poder tener una idea de cómo sería el programa resultante antes de empezar a escribir líneas de código. El usuario debía revisar esos diagramas y especificaciones, y ver si reflejaban sus necesidades; si no era así, los diagramas y documentos se corregían hasta que el usuario estuviera satisfecho con ellos. Recién cuando el usuario daba el OK a todos los diagramas y documentos, se daba por terminada la fase de análisis en el proceso de desarrollo, y los programadores empezaban a escribir código en base a lo que decían los diagramas y documentos. Una vez que el software estaba completo, el usuario lo probaba, y si encontraba errores (que teóricamente debían ser pocos o ninguno), los programadores los corregían y le devolvían el software listo para comenzar a operar.
“Genial, ya no tendremos nada que envidiarles a esos engreídos ingenieros civiles”, habrán pensado los primeros ingenieros de software. Qué equivocados estaban.
Durante bastante tiempo se trabajó de esa forma supuestamente madura, y los problemas no tardaron en aparecer, evidenciados por frías y crueles cifras estadísticas que mostraban el grado de fracaso de los primeros intentos de convertir al desarrollo de software en una ingeniería. Estas cifras aseguraban que el 31 por ciento de los proyectos de desarrollo de software fracasaban; apenas entre un 9 y un 16 por ciento terminaban dentro de los plazos y presupuestos establecidos; 45 por ciento de las características pedidas nunca se usaban, y 19 por ciento se usaban muy esporádicamente. Estas cifras datan del año 1994… es de esperar que hayan cambiado para mejor en todos estos años.
La cuestión es que se puso en evidencia que los métodos que sirven para otras disciplinas (como la ingeniería civil) no son aplicables a la ingeniería de software. Había que repensar las cosas seriamente.
“Cascada”, una mala palabra
La forma de trabajar en el desarrollo de software después del primitivo “code and fix” fue la famosa metodología de cascada. ¿Por qué cascada? Por que el trabajo fluye en un solo sentido, pasando por distintos escalones: análisis, diseño, programación, testing, implementación. Una vez concluida cada etapa, el trabajo “cae” a la siguiente. No hay vueltas atrás.
Hoy, cuando se dice en voz alta la palabra “cascada”, a los ingenieros de software se les hiela la sangre, como si la cascada fuera la culpable de todos los males del universo. Es que, la famosa cascada, que en otras ramas de la ingeniería puede ser una forma viable de trabajar, en la ingeniería de software simplemente no funciona. Y es que los ingenieros civiles pueden hacer un modelo de un puente, y el “usuario” (o el que paga por la construcción del puente) puede tener una idea bastante clara de cómo va a ser y cómo funcionará. Pero por más que nos esforcemos en hacer prototipos y descripciones funcionales que muestren anticipadamente cómo funcionará una aplicación de software, siempre, SIEMPRE, el usuario encontrará algo para decir “ah, pero eso no es lo que yo pedí”. Y lo dirá cuando tenga el software instalado y funcionando. Y en ese momento será extremadamente costoso adaptar el software a lo que el usuario realmente quiere.
En conclusión, hay que entender que ningún documento de especificación, ningún diagrama, ningún prototipo, da garantías de representar fielmente lo que se necesita desarrollar en un proyecto de software. El software, instalado y funcionando, es el único producto sobre el cual el usuario puede decir con seguridad “sí, me sirve” o “no, eso no es exactamente lo que necesito”. Entonces, la forma más adecuada de trabajar en ingeniería de software es comenzar lo antes posible a escribir código y a entregar software que funcione.
¿Significa acaso que hay que olvidarse de crear diagramas, documentos, especificaciones, prototipos, etc.? ¿Volvemos al code-and-fix de los años 60? No tan rápido. No es tan sencilla la cosa.
Lo que dicen las metodologías ágiles es que no hay que esperar a que toda la documentación esté lista para empezar a escribir código. No hay que cumplir un estricto ceremonial y protocolo, en donde todos los documentos estén impecables y cuenten con todas las aprobaciones necesarias como para comenzar a convertirlos en programas utilizables. La forma de trabajar ágil consiste en atacar antes que nada el centro del problema que queremos resolver con una aplicación de software. No TODO el problema; solamente el centro. Luego, documentar lo indispensable como para agilizar la programación, e involucrar al usuario en el trabajo de desarrollo. Que participe en las definiciones, que ayude a crear los diagramas, que vea cómo funciona el software a medida en que se lo va desarrollando/testeando, y que ayude a mejorarlo. Una vez resuelta la parte central del sistema en desarrollo, se comienza a avanzar sobre aspectos menos críticos, menos importantes, más periféricos. Todo esto sin perder de vista el objetivo principal: llegar, en un tiempo establecido, a terminar un software que cumpla de la mejor forma posible con una serie de requerimientos.
Queda contestada entonces la segunda pregunta: para qué sirven las metodologías ágiles.
A a la sans-façon
Por lo dicho hasta aquí, suena como que trabajar con métodos ágiles equivale a hacer las cosas en forma descuidada o descontrolada. Nada más alejado de la realidad.
Para minimizar el “ceremonial”, la documentación y la burocracia se requiere, curiosamente, de una gran disciplina. Tal disciplina impide que se pierda el rumbo y los proyectos queden a la deriva. Disciplina implica control, y para ejercer el control, se requiere evidencia palpable, información permanente de lo que se está haciendo, cuánto se está avanzando, cuánto falta para llegar al objetivo.
En los lugares donde se trabaja siguiendo metodologías ágiles, pueden verse abundantes pizarras y carteleras en donde se observan listas de pendientes (los llamados backlogs), asignaciones de tareas, gráficos de velocidad, y muchos otros indicadores que permiten llevar el control del trabajo de desarrollo. Si van a una entrevista y les muestran las oficinas donde trabajan los programadores, y no ven ni pizarras ni gráficos ni carteleras, lo más probable es que allí no usen metodologías ágiles (ver abajo el apartado “Los falsos agilistas”).
Esto nos lleva a buscar la respuesta para la última pregunta: ¿por qué las metodologías ágiles son tan importantes?
Los 17 apóstoles
El 17 de febrero del año 2001, en una reunión convocada por el creador de Extreme Programming (véase abajo la tabla “Breve sinopsis de las principales metodologías”), 17 críticos de las metodologías de desarrollo acuñaron el término “Métodos Ágiles” para denominar a los métodos que estaban surgiendo como alternativa a las metodologías formales y “pesadas”. Después de aquella reunión, los 17 apóstoles del agilismo se dispersaron para difundir la palabra, habiendo redactado una suerte de constitución, llamada el Manifiesto ágil (véase abajo el apartado“Manifiesto ágil”).
Después de aquella mítica reunión, el agilismo se conoció en todo el mundo, siendo las demostraciones tangibles de su efectividad la mejor publicidad. La empresa VersionOne, además de vender herramientas para manejo de proyectos de desarrollo, se ocupa todos los años (desde hace 8 años) de hacer una encuesta –llamada “State of Agile”– que mide los resultados de la aplicación de las metodologías ágiles. En la encuesta del año 2013, el 92 por ciento de los consultados dijo que la implementación de estas metodologías mejoró su capacidad para controlar los cambios de prioridades. Otros beneficios mencionados por los encuestados incluyeron una mayor visibilidad de los proyectos, mejoras en la moral de los equipos de trabajo, y una mayor alineación con los objetivos de negocio de la empresa.
Hoy nadie duda de las ventajas de las metodologías ágiles, particularmente de su potencial para lidiar con los cambios de prioridades, que son el principal problema con el que se enfrentan los proyectos de desarrollo de software. En otras ingenierías, una vez que se establecen claramente los requerimientos, éstos no sufren grandes cambios a lo largo del proyecto. Pero en el desarrollo de software, la magnitud de los cambios es tal que, trasladados a la ingeniería civil, sería equivalente a que cuando un puente está casi terminado, se decida que el mismo debe ser levadizo para dejar pasar barcos de 15 metros de altura.
Lo bueno de estas metodologías es que, para ponerlas en práctica, no hace falta aprender a dominar nuevas y complicadas herramientas. Sólo se trata de aplicar una serie de prácticas que varían entre una metodología y otra, pero en todos los casos brindan beneficios inmediatos que hacen que los proyectos terminen en el plazo esperado, cumplan con las verdaderas necesidades del cliente y (quizás lo más importante) que los programadores puedan trabajar más relajados y más motivados. Y todos contentos.
Breve sinopsis de las principales metodologías
|
Metodología
|
Claves
|
Características
|
Problemas
|
|
Scrum
|
Equipos de trabajo
pequeños, independientes, auto-organizados. Ciclos de 30 días, participación
de un guía o Scrum Master.
|
Deja de lado lo
“definido y repetible” para reforzar el concepto de desarrollo de nuevos
productos.
|
No detalla las
prácticas específicas, como las pruebas de integración y de aceptación.
|
|
Extreme Programming
(XP)
|
Desarrollo guiado
por el usuario, equipos pequeños, builds diarios.
|
Concepto de
refactoring, mejora continua del código para aumentar su performance y
respuesta a los cambios.
|
Se detallan las
prácticas individuales, pero se dejan de lado las prácticas de management de
equipos y generales. Por eso no se usa XP en grandes equipos de trabajo.
|
|
Proceso Unificado
(UP o RUP)
|
Iterativo e
incremental. Adaptable a distintos tamaños de proyectos y equipos de trabajo.
Guiado por casos de uso.
|
Constituye un marco
de trabajo que puede ser ajustado y extendido según las necesidades del
equipo de trabajo.
|
Tendencia a
considerar a los casos de uso como un contrato con el cliente en lugar de una
ayuda a la programación.
|
|
FDD (Feature Driven
Development)
|
Proceso de 5 pasos,
desarrollo centrado en componentes (features) orientados a objetos.
Iteraciones muy cortas, desde horas hasta 2 semanas.
|
Simplicidad de los
métodos, diseño e implementación del sistema por features, modelado de
objetos.
|
Su foco se centra en
el diseño e implementación. Requiere otras metodologías que lo completen y
soporten.
|
El Manifiesto ágil
En la página http://agilemanifesto.org/iso/es/ puede leerse la versión en español de la “constitución” de los agilistas, llamada Manifiesto ágil, cuyos primeros párrafos dicen así:
Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.
Los falsos agilistas
Cuando nos entrevisten para un trabajo, siempre nos van a querer “vender” que la empresa está en la vanguardia, que aplica tecnologías y metodologías modernas, y entre esas virtudes seguramente mencionarán que utilizan metodologías ágiles. Ésa será nuestra oportunidad para “pasar al ataque” y empezar a preguntar, por ejemplo:
- Específicamente, ¿qué metodología usan?
- ¿Cómo organizan los equipos de trabajo?
- ¿Cómo miden la velocidad de los proyectos?
Muy probablemente nos dirán que “tenemos nuestra propia metodología, utilizando algunos elementos de Scrum, de extreme programming, etc.” Si esa es la respuesta, hay que desconfiar.
Se dice que las metodologías ágiles son como el sexo adolescente, por que:
1. Todos quieren hacerlo todo el tiempo.
2. Todos hablan de ello todo el tiempo.
3. Todos creen que todos los demás lo hacen todo el tiempo.
4. Casi nadie lo está haciendo realmente.
5. Los pocos que lo hacen:
- lo hacen mal
- están seguros de que la próxima vez será mejor
- no lo están haciendo de forma segura.
Aunque sea un chiste, hay mucho de verdad en lo antedicho, por lo cual hay que sospechar de los que dicen muy alegremente que utilizan metodologías ágiles, por que hay muchas probabilidades de que no sea cierto.
