Manifiesto ágil. Un manifiesto a favor del desarrollo de software I
Soy un converso, quizá por eso mi postura es más radical. Estoy cansado de participar en desarrollos con metodologías clásicas que no terminan de tener éxito (no tener éxito no es lo mismo que fracasar, aunque bastante de ellos sí que se podrían considerar un fracaso), podría ser algo que solo me pasara a mi, pero no es así, sucede con frecuencia y seguro que todos nosotros conocemos o hemos vivido proyectos con estos resultados.
La crisis del software sigue existiendo y existirá mientras no cambien muchas cosas. Los que nos dedicamos a esto tenemos muchos esquemas mentales que cambiar, son años haciendo los desarrollos de una determinada manera y también de formación centrada exclusivamente en metodologías clásicas.
El éxito o el fracaso de un proyecto no es exclusivo de las metodologías, pero sí predisponen a obtener unos resultados u otros.
Los proyectos de desarrollo de software tienen una naturaleza cambiante, es complicado acertar en todo: obtener los requisitos del usuario, la mecánica de comunicación entre usuario y sistema, la interfaz, etc… y lo es porque ni los usuarios tienen claro lo que quieren hasta que ven funcionalidades implementadas y también porque no siempre se interpreta adecuadamente por parte de los analistas o técnicos del proyecto las necesidades de los usuarios.
Metodologías de carácter eminentemente predictivo como las clásicas no son acordes con la naturaleza del desarrollo de software, habrá excepciones porque no existen llaves maestras que sirvan para todo.
Las metodologías ágiles, son adaptativas, son iterativas, incrementales. Sin embargo por encima de ellas está la propia filosofía del desarrollo ágil, realmente es la esencia, una vez entendida es mucho más trascendente que cualquier forma de llevarla a cabo.
Teniendo claro qué significa ser ágil, hasta su aplicación en metodologías clásicas las hace más flexibles.
En el año 2001 se reunieron en Salt Lake City diecisiete prestigiosos expertos en gestión de proyectos, ingeniería y desarrollo de software. La convocatoria la realizó Kent Beck, padre de la programación extrema.
En la reunión analizaron las problemáticas existentes en el desarrollo de software y en la necesidad de cambiar la forma en que se enfocaban y hacían los proyectos de desarrollo de software, lo cual dio lugar a unas conclusiones, recogidas en el manifiesto ágil.
En mi opinión, se trata de un manifiesto a favor del desarrollo de software, en su defensa, en la defensa de los que nos dedicamos a esta profesión ya que la mejor forma de dignificarnos es conseguir que la mayor parte de nuestros proyectos tengan éxito. Hay que romper con lo que no funciona, si el desarrollo de software es de una manera, actuar de otra es ir contra natura.
Los firmantes del manifiesto fueron las siguientes personas: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas.
El contenido del manifiesto es el siguiente, primero pongo el original en inglés y a continuación su traducción:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more.”
“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.”
En el próximo artículo sobre esta materia comenzaré a exponer mi punto de vista sobre cada principio de los que componen el manifiesto.
Pingback: Manifiesto ágil. Un manifiesto a favor del desarrollo de software II « Jummp
Pingback: Desarrollo de software. Context-Driven school of software testing « Jummp
Pingback: PM Declaration of Interdependence « Jummp
Pingback: Brian Marick y la complejidad que supone la naturaleza cambiante del desarrollo de software « Jummp
Pingback: Alistair Cockburn. Metodologías Crystal (Crystal Methodologies) I « Jummp
Pingback: Desarrollo de software. Testing ágil « Jummp
Pingback: Desarrollo de software. No usar una metodología de desarrollo no es ágil « Jummp
Pingback: Desarrollo de software. Martin Fowler y la importancia de una buen diseño y codificación « Jummp
Pingback: Desarrollo de software. Martin Fowler. Un buen diseño pasa por reducir o eliminar el código duplicado « Jummp
Pingback: Desarrollo de software. Desde la simplicidad « Jummp
Pingback: Martin Fowler. Programadores y buenos programadores « Jummp
Pingback: Martin Fowler. Sentir el código « Jummp
Pingback: Desarrollo de software. Bob Martin. Artesanía sobre ejecución. « Jummp
Pingback: Desarrollo de software. Beta perpetua « Jummp
Pingback: Desarrollo de software. Cowboy coding vs Desarrollos ágiles « Jummp
Pingback: Crisis del software. Crisis de confianza « Jummp
Pingback: Desarrollo de software. Metodología de desarrollo guiado por las pruebas (TDD: Test-driven Development) « Jummp
Pingback: Desarrollo de software. Historias de usuario « Jummp
Pingback: Desarrollo de software. Metodologías ágiles. Replanificar la fecha de entrega o cumplir con la misma « Jummp
Pingback: Desarrollo de software. Los principios y metodologías ágiles vs incumplientos de plazos y presupuestos « Jummp
Pingback: RUP (Rational Unified Process) vs Desarrollos ágiles « Jummp
Pingback: Desarrollo de software. Técnica de estimación Planning Poker « Jummp
Pingback: Desarrollo de software. Análisis de falsa funcionalidad « Jummp
Pingback: Desarrollo de software. Sin miedo a proponer e implementar soluciones « Jummp
Pingback: Desarrollo de software. Cuando el presupuesto es el que es « Jummp
Pingback: Desarrollo de software. Jim Highsmith. La necesidad de reducir el tiempo necesario para el paso a producción I « Jummp
Pingback: Desarrollo de software. Integración continua « Jummp
Pingback: Desarrollo de software. Jim Highsmith. La necesidad de reducir el tiempo necesario para el paso a producción II « Jummp
Pingback: La imagen del desarrollo de software « Jummp
Pingback: Desarrollo de software. El analista funcional y el analista orgánico « Jummp
Pingback: Desarrollo de software. Complejidad vs Adaptabilidad « Jummp
Pingback: Desarrollo de software. Rebecca Parsons. El rendimiento « Jummp
Pingback: Desarrollo de software. El capital humano debe dejar de ser un concepto vacío « Jummp
Pingback: Desarrollo de software. Death March Project. ¿Y si la negociación falla o no es suficiente? « Jummp
Pingback: Desarrollo de software. Comunicación y saber escuchar « Jummp
Pingback: Desarrollo de software. Elisabeth Hendrickson. Éxitos y fracasos en la automatización del testing « Jummp
Pingback: Desarrollo de software. David Lorge Parnas. Feedback, adaptación y satisfacción del usuario. « Jummp
Pingback: Desarrollo de software. Que los usuarios se impliquen, algo deseable y demasiadas veces imposible « Jummp
Pingback: Desarrollo de software. Planificación. Conservar la ventaja « Jummp
Pingback: Desarrollo de software. Pruebas de aceptación « Jummp
Pingback: Desarrollo de software. Larry Bernstein. Prototipado, tiempo de desarrollo, coste « Jummp
Pingback: Desarrollo de software. Pruebas, testing, cuanto antes mejor « Jummp
Pingback: Desarrollo de software. Exceso de frentes abiertos « Jummp
Pingback: Desarrollo de software. Proyectos y errores « Jummp
Pingback: Desarrollo de software. Gerald Marvin Weinberg. Documentación y programación « Jummp
Pingback: Desarrollo de software. Michael Anthony Jackson. Software, percepción, realidad « Jummp
Pingback: Desarrollo de software. Usuarios, producto, evolución « Jummp
Pingback: Desarrollo de software. El componente estructural de las metodologías « Jummp
Pingback: Desarrollo de software. El inicio del proyecto no es la programación « Jummp
Pingback: Desarrollo de software. Team building « Jummp
Pingback: Desarrollo de software. Barry Boehm. Detección temprana de errores « Jummp
Pingback: Desarrollo de software. Barry Boehm. Metodologías ágiles, equipo de proyecto, gestión del conocimiento « Jummp
Pingback: Desarrollo de software. La tendencia del ciclo de vida en cascada a convertirse a iterativo incremental « Jummp
Pingback: Desarrollo de software. Barry Boehm. Ingeniería del software, preocupaciones humanas « Jummp
Pingback: Desarrollo de software. Ciclo de vida en cascada vs Metodologías ágiles « Jummp
Pingback: Desarrollo de software. Crisis del software, ¿superada?, no « Jummp
Pingback: Desarrollo de software. La esencia del desarrollo iterativo incremental « Jummp
Pingback: Desarrollo de software. Jim Highsmith. Metodologías ágiles, anticipación, adaptación « Jummp
Pingback: Desarrollo de software. Barry Boehm. Agilidad, incertidumbre « Jummp
Pingback: Desarrollo de software. Scott L. Bain. La inutilidad de la lucha contra el cambio « Jummp
Pingback: Desarrollo de software. Martin Fowler. Jim Highsmith. Adaptación, flexibilidad al cambio, ventaja competitiva « Jummp
Pingback: Desarrollo de software. La incertidumbre, la deuda técnica y las buenas prácticas « Jummp
Pingback: Desarrollo de software. Mantenimiento, proceso poco formal, problema « Jummp
Pingback: Manifiesto ágil. Un manifiesto a favor del desarrollo de software V « Jummp
Pingback: Manifiesto ágil. Un manifiesto a favor del desarrollo de software VI « Jummp
Pingback: Desarrollo de software. Peopleware « Jummp
Pingback: Manifiesto ágil. Un manifiesto a favor del desarrollo de software VIII « Jummp
Pingback: Desarrollo de software. Cuando las personas no pueden suplir los procesos « Jummp
Pingback: Desarrollo de software. Plan de sistemas de información ágil « Jummp
Pingback: Desarrollo de software. La mejora contínua y el feedback « Jummp
Pingback: Desarrollo de software. Cuando nos quedamos solos en el proyecto « Jummp
Pingback: Desarrollo de software. Tom DeMarco. Timothy R. Lister. La regularidad en la producción « Jummp
Pingback: Desarrollo de software. Antipatrón. Organización de cuerda de violín « Jummp
Pingback: Desarrollo de software. Iterar con sentido « Jummp
Pingback: Desarrollo de software. Ser ágil es cuestión de actitud, no de metodología « Jummp
Pingback: Desarrollo de software. Ser ágil es cuestión de actitud, no de metodología II « Jummp
Pingback: Desarrollo de software. Objetivos, incertidumbre, agilidad « Jummp
Pingback: Desarrollo de software. Agente del cambio « Jummp
Pingback: Desarrollo de software. Sobre las estimaciones « Jummp
Pingback: Desarrollo de software. Percepción, abstracción, implementación « Jummp
Pingback: Desarrollo de software. Agilidad vs fricción « Jummp
Pingback: Desarrollo de software. Agilidad no es improvisación « Jummp
Pingback: Desarrollo de software. Antipatrón. Ingeniería de diapositivas « Jummp
Pingback: Desarrollo de software. La agilidad no es dar bandazos « Jummp
Pingback: Desarrollo de software. La agilidad y el nirvana « Jummp
Pingback: Desarrollo de software. La evolución en el enfoque del proceso de desarrollo « Jummp
Pingback: Desarrollo de software. Agilidad, orientación al producto y orientación al proyecto « Jummp