Metodologías ágiles. ¿Me las creo o no me las creo?

Últimamente parece que los congresos y otros saraos sobre metodologías ágiles de desarrollo aparecen de debajo de las piedras. Están de moda, está claro. Ante todo, debo reconocer que aunque realmente me encantaría haber podido hacerlo, hasta ahora no he participado nunca en un proyecto en el que se siga alguna metodología ágil. Así que en este artículo parto del desconocimiento y diré irremediablemente un montón de tonterías. En cualquier caso, ya adelanto que las metodologías ágiles me generan tanto entusiasmo como dudas.

En el año 2001, Kent Beck (que básicamente quería vender su libro) convocó a unas cuantas mentes pensantes del desarrollo software y, con una cerveza en la mano, les dijo algo así como: "Señores, ¿están tan hartos como yo de tanta tontería?". El resto se miraron unos a otros, pensando cada uno en ese sufrimiento que les acarreaba el día a día en el trabajo: la incomprensión de sus jefes, ese documento que no vale para nada y nunca se acaba, el echarse las culpas unos a otros... Así que cogieron la petaca de whisky, la apuraron de un trago y todos al unísono gritaron: "¡¡¡Cambiemos el mundo!!!". Vale, seguramente no fue exactamente de esta forma, pero ey, si yo fuera a hacer una película sobre el tema la haría así, ¿qué pasa?.

El caso es que dice la leyenda que estos 17 tipos se pusieron de acuerdo para redactar los 4 principios maestros del desarrollo ágil, recogidos en lo que vinieron a llamar el manifiesto ágil (por cierto, cualquiera que haya estado en una reunión de su comunidad de vecinos sabrá que el que 17 tipos se pongan de acuerdo en algo en una tarde es cuanto menos difícil de creer, pero atribuyamos el mérito al alcohol y créamoslo, que al fin y al cabo da un poco igual si sucedió así o no). Los 4 principios tienen la forma "X mola más que Y", que no es que Y no mole, que si hay que ir se va, pero es que X es la leche y es lo que hay que potenciar. Estos son los 4 principios o valores.

1. Viva la gente (la hay donde quiera que vas)

Como comentaba en mi primer artículo sobre UML, unos años atrás las mentes pensantes del desarrollo de software se estrujaban las meninges buscando una metodología que hiciera el desarrollo tan fácil que cualquier mequetrefe fuera capaz de hacerlo con los ojos cerrados. Se pretendía que el desarrollo no fuera un proceso creativo, sino que siguiendo unos pasos bien definidos se pudiera casi automatizar.

Pero esto no es cierto. Lo cierto es que para hacer un buen diseño, que sea flexible y mantenible, tienes que ser creativo. Tienes que pensar. Y está demostrado que un buen desarrollador cunde más a largo plazo que muchos malos.

Por otra parte, también está demostrado que el rendimiento de una persona que está motivada con lo que hace es infinitamente superior al de la que no lo está. Esto tiene muchas implicaciones. No es fácil estar motivado. Tienes que sentir que controlas completamente el software que estás haciendo, que lo conoces bien, que tienes tu parte de responsabilidad sobre él. Tienes que hacer tareas creativas, no tareas aburridas.

Y aquí llega mi primera duda. Porque la vida real... ¿es así?. ¿No aparecen día sí y día también tareas soporíferamente aburridas, que no se pueden atajar haciendo de otra forma y que además no hay más remedio que hacerlas?. ¿No hay un montón de gente que se ha metido en el desarrollo porque da de comer, pero que realmente ni se sienten especialmente motivados ni les interesa sentirse así, sino que se prefieren limitarse a "cumplir órdenes"?. ¿Dónde encaja todo esto en las metodologías ágiles?.

2. Muerte al papel (efecto Fahrenheit 451)

Tradicionalmente creo que ha habido dos grandes problemas con la documentación. El primero es que muchas metodologías "de las antiguas" requerían una cantidad indecente de documentación. Yo personalmente he trabajado en proyectos en los que el equipo que había se tiraba más de un año haciendo toneladas de documentación, y cuando se querían dar cuenta no habían hecho nada de software real y el tiempo se estaba acabando. Al final resulta que se tiene que hacer todo el desarrollo corriendo y sin que la mayor parte de la documentación existente ayudase demasiado. Es una pérdida de tiempo y de energías, y además, desmotiva.

Pero el segundo problema creo que es aún peor, y tiene que ver con el paso del tiempo. Ocurre porque el software y la documentación son entidades diferentes. Están disociadas. Llega un momento en que, una vez entregada la primera fase del proyecto, dentro del mantenimiento se modifica el software pero no la documentación. ¿Para qué sirve una documentación que no está actualizada?.

Para resolver esto, en mi opinión lo que hay que hacer es integrar la documentación en el propio software. Olvidar la idea del "documento". Un gran ejemplo de esto es el JavaDoc. Pero creo que no basta con eso. Creo que aún nos falta subir más de nivel de abstracción. En mi segundo artículo sobre UML ya mencionaba la importancia de que los diagramas UML estuvieran integrados con el código Java, usando lo que se llamó (entre otros nombres) "live round-trip". Y aún podría ir más allá, porque también tengo mis propias ideas sobre el análisis de requisitos integrado con el código. Pero eso ya lo contaré en otra ocasión (me queda mucho de lo que hablar hasta llegar ahí)...

En este punto de la documentación, la verdad es que mis dudas son menores. Lo único que me pregunto es: ¿la gente estará siendo capaz de medir bien y ser racional con la documentación que se produce para el software?. En esto de la documentación, yo casi siempre lo que he visto han sido extremos: o te obligan a documentar demasiado, o no se documenta nada. Es decir, ¿se estará usando esto como excusa para no documentar nada de nada?. ¿Ni unos mínimos JavaDoc, ni una mínima documentación de intenciones, nada de nada?.

