En marzo de 2001 diecisiete críticos de los modelos de mejora del desarrollo de software basados en procesos se reunieron para tratar sobre técnicas y procesos para desarrollar software. En la reunión se acuñó el término “Métodos Ágiles” para definir a los métodos que estaban surgiendo como alternativa a las metodologías formales (CMMI, SPICE) a las que consideraban excesivamente “pesadas” y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas previas al desarrollo.

Los integrantes de la reunión resumieron los principios sobre los que se basan los métodos alternativos en cuatro postulados, lo que ha quedado denominado como Manifiesto Ágil.

El manifiesto ágil

Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:

• A los individuos y su interacción, por encima de los procesos y las herramientas.
• El software que funciona, por encima de la documentación exhaustiva.
• La colaboración con el cliente, por encima de la negociación contractual.
• La respuesta al cambio, por encima del seguimiento de un plan.

Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.

Valores del manifiesto ágil

Valorar más a los individuos y su interacción que a los procesos y las herramientas

Este es posiblemente el principio más importante del manifiesto. Por supuesto que los procesos ayudan al trabajo. Son una guía de operación. Las herramientas mejoran la eficiencia, pero sin personas con conocimiento técnico y actitud adecuada, no producen resultados.

Las empresas suelen predicar muy alto que sus empleados son lo más importante, pero la realidad es que en los años 90 la teoría de producción basada en procesos, la re-ingeniería de procesos ha dado a éstos más relevancia de la que pueden tener en tareas que deben gran parte de su valor al conocimiento y al talento de las personas que las realizan.

Los procesos deben ser una ayuda y un soporte para guiar el trabajo. Deben adaptarse a la organización, a los equipos y a las personas; y no al revés. La defensa a ultranza de los procesos lleva a postular que con ellos se pueden conseguir resultados extraordinarios con personas mediocres, y lo cierto es que este principio es peligroso cuando los trabajos necesitan creatividad e innovación.

Valorar más el software que funciona que la documentación exhaustiva

Poder ver anticipadamente como se comportan las funcionalidades que se esperan sobre prototipos o sobre partes ya elaboradas del sistema final ofrece un "feedback" muy estimulante y enriquecedor que genera ideas y posibilidades imposibles de concebir en un primer momento, y difícilmente se podrían incluir al redactar un documento de requisitos detallados antes de comenzar el proyecto.

El manifiesto no afirma que no hagan falta. Los documentos son soporte de documentación, permiten la transferencia del conocimiento, registran información histórica, y en muchas cuestiones legales o normativas son obligatorios, pero se resalta que son menos importantes que los productos que funcionan. Menos trascendentales para aportar valor al producto.

Los documentos no pueden sustituir, ni pueden ofrecer la riqueza y generación de valor que se logra con la comunicación directa entre las personas y a través de la interacción con los prototipos. Por eso, siempre que sea posible debe preferirse, y reducir al mínimo indispensable el uso de documentación, que genera trabajo que no aporta un valor directo al producto.

Si la organización y los equipos se comunican a través de documentos, además de perder la riqueza que da la interacción con el producto, se acaba derivando a emplear a los documentos como barricadas entre departamentos o entre personas.

Valorar más la colaboración con el cliente que la negociación contractual

Las prácticas ágiles están especialmente indicadas para productos difíciles de definir con detalle en el principio, o que si se definieran así tendrían al final menos valor que si se van enriqueciendo con retro-información continua durante el desarrollo. También para los casos en los que los requisitos van a ser muy inestables por la velocidad del entorno de negocio.

Para el desarrollo ágil el valor del resultado no es consecuencia de haber controlado una ejecución conforme a procesos, sino de haber sido implementado directamente sobre el producto. Un contrato no aporta valor al producto. Es una formalidad que establece líneas divisorias entre responsabilidades, que fija los referentes para posibles disputas contractuales entre cliente y proveedor.

En el desarrollo ágil el cliente es un miembro más del equipo, que se integra y colabora en el grupo de trabajo. Los modelos de contrato por obra no encajan.

Valorar más la respuesta al cambio que el seguimiento de un plan

Para un modelo de desarrollo que surge de entornos inestables, que tienen como factor inherente al cambio y la evolución rápida y continua, resulta mucho más valiosa la capacidad de respuesta que la de seguimiento y aseguramiento de planes pre-establecidos. Los principales valores de la gestión ágil son la anticipación y la adaptación; diferentes a los de la gestión de proyectos ortodoxa: planificación y control para evitar desviaciones sobre el plan.

El quinto valor ágil

Hace ya un tiempo se renovó la discusión sobre el profesionalismo en la programación, proponiendo un nuevo valor ágil:

• La destreza de las personas, por sobre la ejecución.
  

La mayoría de los equipos son capaces de ejecutar sus tareas, pero no les importa el cómo lo hacen. Las metodologías ágiles valoran la ejecución, pero valoran aún más a la calidad de dicha ejecución.

Este quinto valor apunta especialmente al código de los desarrollos, buscando asiduamente la calidad y evitando el código "basura" y desprolijo.

Hace ya mucho tiempo que se hace foco sobre el profesionalismo en el desarrollo, el buscar continuamente generar código de calidad (por ejemplo, Scrum hace énfasis en la "excelencia técnica" de las soluciones, a través de Definiciones de Terminado claras y completas). Sin embargo, en última instancia, este valor no hace referencia a procesos o herramientas, sino a los mismos desarrolladores, a su capacidad y preocupación por mejorar y crecer continuamente.

Y es que, justamente, el crecimiento personal es eso: un esfuerzo que tiene que poner cada persona para aprender y mejorar en lo que hace. Como profesionales de sistemas es nuestra propia responsabilidad el asegurar excelencia técnica en cada uno de nuestros trabajos. Debemos esforzarnos por buscar y aprender continuamente las mejoras prácticas, leer nuevos enfoques y cuestionar nuestros propios conocimientos continuamente.

Al igual que cada uno de los cuatro valores ágiles originales, este quinto valor es de pocas palabras y mucho significado.  Se centra completamente en el desarrollador y su propia responsabilidad de hacer las cosas mejor, siempre.