Agilismo

on

Lo blando vence a lo duro;
Lo que carece de forma penetra lo impenetrable;
Hay valor en no actuar.
Enseñando a veces sin palabras,
Trabajando a veces sin acción,
Es algo que pocos pueden comprender.

Si deseamos entender los conceptos de las Metodologías Ágiles para del desarrollo de software dentro del campo de las Tecnologías de la Información y Comunicación (TICs), es imperativo entender los motivos de su nacimiento y éxito. Y para hacer eso debemos también entender que es lo que han venido a solucionar, en un mundo donde hasta hace pocos años dominaban las Metodologías Tradicionales de desarrollo de sistemas.

Bajo riesgo de sobresimplificarlo, me puedo atrever a decir que las metodologías tradicionales se pueden resumir en una palabra: rigidez. Generamente son una secuencia de pasos cuyos resultados en cada uno de los casos son el alimento del siguiente paso y se hacen solamente una vez (en teoría), en forma de cascada (de allí su nombre en inglés, Waterfall – Cascada). Es así como luego del Análisis, viene el Diseño, luego la Programación, las Pruebas, la Aceptación y el Despliegue. En cada uno de estos casos suelen existir sendos documentos (muchas veces irreales) que son la base de la siguiente etapa y aun cuando parecen guardar una lógica entre ellos, resultan finalmente impresisos al momento de captar las verdaderas necesidades y unas soluciones reales que realmente agreguen valor (principios Lean).

Esta forma de trabajar sencuencial parecería ser natural, lógica, precisa y obvia sino fuese por un sencillo motivo: todo este proceso es liderado por y para seres humanos. Los sistemas son creados para ser usados por personas comunes y corrientes: un contador, una secretaria, un vendedor, inclusive un Gerente de área, y aun cuando alguno de ellos pueda tener una idea medianamente clara del problema a nivel macro que desea solucionar con el sistema que ha solicitado, ninguno de ellos son expertos en informática y por ello carecen generalmente de una visión completa de lo que una solución informática podría darles, cuales son sus limitaciones y las bondades de las últimas tendencias en el ramo.

El resultado natural de todo esto es que muchas veces, más de las que nos gustaría aceptar, una persona o institución que requiere de una solución informática no tiene realmente claro que es lo que necesita y lo que es peor, suele delegar a los mismos departamentos de informática para que definan lo que se debe hacer, ignorando que aun cuando ellos son expertos en informática, no son expertos en el negocio ni en cómo alcanzar las metas estratégicas del mismo.

El efecto de este gap en un modelo secuencial como el presentado arriba (Análisis, Diseño, Programación, Pruebas, Aceptación y Despliegue) es que muchas cosas que se asumen al principio son incorrectas o imprecisas, y el efecto de este error es cargado en cascada desde el inicio al final, haciendo que mas de la mitad de proyectos de software fallen ya sea en alcance (características), costo o tiempo, puesto que los errores se identifican muy tarde en todo este ciclo de vida y no hay espacio para aprender, corregir y validar tempranamente esas creencias o definiciones erróneas.

Esto también significa que el software, en el mejor de los casos, se va creando por partes, separadas unas de otras, y quien pidió la solución solo podrá verla hasta el final. En la gran mayoría de los casos el resultado final no se acercará alo que tenia en mente o a la solución real a su necesidad puntual.

En las metodologías ágiles, sucede todo lo contrario, y bien podría yo resumirlas en una sencilla palabra: evolución. Cuando son adoptadas para implementar un proyecto de software, las metodologías ágiles en primera instancia están orientadas a entregar lo más pronto posible un producto que, aun cuando al principio no es perfecto, otorga y va otorgando incrementalmente una solución provisional y finalmente definitiva a la necesidad puntual del cliente. Es así como las primeras “soluciones” van sirviendo de base iterativamente para validar constantemente que  la dirección que está tomando el software efectivamente provee valor y se acerca paulatinamente a la mejor solución que se le puede dar al problema o la necesidad planteado y constantemente tambien validada y priorizada. En muchos casos inclusive alguna de las soluciones intermedias a las que se llega son aceptables y suficientes, de forma que los recursos que se ahorran pueden servir para atender otras necesidades.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s