El Manifiesto Ágil

Tras haber escrito ya bastantes artículos que hablan sobre las metodologías Ágiles, no podía faltar en el Blog un post sobre el Manifiesto Ágil.

En el año 2001, diecisiete expertos se reunieron para plantear las bases de las metodologías Ágiles. Definieron un conjunto de principios básicos sobre como enfocar el desarrollo de una manera más ágil en contraposición con el modelo en cascada, considerado más rígido y con mayor dependencia normativa, de la planificación y de la documentación. Este grupo promulgó unos valores sobre una nueva manera de gestionar y realizar los proyectos de desarrollo de Sw que desde entonces definen “la doctrina” Ágil.

Si quieres saber los nombres de esas personas puedes visitar la página del manifiesto ágil en español, desde este enlace.

En esta página, que por cierto, no puede ser más fea , además de los valores, se describen los principios que aplican a un desarrollo ágil y hay un enlace para poder firmar el manifiesto. Algo así como una forma de adherirse al mismo y dejar un pequeño comentario sobre lo que piensas de él.

Algunas de las últimas firmas dicen :

Agile methodology has given us a new way to look at software development and we look forward to enhance and add value to our efforts to grow with agile and deliver value to all stakeholders.

Must say that Agile methodologies have changed the way project management was supposed to be.

I’ve been doing this for years. Is it easy? No, not always. But it works in this ever changing world.

After working as a software tester in waterfall development models for many years, I am finally working in an Agile (SCRUM) environment. I am happy to finally work in a way that makes sense, and is effective!

Los 4 valores dicen así:

• Valorar más a los individuos y su interacción que a los procesos y las herramientas
• Valorar más el software que funciona que la documentación exhaustiva.
• Valorar más la colaboración con el cliente que la negociación contractual
• Valorar más la respuesta al cambio que el seguimiento de un plan

Se ha discutido mucho sobre lo que esto significa. Defensores y detractores del modelo han comentado el significado de cada uno de estos principios.Al principio, todo era más radical en cuanto a los planteamientos y el cambio hacia el modelo Ágil que defendían los pioneros, fue enfocado como una ruptura total con el modelo tradicional.Los planteamientos radicales fueron usados por los detractores del modelo para realizar una fuerte oposición al cambio, pero poco a poco fueron apareciendo corrientes de opinión y planteamientos sensatos que hicieron que estos valores fueran entendidos como lo que realmente son : “ un modelo de trabajo flexible, abierto y más acorde a los tiempos” , que busca lo que todos los que nos dedicamos al desarrollo de Software queremos : “Que el proyecto salga bien.”

Que se valore más el software que funciona que la documentación exhaustiva, por citar el segundo principio, no quiere decir que en un proyecto que adopte una metodología Ágil se vaya a dejar de documentar. No, no quiere decir eso. Los detractores del modelo lo usaron como un arma para atacarlo.La documentación, es necesaria en cualquier proyecto y todos los que nos dedicamos a esto sabemos que hace falta documentar lo que vamos a hacer, como también sabemos que dicha documentación se queda obsoleta rapidamente y que mantenerla actualizada es una tarea que pocos consiguen. Por eso en el manifiesto se promulga que se da más valor a que el Software funcione, en lugar de tener una documentación rigurosa y voluminosa. Documentar :SI , pero no documentar en exceso y estar obsesionado con ello. Creo que es simplemente una cuestión de sentido común como el resto de valores.

Cada uno de valores, promulga unos conceptos donde se valora más la parte de la izquierda que la de la derecha, pero como decía antes. Lo uno no invalida lo otro.

Los procesos y las herramientas, en un proyecto son necesarios, pero en los postulados ágiles, debemos poner más incapié en las personas que llevan a cabo dichos procesos y usan unas herramientas.

Sobre la documentación, ya he comentado antes.

Sobre la colaboración con el cliente frente a la negociación contractual. Con esto es con lo que yo me muestro más excéptico. Colaborar con tu cliente es absolutamente necesario. Una proyecto fracasa normalmente cuando no hay colaboración, pero tan necesario veo esto como tener claro el marco contractual para que los clientes y los proveedores sepan cuales son sus derechos y sus obligaciones. Hay modelos de contratos enfocados a los procesos Ágiles , menos rígidos que los contratos a precio cerrado, que dan opciones a clientes y proveedores de obtener relaciones beneficiosas para ambos , pero creo que aquí es donde más dificultades hay actualmente para que las Organizaciones adopten los modelos Ágiles: en los modelos de contratación. Estos modelos ya se aplican, y lo que el tercero de los valores dice es que busquemos más colaborar con el cliente para que sus objetivos se vean satisfechos y menos en cerrar antes una negociación contractual con él para “amarrar” legalmente el proyecto antes de empezar.

Al final hace falta equilibrio entre ambas cosas. Busquemos colaborar pero usemos modelos en los que todos salgan beneficiados. Esto no es propiedad del manifiesto Ágil. Es algo de debería ser intrínseco a las relaciones entre las partes. Si solo uno gana , la cosa no va bien.

Por último, respecto al cuarto de los valores: Valorar más la respuesta al cambio que el seguimiento de un plan. De acuerdo, pero con limitaciones. Los cambios son bien recibidos por el manifiesto Ágil, pero hay que saber hasta que punto somos capaces de asumirlos y como y de que manera afectan al proyecto. La gestión de cambios es una disciplina de la Gestión de Proyectos que está presente en todos los manuales de cualquier metodología. Unos son más estrictos y aplican más controles sobre el cambio, pero creo que en ninguna de las metodologías sobre las que he estudiado y trabajado dicen radicalmente NO a los cambios. En una metodología Ágil es más fácil introducir cambios pues es consustancial al modelo, y el equipo está más predispuesto a asumir el cambio. El cambio forma parte de su cultura, pero para mi eso no quiere decir que haya carta blanca. Hay que ser sensatos y tener claro que tampoco es bueno que haya continuos cambios porque el equipo se desestabiliza y no tiene el rumbo claro y definido. Incluso trabajando en un proyecto que usa metodologías Ágiles siguiendo completamente el modelo , sin desviarse ni un ápice de los procedimientos , soy de la opinión que también se puede y se debe decir en ocasiones NO a los cambios

Soy partidario de cada uno de los cuatro valores del manifiesto Ágil , pero vengo de un modelo tradicional , más rígido y predictivo, en el que hay que aplicar una metodología en cascada en los proyectos. Sin embargo, incluso si en tu organización te tienes que regir por principios clásicos para los proyectos, mi recomendación es que tu modelo de Gestión se base en estos cuatro valores del manifiesto ágil.

Valora lo que te dice el manifiesto que debes valorar más, aunque tengas que seguir aplicando y cumpliendo con un modelo “oficial” que te dicten las normas de tu empresa. Tu equipo, tus clientes y tú mismo, seguro que trabajaréis mejor y con mayor colaboración y participación. Si eres valiente y decidido y te ves con fuerzas para promover un cambio, empieza por crear en tu organización el ”sentido de urgencia del cambio” , pero eso ya será otro artículo….

 

Fuente: Gestiondeproyectosit.es