El 17 de febrero de 2001 se reunió Kent Beck con otras dieciséis personas para reflexionar sobre los procesos de desarrollo de software. La sesión surgió como reacción a las metodologías dominantes entonces (CMMI y SPICE) que ellos consideraban demasiado rígidas. El resultado fue el manifiesto ágil que se basa en cuatro principios:
- Individuos e interacciones sobre procesos y herramientas.
- Software que funciona sobre documentación extensiva.
- Colaboración con el cliente sobre negociación contractual.
- Respuesta ante el cambio sobre seguir un plan.
Han pasado catorce años desde ese momento y el agilismo en el desarrollo de software hace ya tiempo que llegó a las empresas y podemos tener una opinión clara sobre el éxito de su implantación. Si definimos éxito como un equivalente a su propagación y adopción en las empresas, ha sido un éxito. Es irrebatible. Las empresas que desarrollan software ya han incorporado metodologías ágiles como Scrum o Kanban o quieren hacerlo a corto plazo.
Pero definir éxito de esta manera es una forma muy pobre. La pregunta más adecuada sería: ¿Está funcionando bien? Es una pregunta incómoda, porque requiere analizar y pensar. La bandera del agilismo ha sido izada por los mejores desarrolladores de los últimos años, sea lo que sea que signifique eso. Si uno lee el manifiesto completo, probablemente esté bastante de acuerdo, pero ya se sabe que en teoría la teoría y la práctica son lo mismo, pero en la práctica son diferentes.
Al diablo con la documentación
Todos, o al menos los más viejos del lugar, recordamos cosas tan dantescas como Métrica-3 que se pedía en la mayoría de desarrollos relacionados con la administración pública. Documentación inútil por todos lados. Con la llegada del agilismo desaparecen los documentos de texto y aparecen los post-it. Y nada más. La documentación funcional no existe, la documentación técnica menos aún. Larga vida a los árboles. Lo que hace el sistema está en los correos electrónicos del equipo y en sus cabezas. Eso no es exactamente lo que yo consideraría un avance. Se ha pasado de una excesiva documentación a no documentar nada.
Mira mamá, sin control de cambios
El cambio es bueno, decían. La satisfacción del usuario es lo principal, decían. Este es uno de los puntos más polémicos. Los cambios en el desarrollo son consustanciales. Es algo natural. El cambio es bueno, quién puede estar en contra de ese concepto. Inténtalo y te tacharán de retrógrado, seguidor de los Illuminati de la metodología en cascada y cosas aún peores. Con esa visión se levantaron todos los muros de contención que antes permitían negociar con el usuario qué incorporar y qué no. Barra libre. Pide que tú eres el que sabe lo que quiere. Yo estoy de acuerdo con esto, siempre que ante innumerables cambios disponga de un tiempo también incontable para acabarlo.
El concepto «los usuarios saben lo que quieren y lo que piden es porque lo necesitan» rivaliza en falsedad con el de «el cliente siempre tiene razón». No es popular decir esto. Pero para llegar a esa conclusión basta con acumular unos cuantos clientes, unos cuantos años de trabajo y eliminar la ceguera que impone el buenismo.
Qué demonios tiene que hacer el sistema
Los malditos casos de uso que nadie se leía en un documento de texto de 189 páginas. Tenía que haber algo mejor, lo que ya no tengo tan claro es que lo mejor sean unos post-it colgados en un tablón. Y ya. Cuando tienes que definir e implementar procesos complejos que incluyen una carga funcional fuerte, tanto de interacción con el usuario como de procesos desasistidos, en ese escenario hostil manejar lo que hay que desarrollar en unos post-it no es viable.
Un product owner para dominarlos a todos
El product owner en Scrum es el representante de todas las personas interesadas en el proyecto y el que decide qué características debe tener el software. Suena genial. Pero la vida real te dice que en un proyecto normalmente hay varios usuarios de diferentes áreas con intereses contrapuestos que hay que balancear y negociar. El product owner suele ser de un área, a veces de marketing, y casi nunca de TI. Con ese escenario, el drama está servido, la labor de intermediación no suele funcionar bien en esos casos.
La fecha de entrega ha muerto, viva la fecha de entrega
Este es mi favorito. La secuencia de pasos suele ser así. Se elige una metodología, se define el equipo, se asignan roles y empieza el trabajo. Todo el mundo está muy contento porque por fin va a poder desarrollar como los buenos de la industria. Sprint cada dos semanas y el usuario con feedback continuamente y contento. El paraíso terrenal. Pero de repente te das cuenta de que hay una fecha de entrega fija. Y que se van pidiendo funcionalidades, definidas escrupulosamente por el product owner al que le preocupa poco la fecha, y se va avanzando hacia el punto en que te espera el mago Gandalf con su «no puedes pasar». Hay que entregar. Pero el trabajo no estaba organizado para terminar en esa fecha, sino simplemente para ir haciendo cambios, incorporando nuevas funcionalidades y mejorando otras sin preocuparse de cuándo estará listo el producto para producción. Todo muy iterativo e incremental, pero haciendo una gestión del proyecto ciega con la fecha de entrega.
Las consecuencias: el bol de arroz y el orinal
Esta parte también es muy buena, aunque no muy divertida. Comienza con frases del estilo «¿como cuánto de comprometido tienes el fin de semana?». Y es entonces cuando los desarrolladores menos despiertos se dan cuenta de que algo no ha ido del todo bien. Tienen que recuperar su bol de arroz, el pijama y pasar el máximo de horas en el trabajo, para conseguir cumplir con una fecha de entrega que parecía poco relevante al comienzo, que ningún principio del manifiesto ágil comenta, pero que irónicamente es lo único que les importa de verdad a la mayoría de directivos de TI en las empresas españolas. ¿Calidad? No nos han presentado.
Conclusión: Sigue sin haber bala de plata
Hay que recurrir siempre al artículo de Frederick Brooks, que escribió en 1986: No silver bullet y su versión en español. No hay una tierra prometida, no hay una forma adecuada de desarrollar software que elimine los problemas inherentes a esta actividad. El agilismo nos ha traído buenas prácticas que nadie discute, pero también su adopción en las empresas de tamaño medio y grande ha sido en no pocas ocasiones y está siendo un completo desastre. Y las personas que nos dedicamos al desarrollo no debemos obviar estos problemas, hay que hablar de ellos con otros colegas y no rendirse en la batalla que nunca se ganará del todo para conseguir mejorar en el desarrollo de software.
No permitamos que el desarrollo agile se convierta en lo que ya se conoce como perverted agile = «pervagile». No erijamos totems a los que no podamos criticar. No hagamos una religión en torno a metodologías de desarrollo, porque eso nos hace estrechos de mente. Cambiemos lo que no funciona, aunque a otros eso mismo sí les funcione. Los proyectos de desarrollo son muy variados, muy diferentes y requieren sobre todo que las personas que participen sean críticas con ellas mismas y con el trabajo de los demás para poder mejorar. Siempre hay que mejorar.
Foto: Melanie Holtsman