Los Fundamentos de Agile Scrum. Frank Turley
a los Ciclos de vida Predictivos usados en proyectos de TI; no se oye a nadie decir “Este edificio se construyó usando el método en Cascada”.
Para asegurarse de que conoce a fondo la terminología, debe ser consciente de que decir método en Cascada es prácticamente una grosería hoy en día, y ¡tiene derecho a enfadarse y a ofenderse si alguien le dice que está usando el método en Cascada! Por eso sugiero que usemos el concepto más formal en este libro: Ciclo de vida Predictivo.
■ ¿ES NUEVO AGILE?
Normalmente, Agile se anuncia como la novedad. Ciertamente, el uso del concepto Agile refiriéndose a los Ciclos de vida Adaptativos es nuevo, pero ¿el ciclo de vida en sí lo es?
No sé a los demás pero a mí me cuesta imaginar la larga historia del ser humano con tantos proyectos y programas que se habrá realizado sin que hubiera ningún tipo de ciclo de vida adaptativo. ¿Se le ocurre algún ejemplo?
Le propongo uno. Piense en una iniciativa (programa o proyecto) muy popular en los viejos tiempos: el ir a la guerra. ¿Se puede gestionar una guerra con un enfoque Predictivo? ¿Planifican y diseñan todo desde el comienzo? Desde luego que no. Puede que haya un plan inicial general que se parezca más a una estrategia que a un plan, y que se gestione la guerra de batalla (es decir, iteración) en batalla (o con varias a la vez), y en función del resultado de cada batalla, se adapta el resto de la iniciativa.
No es un ejemplo agradable pero es un ejemplo claro de que los Ciclos de vida Adaptativos no pueden ser nuevos.
Entonces, ¿cuál es la novedad?
En un momento dado, el enfoque de gestión conocido como el científico y el Taylorismo se convirtieron en la norma, tanto es así que cualquier otro enfoque se percibía como inferior e incluso equivocado. El Taylorismo se basaba plenamente en sistemas Predictivos. Por lo tanto, los sistemas Predictivos dominaban el mundo, por así decirlo.
Después, llegamos a un momento en el que se iniciaban más y más proyectos de desarrollo de TI y los Ciclos de vida Predictivos no eran la mejor manera de gestionar aquellos proyectos. Las personas intentaron aguantar, mientras que aumentaba la presión hasta que hubo manifestaciones y, finalmente, ¡la revolución! Como cualquier otra revolución, devoró a sus retoños pero ese es un tema para otro momento.
■ EL MANIFIESTO AGILE
Algunas personas comenzaron a usar sistemas Adaptativos para el desarrollo de TI y, poco a poco, los fueron organizando en procesos de gestión que se podían repetir. Un grupo de pioneros se juntó en el 2001 para formalizarlos, dándoles nombre y creando un manifiesto.
Empecemos por el nombre. La leyenda dice que las dos opciones al final era Agile (Ágil) y Adaptive (Adaptativo).
Lamentablemente, se quedaron con Agile. Adaptive habría sido mucho mejor porque describe la naturaleza del enfoque y evita muchos malentendidos.
Así pues, a continuación le mostramos el Manifiesto Agile. Está disponible en la página web AgileManifesto.org, muy moderna y avanzada.
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.
| Kent Beck | Ward Cunningham | Andrew Hunt | Robert C. Martin | Dave Thomas |
| Mike Beedle | Martin Fowler | Ron Jeffries | Steve Mellor | |
| Arie van Bennekum | James Grenning | Jon Kern | Ken Schwaber | |
| Alistair Cockburn | Jim Highsmith | Brian Marick | Jeff Sutherland |
© 2001, los autores mencionados mediante esta nota se autoriza la copia y distribución de esta declaración a través de cualquier medio pero sólo de forma íntegra.
Lamentablemente, este manifiesto en sí no ha sido adaptado en lo que tiene de vida.
La última frase normalmente se pasa por alto. Le invito a que lea de nuevo el manifiesto teniendo en cuenta la última frase.
Así pues, revisemos estas cuatro declaraciones.
Valor 1: Individuos e interacciones sobre procesos y herramientas
Restarle importancia a los individuos y a las interacciones es una manera muy rápida de fracasar. Al fin y al cabo, son las personas las que realizan el proyecto. Algunos miembros de dirección piensan que pueden superar problemas en este ámbito usando un “sistema” más sofisticado pero eso no funciona casi nunca, o nunca.
Muchos nos hemos visto decepcionados por el optimismo ingenuo de pensar que, al implementar una herramienta sofisticada, se iban a solucionar problemas causados por no tener en cuenta el aspecto humano, o incluso sus métodos. Aun así, los responsables se gastan cantidades enormes de dinero implementando y manteniendo herramientas, con la esperanza de que sean mágicas. El hecho es que las herramientas solo pueden facilitar un sistema; no sustituyen la necesidad de tener un sistema en sí. El lado positivo es que estas herramientas son programas de software sofisticados que necesitan años de desarrollo y mantenimiento y crean muchos proyectos y empleos, y ¡nos ofrecen la posibilidad de invertir en pensar en cómo mejorar nuestra forma de realizar proyectos de TI!
La parte sobre procesos en esta declaración es un poco delicada. En realidad, habla de un tipo concreto de proceso, no de los procesos en general. Trata de aquellos procesos que han sido diseñados para sustituir la necesidad de la interacción humana y sus complejidades. Personalmente, conozco directores que creen que si tienen un mejor proceso, no tendrán que contratar a expertos profesionales. Mientras tanto, uno de los aspectos geniales de los sistemas Agile es que TODOS tienen integrados el aspecto humano en sus procesos, en vez de meterlo a la fuerza o incluso limitarse a comentar la importancia de la faceta humana, lo cual ocurre, lamentablemente, con los sistemas de gestión de proyectos ya establecidos.
Por lo tanto, para resumir, los procesos que intentan ignorar o reemplazar el aspecto humano son malos, y los procesos que incluyen estos aspectos y los integran como parte del sistema son buenos.
Valor 2: Software funcionando sobre documentación extensiva
Al contrario de la declaración anterior, que es correcta para todo tipo de proyectos, esta es específica a los sistemas Adaptativos. Se refiere al hecho de que, en vez de utilizar documentación por adelantado para predecir lo que tiene que ocurrir en un proyecto, simplemente, trabajamos sobre partes de software operativos