El manifiesto ágil fue fruto de una reunión que se mantuvo en Salt Lake City en marzo de 2001. Diecisiete críticos de los modelos de mejora del desarrollo del software basado en procesos, convocados por Kent Beck, padre del Xtreme Programming, escribieron el siguiente manifiesto:
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.
Entre estas diecisiete personas estaban: Kent Beck, uno de los tres creadores del Xtreme Programming; Alistair Cockburn, padre de los Crystal Methods; Martin Fowler, gran defensor de la Refactorización; Ward Cunningham, estudioso de los patrones y antipatrones de diseño del software y otro de los creadores de Xtreme Programming; Ron Jeffries, otro de los creadores del Xtreme Programming; Jeff Sutherland, gran promotor de Scrum.
Individuos y su Interacción sobre Procesos y Herramientas
No hay que malentender estas palabras tomándolas en su sentido más radical. La expresión de esta frase se refiere que se valora más la comunicación humana, las reuniones y lo que una persona pueda transmitir a otra, que las herramientas.
Así mismo, se considera más importante la valía de la persona, del programador y del diseñador, que los procesos establecidos en sí.
Software que funciona sobre Documentación exhaustiva
Es lógico que, si tengo un software que no funciona como quiero, da igual lo grande que sea la documentación. Es más útil un programa intuitivo, que hace única y exclusivamente lo necesario y tiene una calidad interna alta (código limpio, claro y con comentario concisos) que un software enrevesado que necesita un manual de no menos de 100 páginas para poder entenderlo.
Colaboración con Cliente sobre Negociación Contractual
La firma de un contrato ata a ambas partes a realizar un cierto desarrollo en un determinado tiempo con un gasto prefijado, solo que estos valores son solo estimados.
El contrato debe de existir, pero hay que colaborar con el cliente en realizarlo de forma más flexible, es decir, que los desarrollos sean de períodos cortos y vayan dando valor al cliente, de modo que, con esas cortas entregas, el cliente pueda decidir el curso a seguir entre iteraciones con sus peticiones y los desarrolladores realizar solo el esfuerzo necesario.
Respuesta al cambio sobre Seguimiento de un plan
Como comentaba, salvo para administraciones públicas, los desarrollos que se realizan a vista de un año o más, no suelen aportar valor al cliente hasta terminado ese período de espera. Una empresa que necesita un software, normalmente no puede dar unos requisitos fijos que, a lo largo de los siguientes meses, no cambien debido a un cambio externo o una necesidad de la propia empresa.
Por este motivo, la respuesta al cambio es vital y muy necesaria y, como indicaba el punto anterior, el hecho de poder hacer iteraciones y dar valor al cliente cada poco tiempo es lo que se persigue con el desarrollo ágil.
Conclusión
Esto se produjo en marzo de 2001, desde entonces ninguno de los diecisiete, más otros igualmente grandes, como Mary Poppendieck o Mike Cohn, no han parado de aportar bibliografía sobre el tema y métodos o matizaciones de los métodos ya existentes.
En este sentido, se puede decir que el desarrollo del software es un terreno vivo, donde no paran de descubrirse y crearse métodos y técnicas, para poder abarcar de una forma más exacta el desarrollo de un proyecto de software.
