Toma de decisiones en un proceso de Desarrollo Ágil: pensar en el futuro.

Luego de 8 años de experiencia en desarrollo de software con metodología ágil, hay ideas que empiezan a cuajar. En un proyecto de desarrollo de software es común toparse con decisiones que tienen que ver con agregar funcionalidad al código “por si más adelante se necesita” y hoy en día en Platanus no nos demoramos mucho en saber qué contestar.

El tema va más o menos así: Mientras discutimos de incluir en el software una funcionalidad X, alguien se imagina el futuro del producto y comenta que, tal vez, más tarde el cliente pueda necesitar una funcionalidad similar Y. Al evaluar la idea los programadores opinan que es sencillo, y comentan — “no veo problema con programar esto de manera que el día de mañana el software también pueda hacer Y ” — con bastante calma. El cliente, o el que cumple el rol de dueño del producto, no cree que va a necesitar Y por ahora, pero no descarta que en el futuro le pueda servir. Ok, dejemos entonces “la puerta abierta”, dicen todos. La decisión se toma como si fuera algo muy barato.

Lo que queda escondido es que la “puerta” que acaban de abrir aumenta considerablemente los costos y es una puerta muy difícil de cerrar.

En primer lugar, aumenta los costos en términos de horas de programación, porque al agregar la característica, por pequeña que sea, nos estamos comprometiendo implícitamente a arrastrarla hacia el futuro. Hay que tener bien claro que es la complejidad lo que hace que el desarrollo vaya más lento, y aunque lo que se decidió implementar en su momento sea sencillo, lo que hicimos fue agregar un poco más de peso a nuestra carga. De alguna manera, hacer software es como hacer una novela, y agregar un personaje en una escena puede parecer sencillo, pero tendrás que considerar su existencia en la construcción de escenas posteriores. Las distintas características que agregamos “por si acaso” terminan llenando nuestro código de complejidad y hacen que avanzar sin romper nada sea lento y costoso.

Pero lo de arriba no es lo peor. La decisión resulta costosa para el avance de las reuniones de definición del software, porque, tal vez sin querer, le entregamos una señal al equipo de que pensar en estas ideas futuras es importante. El tomar la decisión de implementar algo al alcance de la mano “por si en el futuro se necesita”, le señala a todos que debieran estar alerta a lo que podría necesitarse, que debieran pensar si están frente a una oportunidad de dejar una nueva puerta abierta. Al tomar esta decisión, acabamos de aumentar el número de decisiones a tomar en el camino y tomar decisiones es caro. El problema más grave es que, sugerir ideas de lo que podría necesitarse en el futuro es muchas veces más fácil que pensar en el presente, porque este tipo de ideas no se ponen a prueba inmediatamente, son ideas más defendibles con “quién sabe si el día de mañana…”, pero igualmente gastan energía creativa y, lo que es peor, desvían del verdadero objetivo de un buen desarrollo, que es descubrir y resolver los problemas que tenemos hoy.

Por otro lado, la puerta es difícil de cerrar porque todos buscamos ser consistentes con nosotros mismos: si en la primeras reuniones decidimos dejar algo “por si se necesitaba más adelante”; ¿Por qué otra idea similar no tiene cabida?, nos obligamos entonces a seguir pensando cada decisión nacida de la “futurología”, dedicarle tiempo y explicar razones para sí y para no.

¿Y qué se puede hacer?

Creo que la razón por la que caemos en la falacia de “dejar la puerta abierta a un cambio” es porque comprendemos el mundo desde lo físico. En el mundo físico hay que ser precavidos, no pensar en el futuro trae costos muy altos. Si vamos un fin de semana a la playa y al armar la maleta no pensamos en que tenemos la idea de salir a trotar, luego simplemente no podremos “modificar un poco los zapatos” y salir trotando. Si con el arquitecto no pensamos en un baño de visitas, agregarlo después podría requerir demoler un pedazo de la casa.

Es importante entender que el proceso de desarrollo de software no es asimilable al proceso de construcción de una casa. El código se puede cambiar y mucho. No es buena idea intentar adivinar lo que se necesitará el día de mañana, porque el costo del desarrollo de software está relacionado al manejo de la complejidad, y una vez que implementemos algunas cosas, vamos a terminar arrastrando complejidad en el tiempo que muy probablemente no será necesaria después de todo.

Al contrario de lo que muchos piensan, lo que permite que un código se adapte a las distintas situaciones a un costo bajo no es que se hayan pensado las posibilidades con anticipación, sino que el código sea sencillo y entendible.

A la hora de tomar decisiones de qué implementar, el presente es más importante, y rara vez conviene tomar una decisión a partir de un futuro incierto, dado los altísimos costos que implica. Si descartamos las ideas nacidas de la futurología desde el día uno, el código permanecerá abarcable, ahorraremos tiempo en decisiones, mantendremos una buena velocidad de avance y podremos implementar en su momento lo que se haga prioritario.