Un poco de historia de "Ágil"

Como hemos podido ver en post anteriores (Que es Ágil), la gestión ágil de proyectos intenta resolver los problemas de gestión que el enfoque “Tradicional” o “En Cascada” no puede.  La gestión ágil de proyectos esta enfocada básicamente en proyectos con alto nivel de incertidumbre, con mediano o alto nivel de complejidad, con procesos desconocidos o que deberán ser adaptados durante se este ejecutando el proyecto, características del producto, servicio o resultado que podrían variar basado en los resultados obtenidos por el proyecto a mediano plazo, con necesidad de retroalimentación temprana y con alta frecuencia para la toma de decisiones y que necesitan flexibilidad en el alcance, tiempo y/o costos.  Ahora bien, estos proyectos no existen desde hace 6 meses, estos tipos de proyectos tienen muchos años existiendo, entonces, quien fue el primero que pensó en esto de “Ágil”?, fue el concepto inicial de esa persona o personas el mismo que tenemos ahora?, ha evolucionado con el tiempo?, desde cuando esta este tema de “Ágil” en el mundo de la gestión de proyectos?.  Hablemos un poco de eso.

Todo este tema de “Ágil” y su funcionamiento esta basado en el uso de pequeños ciclos de trabajo, de los cuales se hacen varios (varios ciclos), estos ciclos van acumulando un resultado que crece con cada uno de ellos, este modelo es llamado “Desarrollo en Espiral”.  El Desarrollo en Espiral fue definido por primera vez en 1986 en un articulo publicado por el sr. Barry Boehm (un señor que le gustaba hacer muchas cosas interesantes por sus años de juventud y que posee un Master y un PhD en Matemáticas, para los que les gusta estudiar matemáticas a niveles de Master).   Sin embargo, la NASA uso el “Desarrollo Iterativo e Incremental” en su proyecto Mercury a principios de los 60s según un artículo publicado por el sr. Victor R. Basili (“Iteractive and Incremental Development: A Brief History”).  En ese mismo articulo se menciona que IBM estuvo usando estas técnicas a principios de 1957.  Es decir, este asunto lo usan desde hace un tiempo, imagínese… 1957  0_o.

Mientras estas personas de la NASA e IBM estaban tratando de gestionar sus proyectos y crear sus productos usando un enfoque distinto al “Tradicional”, el Project Management Institute (PMI) es formado en Estados Unidos en el 1969, es formado también el International Project Management Association (IPMA) en Europa para eso del 1965 (aunque ese nombre lo oficializaron realmente en el 1979, del 1965 al 1979 tenían otro nombre), en 1953 inician en Toyota con el uso de las pizarras de Kanban, que no es mas que un sistema de tarjetas postradas en columnas (regularmente en una pizarra) para controlar el trabajo en proceso, trabajo pendiente, trabajo terminado, y otros estados.  Todo esto de Kanban surgió como un subsistema de JIT (Just in Time) y lo mencionamos porque se usa bastante en el enfoque “Ágil”.

Paralelo a todo lo que he mencionado, la industria de software estaba en asenso y como ya les había mencionado, estos proyectos de desarrollo de software cumplen con la gran mayoría de las características que una gestión “En Cascada” no podía resolver, estos señores que producían software tenían un serio problema en las manos y necesitaban resolverlo.  Y Como dijo Platón “La necesidad es  la madre de la invención”, comenzaron a surgir un conjunto de “Frameworks”, Metodologías, Mejores Prácticas, Guías, Artículos, etc. que indicaban como los diferentes grupos de ingenieros de diferentes industrias intentaban resolver la situación.  En 1986 se usa por primera vez el término “Scrum” haciendo alusión a un “Framework” para la gestión de proyectos de software.  Esto fue en un artículo de Harvard Business Review publicado por un conjunto de ingenieros que usaron ese novedoso “Framework” en empresas como Canon, Honda, NEC, 3M, Xerox, HP, etc.

Ya para mediados de los 90s existían varias opciones para poder enfrentar los proyectos que la gestión “En Cascada” no podía solucionar, Scrum se populariza, eXtreme Programming y TDD (Test Driven Development) que son otras formas de desarrollar productos de software atendiendo a las características que mencionamos al principio de este post y que inician a finales de los 90s (gracias a un señor llamado Kent Beck).

A esos del 2000 ya teníamos un conjunto importante de “Frameworks” y metodologías que “resolvían” el tema del desarrollo de software (que eran los mas afectados por la naturaleza de sus proyectos) y que habían surgido en la década de los 90s,  pero todos estaban hasta cierto punto dispersos.  Entonces, en el año 2001, específicamente entre el 11 y el 13 de Febrero de ese año, en el Lodge at Snowbird resort de Utah, 17 personas se reunieron a hablar un poco sobre el tema.  Estas personas representaban los principales “Frameworks Agiles” hasta ese momento y producto de esa reunión se formo la Alianza Ágil compuesta por todos ellos y también surgió la pieza principal que rige hoy en día el Desarrollo Ágil, nos referimos a el Manifiesto Ágil, el cual fue firmado por todos los presentes.

El Manifiesto Ágil que surgió de esa reunión con los 17 principales representantes de los diferentes movimientos “ágiles” hasta ese momento, cuenta con cuatro valores y 12 principios y aquí esta lo que dice:

"Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractual

Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda."

Lo firmaron los siguientes personajes:

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 Sutherlan and Dave Thomas.

Los 12 Principios del Manifiesto Ágil son los siguientes:

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
3. Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
7. El software funcionando es la medida principal de progreso.
8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
9. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

Todo lo anterior es historia, sin embargo, hoy en día siguen vigente todos estos principios y valores y cada día son mas los equipos de desarrollo de software que usan los “Frameworks”, metodologías y mejores practicas que fueron impulsadas a través de este manifiesto y por estos autores.

No obstante, no solo los proyectos de software tienen problemas en cuanto a su gestión que el enfoque “En Cascada” no puede resolver y según hemos visto, el manifiesto ágil aunque puede usarse para el desarrollo de productos, esta enfocado al desarrollo de productos de software.  Atendiendo a esta problemática, en el 2005, un grupo de los autores del manifiesto ágil junto a otro pequeño grupo de personas, redactaron lo que le llamaron “PM Declaration of Interdependence” o DOI que cuenta a su vez con seis principios que son mas específicos de la gestión de proyectos ágiles en general (no específicos de la gestión de proyectos de software).  Los seis principios son los siguientes (en ingles):

1. We increase return on investment by making continuous flow of value our focus.
2. We deliver reliable results by engaging customers in frequent interactions and shared ownership.
3. We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
4. We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
5. We boost performance through group accountability for results and shared responsibility for team effectiveness.
6. We improve effectiveness and reliability through situationally specific strategies, processes and practices.

Los firmantes del DOI son los siguientes:

David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki.

Bueno, hemos hablado bastante de historia, aunque se que somos gente de acción, también se que la historia debemos conocerla.  A continuación les dejo algunos enlaces de interés relacionados con este tema.  Hasta la próxima.

Enlaces:

Alianza  Ágil (http://www.agilealliance.org)

Manifiesto Ágil (http://agilemanifesto.org)

Declaración de Interdependencia (http://pmdoi.org)