Читать книгу Los Fundamentos de Agile Scrum - Frank Turley - Страница 13

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 (incrementos) y los utilizamos para adaptar la solución.

Valor 3: Colaboración con el cliente sobre negociación contractual

Cualquier proyecto tendría más éxito si tuviera un nivel de colaboración más alto del cliente. En los sistemas Adaptativos, es más que importante: es necesario. El cliente tiene que colaborar con nosotros todo el tiempo ya que estamos constantemente especificando nuevos requisitos y requiriéndole que compruebe los incrementos y que nos dé feedback. Si no lo hace, no podremos adaptar la solución.

Y a todos nos encanta la negociación contractual Un proyecto Agile ideal, con un contrato de tiempo y material y un cliente que no cree que los proveedores son delincuentes, no necesita mucha negociación contractual. Las dos partes trabajan conjuntamente para crear un producto de valor. Sin embargo, el ideal es tan solo el ideal, y los clientes siguen buscando contratos que delimitan el ámbito y el precio, que suponen una contradicción fundamental con los métodos Adaptativos, lo cual es una fuente de negociaciones interminables de contrato similares a las de los proyectos Predictivos.

Valor 4: Respuesta ante el cambio sobre seguir un plan

Esta declaración, como la segunda declaración, es específica a los sistemas Adaptativos. En vez de tener un plan por adelantado, Predictivo, que nos muestra el camino, dependemos de la adaptación. A esto último, se le suele llamar “cambio” en Agile, probablemente porque hace feliz a los clientes saber que pueden cambiarlo todo, aunque de hecho, no es un cambio salvo que no cuadre con el plan de base inicial que no tenemos en los sistemas Adaptativos. Técnicamente, lo que tenemos es un flujo continuo de ideas nuevas. Sin embargo, continuemos llamándolos cambios, por el bien de todos los clientes.

■ Muy probablemente haya preguntas sobre el Manifiesto Agile en el examen. No es mala idea revisarlo varias veces y poder incluso memorizar las cuatro declaraciones.