3. El cliente es tu amigo

Tengo que reconocer que la idea es muy buena. Es difícil que el software que se produzca satisfaga al cliente y cumpla sus necesidades cuando el cliente no está ahí siempre que haya alguna duda. Si hay que esperar a que haya una reunión para preguntarle, todo se retrasa. Muchas veces se tira "por el camino del medio", acertando en algunas ocasiones y en otras no. Muchas veces esas reuniones, cuando por fin llegan, se estiran y estiran y cuando sales te das cuenta de que no le has preguntado nada de lo que necesitabas saber (y que te duele la cabeza, además). Pero también muchas, muchas veces, el cliente se para a mirar lo que llevas hecho cuando sólo quedan dos semanas para la puesta en producción. Y entonces decide cambiarlo todo.

La idea, como digo, es buenísima, que el cliente participe dentro del propio desarrollo, que haya una comunicación frecuente con él y pueda resolver todas las dudas rápidamente. Pero... ¿es realista en la mayor parte de las ocasiones?. ¿De verdad los clientes se prestan a colaborar en los proyectos?. En mi experiencia, muchos clientes tienen su propio trabajo que sacar adelante, y consideran que no tienen tiempo para eso. Consideran que es tu problema. No entienden la importancia de ese tema. Ya te han contado qué es lo que necesitan, así que déjales en paz. Por supuesto, hay clientes y clientes. Pero me surgen muchas dudas sobre la resistencia que presentarán muchos clientes en contra de esa colaboración.

4. Be water, my friend

Ya he comentado en alguna ocasión que el desarrollo de un producto de software es un proceso de aprendizaje. Según se va profundizando en él, mejor se va entendiendo, y al hacerlo se van descubriendo nuevas implicaciones del desarrollo. Cosas nuevas que hay que hacer, o cosas que cuestan mucho más de lo que se había pensado al principio porque obligan a cambiar otras cosas o no se pueden plantear como se tenía previsto. Esto hace que los planes a largo plazo (e incluso a medio, y diría que muchas veces hasta a corto) sean difíciles de seguir, porque lo normal es que se descubran cosas nuevas sobre la marcha, y en ese caso siempre hay que acabar sacrificando algo. O el proyecto sale menos rentable, o se resiente la calidad del producto, o (más a menudo de lo que debería, sobre todo en consultoras) lo que se sacrifica es el tiempo de los programadores, que acaban haciendo horas no retribuidas como campeones, apelando al "compromiso con la empresa".

En cualquiera de los casos, se propaga un sentimiento de culpabilidad: "alguien ha hecho algo mal". "Esto no debe seguir así". "A partir de ahora vamos a hacer las cosas bien, y vamos a... planificar más cosas y mejor".

Las metodologías ágiles afrontan este problema dándole más importancia a la "respuesta al cambio" que al plan. Esto tiene una implicación enorme sobre la forma de trabajar de las empresas con sus clientes: requiere cambiar la forma en la que se hacen los contratos con el cliente. Ya no valen contratos cerrados, tipo "me haces todas estas funcionalidades en este tiempo y yo te pago esto". Nos vamos a una facturación por tiempo trabajado. Por un lado eso invalida directamente este tipo de desarrollos con determinado tipo de contrataciones, por ejemplo, cualquier proyecto con la administración pública, que tiene que ser cerrado por definición. Aparte de eso, ¿cuál es el problema de esto?. Que requiere una gran confianza. Confianza del cliente hacia la empresa del desarrollo, para que no piense "estos me están queriendo timar, me están cobrando una barbaridad para lo que están haciendo". Confianza del gestor de la empresa de desarrollo con el equipo que va a programarlo, para que no piense "estos se están pasando el día tocándose las narices, y el cliente se va a cabrear y nos va a dejar tirados".


¿Y en el fondo, no es ese el principal problema que tienen las metodologías ágiles? (aparte del hecho de que hay un conjunto grande de gente y/o situaciones para las que sencillamente no valen). Que requieren confianza. Que requieren querer hacerlo. Confianza del programador en el resto del equipo, confianza en que se está haciendo lo correcto, confianza en que la dirección lo va a soportar, confianza en que el cliente lo va a apoyar. Confianza de la dirección en el equipo de desarrollo, confianza en que va a funcionar bien, confianza en que al cliente le va a gustar. En definitiva, requieren que todos los implicados crean en lo que se está haciendo, desde el cliente que pone el dinero hasta el becario que echa una mano con lo que sea. Requieren que todos crean en el trabajo de ese equipo y de todos y cada uno de sus componentes.

¿Y sabéis qué?. Que yo me creo todo eso. Creo en la sinergia. Creo en que cada persona es capaz finalmente de asumir responsabilidades por sí misma, cuando se le otorga la confianza para que lo haga.

Pero no estoy seguro de que el mundo esté preparado para ello. Me parece un cambio de orientación demasiado grande y que afecta a demasiadas partes. Tengo muchas dudas. Me cuesta creer que las metodologías ágiles se estén usando de forma generalizada.

Así que si estás leyendo esto y has tenido ocasión de trabajar en algún proyecto siguiendo una metodología ágil, por favor, deja un comentario y comparte tu experiencia. Cuéntanos cómo convenciste a tus clientes y a tus jefes. Yo estoy dispuesto a apurar mi petaca de whisky y gritar: "¡Cambiemos el mundo!".


NOTA: Sí, los chistecillos son míos, haciendo un poco el tonto con el Inkscape juntando personajes que he cogido de por aquí y por allá (he procurado que fueran todos de dominio público). La mayor parte proceden de Open ClipArt.