Innovar la Innovación
¿Has inventado algo alguna vez? Puede que creas que no, pero todos lo hacemos al aparcar: nos estamos inventando un movimiento de volante que acabe con el coche en su sitio. Tenemos una idea más o menos precisa de qué queremos, pero no estamos del todo seguro de la manera en la que ocurrirá.
Lo primero de lo que te habrás dado cuenta es de que si es en el mismo sitio que ayer, aparcar es más sencillo. Mi suegro es capaz de cuadrar su coche dentro de su garaje, pequeño y lleno de columnas, casi con los ojos cerrados. El truco para poder hacer eso es que lleva aparcando en ese sitio los últimos veinte años.
Pero aparcar en un sitio nuevo, sobre todo uno que esté muy justo, es todo un reto. Tenemos un procedimiento, unas sugerencias de cuando aprendimos a conducir, pero a la hora de la verdad, es muy poco mecánico. Lo más que podemos hacer es tirar, mirar, e ir corrigiendo.
Durante muchos, muchísimos años, el desarrollo de tecnología seguía un proceso similar al que sigue mi suegro para aparcar: estas son las cosas que sé hacer, así que vamos a hacerlas así. La gente con mayor experiencia estaba al mando, porque las cosas se hacían como se hacía antes. Así trabaja la NASA, por ejemplo: todo está calculado y planeado hasta el más mínimo detalle, y cada decisión está comprobada y ensayada milimétricamente. Y dirás, “claro, ¡están en el espacio!”. Y tendrás razón. Dado que primero planeamos, y luego caemos en la ejecución, y luego caemos en el testeo, el proceso evoluciona escalonadamente. Por eso se conoce como “Enfoque Cascada”.
En los años 80, 90, diversos programadores de renombre empezaron a darse cuenta de que este enfoque no era el ideal para atacar proyectos de software. Dos causas encontraron por las que el Enfoque Cascada fallaba en este caso particular: la primera, que muchas veces no sabían lo que estaban construyendo, más allá de una idea general; y la segunda, que cometer un error no era tan catastrófico al desarrollar un videojuego que al desarrollar el sistema que regula la Estación Espacial Internacional. En software, fallar no tiene un precio fijo: es más barato fallar durante el desarrollo, en cuanto a tiempo que se tarda en corregir, porque es cuando el programador puede hacer ajustes, mientras que cuando ya está todo terminado, un ajuste supone tener que volver a empezar toda la batería de comprobaciones.
El Enfoque Cascada no funcionaba con software, porque asumía que los errores costaban lo mismo al principio que al final, y que siempre costaban mucho. Pero lo cierto es que en software no es así. Hay muchas veces en las que no es fácil definir qué queremos del proyecto que tenemos entre manos: puede que sea “mejorar la experiencia del usuario”, sí, pero, ¿cómo lo hacemos?
Lo que me lleva de nuevo a buscar aparcamiento. Si no sabemos cómo vamos a llegar a nuestro objetivo con antelación, ¿qué podemos hacer?
Tirar, mirar, e ir corrigiendo. Estos programadores se reunieron en 2001 y publicaron el Manifiesto Ágil, donde anteponían la capacidad de responder a pequeños cambios frente a seguir un plan predefinido. Así, el software está en manos de los que lo crean, quienes están en condiciones de corregirlo con un coste menor.
Recuerda: ágil es la capacidad de moverse con soltura y reaccionar ante cambios. No tiene nada que ver con llegar antes a ningún sitio.