Conclusiones. El Manifiesto Ágil: el documento que cambió el modo de desarrollar software

Aunque la mayoría de las empresas y los equipos desarrolladores de software siempre han utilizado los métodos tradicionales u ortodoxos para crear sus sistemas, también es verdad que es ya un número considerable el de empresas que han implementado, aunque sea poco a poco y sólo en ciertos aspectos, los Métodos Ágiles: el 50% considera que más de la mitad de sus procesos se realizan utilizando MAs.

Y es que tales métodos ofrecen un gran número de ventajas sobre los métodos ortodoxos. Tal como se señala en el Manifiesto Ágil, se privilegia a los individuos y a las interacciones sobre los procesos y herramientas. Lo humano siempre se pone en frente de lo administrativo o material, pues el humano es quien decide lo que se debe realizar, y no un documento. Con ello, se pone énfasis en lo que el cliente y usuario quiere, y no en lo que dice un papel firmado.

Otro punto que le da cierta ventaja sobre los métodos tradicionales es que su principal medida de progreso es el software funcionando, y no la cantidad de documentación, que en muchos casos puede estar correcta; pero eso al cliente no le dice nada de cómo va su proyecto. No sirve de nada que existan cientos de hojas que describan las fases de análisis y diseño del sistema si éste aún no se ha codificado; del mismo modo, si existe un programa que funcione a la perfección, al cliente no le importará que no esté bien documentado (a menos que quiera brindarle mantenimiento o modificarlo, claro).

Una ventaja más es que se privilegia la colaboración con el cliente sobre negociaciones y contratos. Así, en un proceso cualquiera, los grupos de trabajo siempre estarán en constante comunicación con el cliente, al grado de que éste está presente mientras los desarrolladores van programando; lo cual es muy diferente a comprometerse a trabajar mediante contratos, aunque nunca se conozca en persona al cliente final. De este modo, cualquier duda o aclaración por parte de los desarrolladores es satisfecha in situ por el cliente; duda que podría no estar estipulada claramente en un contrato.

La última ventaja, y una de las mejores, es que siempre se tiene una respuesta ante el cambio, en lugar de tener que seguir un plan. Los métodos ortodoxos no toleran con tanta facilidad las modificaciones: es casi fatal encontrar un error de requerimientos cuando se está finalizando ya la fase de pruebas, por ejemplo. En cambio, con un Método Ágil, se pueden estar cometiendo esta clase de errores y regresar a fases anteriores, pues se sigue un modelo iterativo; aunado al hecho de que es menos probable, pues el cliente está presente mientras se está programando.

Por todo lo expuesto anteriormente, creo que es mejor utilizar MAs si se trata de proyectos particulares, cortos y sencillos, pues significaría un ahorro considerable de tiempo y recursos, tanto humanos como económicos y materiales; y dejaría los métodos tradicionales u ortodoxos para sistemas de gobierno, bancarios, hospitalarios, o aquellos cuyo funcionamiento es crítico para cierto sector de la sociedad.

Bibliografía

• Cunningham, Ward, et al. (2001). Manifiesto por el desarrollo ágil de software. Michigan City, Estados Unidos. Recuperado de http://agilemanifesto.org/iso/es/manifesto.html el 18 de febrero de 2018.
• Reynoso, Carlos. (2004). Métodos Heterodoxos en Desarrollo de Software. Buenos Aires, Argentina. Recuperado de http://carlosreynoso.com.ar/archivos/arquitectura/Metodos-Agiles.PDF el 18 de febrero de 2018.
• Scrum Manager. (2014). El Manifiesto Ágil. Recuperado de https://www.scrummanager.net/bok/index.php?title=El_manifiesto_ágil el 18 de febrero de 2018.
• Sutherland, Jeff. (2013). Principios y valores de Agile. Recuperado de https://msdn.microsoft.com/es-es/library/dd997578(v=vs.120).aspx el 18 de febrero de 2018.