El manifiesto Agile, ¿de que va?.

Ser ágil es un requerimiento para todo programador en la actualidad, gran cantidad de las ofertas de trabajo que se publican exigen “metodologías ágiles” como parte de los requisitos de contratación. No todo lo que se nombra ágil lo es. La mayor parte de los programadores ágiles en realidad son programadores informales, Agile no trata de entregar rápido, tampoco de que pocos programadores hagan el trabajo de muchos, y  definitivamente ser ágil no es programar sin diseñar, ni analizar. Voy a darle una revisión al manifiesto original.

El movimiento Agile surgió como una protesta al modelo actual de construcción de  software (allá por los 2000’s). En esos tiempos el modelo de cascada dominaba la construcción de sistemas. Largos tiempos de análisis y desarrollo que con frecuencia llegaban a un producto que no solucionaba las problemáticas de los clientes. Hay que ser cuidadosos en lo que construimos como programadores, es un hecho. Pero tampoco hay que olvidar el factor humano, las personas que construyen el software y las que usaran el software. Agile busca conciliar estas dos partes. Opinare acerca de los cuatro puntos principales:

Individuos e interacciones sobre procesos y herramientas.

Toda empresa requiere de procesos claros y definidos, estos deben  de servir como lubricante para que la organización funcione, en ningún caso deben volverse un obstáculo a rodear para poder moverse en la empresa. Los procesos deben de seguirse siempre que se pueda, pero no deben ser inflexibles. Un buen proceso se adapta a los individuos y sus necesidades, no al revés.

Software funcionando sobre documentación extensiva.

En la era pre Agile, la construcción del sistema comenzaba una vez que el diseño había concluido. Esto creaba la problemática de no saber si la solución a construir resolvía las necesidades del usuario. Tener una pieza de software con un funcionamiento mínimo ayuda a corregir errores en el diseño. Esto no quiere decir que la documentación y el diseño sean malvados. Sobre documentar o sobre diseñar esta mal, es un hecho, pero no documentar o no dedicar el tiempo al diseño es aun peor (una situación bastante común en la actualidad). Es necesario un punto intermedio.

Colaboración con el cliente sobre negociación contractual.

Como programadores somos facilitadores del trabajo de otras personas, estas usan nuestras herramientas para hacerse la vida mas fácil. Hay que tener confianza con el cliente para poderle ofrecer el producto correcto. Pero tampoco quiere decir que omitas el dejar constancia mediante acuerdos escritos. No debes escudarte en un contrato para no solucionar la problemática del usuario pero tampoco debes omitir la formalidad mínima al momento de llegar a acuerdos.

Respuesta al cambio sobre seguir un plan.

Es imposible construir software preparado para el cambio solo puedes construir software adaptable al cambio. La viabilidad de una aplicación en estos tiempos significa que tan rápido y que tan bien esta se adapta a las necesidades de sus usuarios. Seguir un plan ciegamente al momento de construir la aplicación esta mal, la mayoría de los proyectos actuales tienen un  porcentaje alto  de lagunas de conocimiento (no se conoce del todo bien la problemática, pero hay que comenzar a construir). Si no sabes exactamente que construyes habrá desperdicio, necesitas mecanismos que permitan amortizar y minimizar el desperdicio, osea responder ante el cambio a tiempo, tomar decisiones correctivas y preventivas cuando sea necesario.

Conclusiones.

Agile busco en su tiempo romper con la rigidez y burocracia al momento de construir aplicaciones, desgraciadamente de un extremo muchos programadores se fueron para el lado opuesto, de “mucho análisis y formalidad” se termino en “no análisis ni formalidad”. Ninguna de estas dos posiciones es sana, es necesario tener un punto medio, y Agile si se entiende correctamente es este punto intermedio.

  Autor imagen: Dushan Hanuska

Gustavo Sánchez