Joel Cuevas

Just barely good enough

A mí me tocó vivir el pináculo mediático del desarrollo de software con metodologías ágiles. Y nunca las comprendí. Es más, durante casi diez años me debatí entre si debía alinearme y adoptar alguna de ellas o, ya que las cosas no me habían resultado tan mal, simplemente continuar como siempre y ya.

La realidad es que este debate fue así de largo porque nunca me tomé el tiempo para profundizar, y me refiero a en verdad profundizar, en cualquiera de estas metodologías. Tardaba más en decidir comenzar a aprender alguna que en llegar al punto en donde me volvía a decir que, al igual que las metodologías tradicionales, estaban llenas de cosas absurdas e innecesarias o que en el otro extremo sus principios eran tan flexibles que era demasiado fácil faltar a ellos.

Y lo sigo creyendo. Pero vamos, nunca he sido un sujeto de metodologías así que no hagas mucho caso a lo anterior.

Específicamente uno de los principios que la mayoría de las metodologías ágiles adoptan ya sea bajo un nombre u otro es el concepto de hacer únicamente lo necesario —"just barely good enough", le dicen—, pero cuando se es un sujeto un tanto obsesivo-compulsivo como yo, aceptar hacer únicamente lo necesario puede resultar un poquito conflictivo.

Yo concebí el desarrollo de software como un arte perdido, en el cual cada elemento debía de ser sublime, exquisito, inefable, parte de una maquinaria perfectamente engrasada... Hasta que la vida y los golpes de realidad (y los usuarios finales) lograron que me replanteara todo.

Más seguido de lo que deseaba me descubría rehaciendo mis obras de arte, borrándole al cuadro la firma que suponía el trabajo terminado a causa de un nuevo requerimiento, casi siempre absurdo pero inapelable, de parte del usuario final. Después de todo el software no era ni mío ni para mí, era para ellos.

Lo que sucedió fue que, después de interminables rabietas y muchos autocomplacientes "no me vuelvo a esforzar", decidí que era momento de reconsiderar aquello de hacer lo mínimo que se necesitara para mover las cadenas. Y lo pensé y lo pensé y leí y leí hasta que me convencí de que al final no era tan mala idea.

Descubrí que todos esos años mi problema había radicado en la connotación negativa que yo le daba a las palabras "únicamente lo necesario". Me hacían sentir un tipo mediano y que eran solo un pretexto para elegir el camino fácil y trabajar menos. Sin embargo, un día, una sutil variación en mi actitud al leerlas otra vez hizo que todo fuera muy diferente.

Hacer únicamente lo necesario no quería decir hacer las cosas mal, quería decir que debía de aprender a identificar y a balancear la cantidad de esfuerzo que tenía que dedicar a una tarea de tal forma que esa tarea cumpliera con lo que se requería obtener. Es decir, debía minimizar el esfuerzo y maximizar el resultado... ¡duh!

Claro que entenderlo fue más fácil que aplicarlo.

Mis problemas pasaron de tener que rehacer cosas a preguntarme permanentemente qué era lo que estaría dejando de lado y que iríamos a necesitar después. Ya no me preocupaba tanto que el usuario final pidiera modificaciones, sino que se convenciera de que el software era insuficiente o completamente inutil. Y volvía ese molesto dolor de estómago y las ganas de vomitar.

Y volví a pensar y a pensar y a leer y a leer y, de nuevo, lo que necesité fue otro cambio de actitud que resultó en un mantra que me recitaba más o menos así: con la información que tienes haz algo que satisfaga lo que se te solicitó, muestralo al usuario y pregúntale qué le parece; enjuaga y repite. Release early, release often, le llaman también.

Básicamente en lo que tuve que trabajar fue en perder el miedo a escuchar al usuario. Después de todo, si el usuario va a opinar que está mal, es mejor que lo opine antes de haber invertido demasiado esfuerzo en terminar eso que va a estar mal. Escuchar al usuario, además, saca a la luz un montón de información útil que permite realizar la siguiente iteración del desarrollo mucho más enfocada en los resultados que se esperan obtener, lo que se traduce directamente en menos trabajo y mayor satisfacción, que justo era el objetivo de la primera meditación. Y, ya por decirlo de paso, si las iteraciones son bien ejecutadas, encontrar el punto de suficiencia de lo necesario para tu audiencia se vuelve bastante evidente en el transcurso de la evolución del trabajo.

¿Y a poco no suena mucho mejor?

Los dos principios que mencioné —"just barely good enough" y "release early, release often"— van estrechamente de la mano y son el fundamento de las metodologías con más popularidad últimamente. Podríamos decir que es algo así como el segundo aire de las metodologías ágiles, que ahora en general están más enfocadas en dar resultados iterativos y mejorables que en establecer procesos que seudo-aseguren la calidad del resultado prometido a futuro.

Y aunque después de todo aun sigo sin adoptar completamente ninguna metodología, en lo personal sí le tengo especial afecto a varios de los conceptos de dos en particular: Lean software development y Kanban, que sin intención de polarizar ninguna discusión, si me lo preguntas a mí, te diré que en definitiva ambas son lecturas obligadas si pretendes desarrollar buen software en el siglo XXI.

En conclusión, recuerda entonces que la base de un buen proceso de desarrollo, independientemente del método que prefieras utilizar, está en hablar con tus usuarios. Habla SIEMPRE con tus usuarios.

Ir a la página principal