Conversis Consulting – Marketing orientado a resultados para mercados tecnológicos

Desde hace unos años todo es Agile: la creación de software, el desarrollo de productos, las organizaciones… En este post explicamos los orígenes de esta filosofía, los beneficios que aporta y algunas de sus limitaciones.

Desde hace más de diez años las filosofías Agile están revolucionando el desarrollo de software. Por poner como ejemplo a alguien habitual en este blog, Steve Blank y Eric Ries han incorporado el Desarrollo Ágil como una de las bases de su Startup Stack (junto a Customer Development y Business Model Generation). Tal ha llegado a ser el predicamento de esta filosofía que en los últimos tiempos hay quien intenta convencernos de que Agile no solo es la panacea para el desarrollo de productos de cualquier tipo y en cualquier mercado, sino que todo aquel que no se haya convertido a Agile no es más que un “dinosaurio de las cascadas” o -lo que casi es peor- un “cowboy metido a programador”.

Por aportar un poco de contexto y abrir el debate sobre el papel de Agile en el desarrollo de productos vamos a repasar los orígenes y principios básicos de este movimiento (desde la perspectiva de alguien que -aunque hace mucho tiempo que dejó de programar- sí que dedicó los primeros años de su carrera a la Ingeniería del Software).

Lo primero que hay que decir es que lo que ahora se conoce como Agile surgió a partir de los años ochenta del pasado siglo (e incluso antes) en forma de metodologías “ligeras” de desarrollo software, como respuesta a las limitaciones de las metodologías “pesadas” tipo Waterfall (Cascada). Dichas metodologías pesadas se habían definido inicialmente para el desarrollo de proyectos de software a medida como una adaptación de los métodos al uso en los sectores de la fabricación y la construcción. Estos son entornos intensivos en el uso de materiales y maquinaria específica y donde los costes de hacer cambios cuando el proyecto está avanzado son prohibitivos, lo que exige una exhaustiva definición inicial de requisitos y un diseño cerrado. Las metodologías de desarrollo software tipo cascada asumen que hay un cliente que sabe cuál es su problema (por eso contrata el desarrollo) y se basan en unas fases secuenciales sin solapamientos y un diseño inicial estable e invariable (BDUF, Big Design Up Front).

Sin embargo el desarrollo de programas, por su propia naturaleza, no se ajusta muy bien a dichas condiciones: la complejidad de los problemas que se suelen resolver mediante software, la indefinición de los requisitos del cliente, la importancia de la interacción entre el producto final y sus usuarios, el continuo cambio tecnológico, etc. hacían imposible que aspectos como la solución dada al problema del cliente, los requisitos, el diseño e incluso la arquitectura del programa pudieran mantenerse constantes durante el desarrollo. Y el modelo en cascada no está preparado para encajar bien esos cambios.

Por otra parte la tecnología del software posee algunas características particulares que abrieron la posibilidad de otro tipo de metodologías; entre estas peculiaridades podemos citar la facilidad para “componentizar”/modularizar el desarrollo, crear prototipos o automatizar las pruebas y los (comparativamente) bajos costes de realizar cambios que aporta su naturaleza “inmaterial”. A partir de los pasados años ochenta empiezan a aparecer una serie de nuevos modelos para el desarrollo de software a medida, tales como el Desarrollo Rápido de Aplicaciones, el Espiral o el Proceso Unificado y -más tarde- metodologías como XP (Extreme Programming) o FDD (Feature Driven Development). Estas metodologías se basan en un desarrollo iterativo e incremental en el que los requisitos y las soluciones van evolucionando gracias a la comunicación con los usuarios y la colaboración entre equipos multidisciplinares autoorganizados, todo con el objetivo de mejorar la calidad del software y la capacidad de respuesta ante cambios en los requisitos del cliente y el entorno.

En la segunda parte de este post hablaremos del Agile Manifesto y de los beneficios y limitaciones de estos enfoques.

Este post en Marketing & Innovación.

9 Respuestas a “Los orígenes de Agile (1)”

Deja un comentario

Está permitido HTML básico. No se publicará tu dirección de correo electrónico.

Suscribirse a este feed de comentarios vía RSS

Este sitio utiliza Akismet para reducir el spam. Conoce cómo se procesan los datos de tus comentarios.