Ágil es una palabra de moda en el mundo del desarrollo de software si bien, esta metodología como tal, no viene diciendo nada nuevo.

Varios evangelistas y gurús se han alzado como portadores de esta “nueva” manera de construir software y diversas técnicas han surgido al rededor de este movimiento (con certificaciones y todo), afirmando ser la solución para todos los males.
En mi humilde opinión todo esto es (o debiera ser) mucho más simple.

Este es el primero de una serie de posts que voy a escribir a cerca de cómo entiendo la metodología ágil para el desarrollo de software.

Quiero dejar claro que no me considero ningún evangelista, ni ningún gurú, pero considero que puede resultar interesante y que cojones, me gusta hablar del tema

Todo este buzz de desarrollo ágil viene inspirado por este manifiesto:

• Valorar más a los individuos y su interacción que a los procesos y las herramientas
• Valorar más el software que funciona que la documentación exhaustiva
• Valorar más la colaboración con el cliente que la negociación contractual
• Valorar más la respuesta al cambio que el seguimiento de un plan

Lo cual fue tan revolucionario porque se da de lleno con las prácticas habituales en el desarrollo de software.

Recuerdo poco antes de salir de la universidad, cuando comencé a hacer prácticas para sacarme de encima esos créditos de libre configuración, que me llevé un severo desencanto en lo referente a mi futura profesión.
No había nada de planificación, todo se hacía deprisa y corriendo. A nosotros los becarios nos dejaban a nuestro libre albedrío, con poco más que un manual de actuación, unas pocas charlas sobre lo que necesitaban y una máquina para trabajar.
Ah!, y todo tenía que estar listo en 2 semanas.
No importaba como, no importaba la calidad y sobre todo no importaban las personas. Si te tenías que quedar haciendo horas extra (siendo becário!!!) pues te quedabas y punto.

A lo que voy es que generalmente, las llamadas “Empresas de Consultoría de Software”, en la mayoría de los casos no entendían el Software. Eran expertos en hacer dinero con el software (habitualmente subcontratando personal) dando lugar al llamado “Mercado de Carne“, en donde no importa lo que hagas, ni si estás bien o no. Lo único que importa es la diferencia entre:

a) El dinero en el que podamos venderte
y
b) El dinero que te damos a ti.

Si a - b es lo suficientemente lucrativo, entonces te contrataban. Si no entonces es que no habías pasado las pruebas psicotécnicas y demás…

Podría contar mil historias relacionadas con el mercado de carne madrileño, pero no viene al cuento.

Lo importante es que la llamada “revolución ágil” hacía una llamada al cambio.

Las personas son más importantes que los procesos y las herramientas.

Hazle entender esto a cualquier jefe de proyecto de la consultora Fulanez…

Ágil significa que un equipo de desarrollo de software, es el principal activo y como tal, las personas que conforman dicho equipo son lo primero. Todo lo demás viene a consecuencia de dichas personas. Y eso creo que nunca será suficientemente matizado:

Los programadores programan!

Si tu compañía vende “código”, ya sea en forma de servicios o de productos o de lo que sea… cuida de la gente que genera ese código.
Tiene sentido no?

Como ya escribí anteriormente, es difícil enseñarle trucos nuevos a un perro viejo, y es que como se suele decir “bad habits die hard”

En grandes compañías de software hay toda una serie de jerarquías, estándares y procedimientos establecidos que, en mi opinión, sólo sirven para mantener las cosas a raya.

Si nos abstraemos un poco y nos enfocamos en lo que es la estructura a nivel de corporación, es difícil percibir la diferencia entre una compañía que genera sofware y otra que vende lavadoras.
Y esto no sería grave si el software fuera como una lavadora, pero afortunadamente no lo es.

Según lo veo yo, el software es algo vivo. Algo que uno crea pero que, llegado el momento, cobra vida propia y comienza a demandar cosas en las que jamás habríamos pensado inicialmente. Y lo genial del Software es que podemos proveer soporte para esas necesidades de manera relativamente sencilla!
Una lavadora podrá tener más o menos programas, pero no dejará de ser una lavadora.

Esta diferencia fundamental radica que el software es, por así decirlo, un “producto” que reside más en el plano de las ideas, que en el plano físico, y tratar de controlar este tipo de productos usando viejas metodologías bien conocidas en otras industrias, en mi humilde opinión es un craso error.

Os diré qué es el infierno para mi:

• Programar algo usando especificaciones escritas en piedra.
• No poder mostrar tu trabajo al cliente a medida que lo desarrollas para saber si es eso lo que quiere.
• Después de haber trabajado en algo durante meses, que el jefe de turno me diga que hay que tomar otra alternativa.
• No poder avanzar en un proyecto porque “los jefes y el cliente” se encuentran discutiendo re-negociando los términos del contrato.
• No poder programar algo chulo y que sé que le va a proporcionar valor agregado al cliente, porque no se encuentra en el documento de especificación.
• Asistir a aburridas reuniones en las que los “los jefes y el cliente” se la pasan discutiendo quién tiene la culpa del retraso en el proyecto.
• Que el manager de turno nos diga que tenemos que trabajar más horas porque “vamos” con retraso.
• Tener que llevar traje y corbata al trabajo

Si alguno de vosotros ha trabajado en un proyecto de este estilo seguro que entiende a lo que me refiero, los que no… no importa como trate de explicarlo, nunca podré llegar a expresar con palabras el estrés y sobre todo la frustración que eso genera.

Por qué uso una metodología ágil?

• Puedo participar en el diseño de manera directa, dando mi opinión y modelando las tareas que van a terminar dando forma al proyecto.
• No más Proveedores vs Clientes. Prefiero Proveedores + Clientes, mucho mejor.
• Puedo enseñar periódicamente lo que estoy haciendo al cliente, de manera que él puede decidir si vamos por el buen camino o no, y sobre todo, puede inspirarse y darse cuenta de lo que realmente quiere.
• Si la cosa no funciona, si hemos escogido un camino que resulta no ser el bueno, es mejor caer cuanto antes (el principio “fail fast”). Si lo que estoy haciendo no es lo que el cliente quiere, prefiero haber gastado una semana a varios meses de trabajo.
• Prefiero pactar un número de iteraciones con el cliente, que un contrato escrito en piedra y lleno de cláusulas. Si mi trabajo gusta a mi cliente, y si ve el avance en el proyecto, acordamos más iteraciones. Si no, es mejor buscar otro proyecto u otro cliente, que establecer una relación de “te odio pero te necesito”.
• Puedo colaborar con un cliente ofreciéndole ideas y opciones en las que él no había pensado y enseñárselas en un pequeño demo. Si le sirve y si le gusta, podemos pasar esas ideas a la lista de cosas que hacer en sucesivas iteraciones.
• Mi cliente puede usar su producto, aquello por lo que está pagando, desde el primer momento! Y creo que esto, desde el punto de vista de alguien que está invirtiendo un montón de dinero en algo es fundamental.
  Ofrecer la posibilidad de “jugar” con el producto a mi cliente desde el final de la primera iteración y desde ese momento recibir su feedback, es algo impagable.

El desarrollo ágil ofrece diversas técnicas para llevar a cabo estas y muchas otras prácticas, generando unos resultados bastante menos estresantes, menos frustrantes y sobre todo más divertidos y con el tiempo iré contándoos las que yo uso para trabajar.