Ágil

En nuestros primeros blogs de gestión de proyectos empezamos, como casi todo el mundo, por los chistes, los fracasos y las mentiras (1, 2). Analizábamos las causas del fracaso y nos salían temas de tipo más organizativo (involucración de usuarios y directivos, presiones económicas que afectan al tiempo y coste), que de tipo técnico o de gestión del proyecto (requerimientos poco definidos, pruebas insuficientes). La mejora de la gestión de proyectos como disciplina y profesión y la introducción y práctica de la cultura de proyectos dentro de las empresas ha mejorado en el ciclo largo la calidad y resultados de los proyectos, más o menos hasta principios de los 2000, pero en los últimos años tiene un efecto marginal. Aproximadamente, un cuarto de los proyectos son un fracaso total y más o menos un tercio pues ni fu ni fa.

El enfoque tradicional y bien establecido de la gestión de proyectos, en las TIC y en cualquier otra cosa, se basa en la obsesión por la predictibilidad y el cumplimiento, soportados por liderazgos fuertes y documentación exhaustiva. Si definimos bien el alcance, si tenemos un buen plan y si todas las partes lo cumplen y nos dirige un buen jefe, el proyecto será un éxito. Pero lo es pocas veces. El cliente y los usuarios no saben bien lo que quieren y lo cambian continuamente (o no saben explicarlo, o el analista no los entiende), aceptamos presupuestos cortos que sabemos que no podremos cumplir (también lo sabe el comprador) y las empresas no hacen lo que tienen que hacer para que el proyecto y sus resultados sirvan para algo.

He prometido varias veces hablar de las metodologías ágiles y lo he hecho alguna vez de pasada, cuando me he referido a la implantación de ERPs o a proyectos de Business Intelligence. Gente que sabe mucho más que yo ha venido hace poco a un coloquio en la UOC promovido por el profesor Santi Caballé, director de los programas de posgrado de Ingeniería del Software. Podéis seguir el coloquio aquí (http://vimeo.com/42257313).

Los ponentes, Jordi Pradel y Jose Raya, son miembros de la asociación Agile Barcelona, muy activa en la formación y divulgación de esta clase de enfoques.

Me gustó esta manera de presentarlo. En Agile hay desarrolladores con vocación de excelencia y buenas técnicas y herramientas. Pero sobre todo hay otra visión y otra clase de valores y principios, que están resumidos en el manifiesto Agile publicado en 2001 por un grupo de 20 desarrolladores, más o menos liderados por Martin Fowler.

Me cuesta ponerlo en sus términos, acaso por esa aprensión hacia las ideologías que he confesado otras veces, pero yo lo diría así:

  • Agile acepta con humildad y realismo que las cosas no son predecibles siempre, que habrá cambios que hay que saludar y no maldecir, que la relación con el usuario será complicada pero productiva y que la fatalidad del triángulo virtuoso de alcance, tiempo y coste se puede romper de vez en cuando sin que pase nada.
  • Agile reniega del desarrollo en cascada y de la transferencia de instrucciones cada vez más precisas entre el usuario, el analista, el desarrollador y el probador, bajo la severa mirada del jefe de proyecto, que finalmente y al cabo de meses o años no tienen nada que ver con lo que el cliente realmente necesitaba. Los desarrolladores producen software en vivo cada semana que el cliente puede usar, aprender y cambiar. La única métrica de progreso del proyecto es la entrega de software que funciona, continuamente.
  • La relación es simple y directa, basada en la confianza, el diálogo y el trabajo conjunto y autoorganizado del usuario y el desarrollador. Hay pocos jefes, poca documentación y procesos de gestión de proyectos bastante elementales.

Seguramente, esto quiere decir también otro tipo de desarrolladores con habilidades de consultoría, otro tipo de clientes no obsesionados por los contratos y presupuestos y otras culturas de empresa en las dos partes. No hay mucha evidencia de que sea más barato y efectivo siempre, pero no es más caro y menos efectivo que trabajar como hasta ahora.

Y, como ocurrió con el software libre, se va introduciendo sutilmente en empresas de todos los tamaños y sectores, sobre todo en las más grandes y en las más pequeñas. Tiene sentido. Y hasta la ortodoxia de la gestión de proyectos como el PMI lo está incorporando a su colección de metodologías.

Otra forma de construir buen software y de gestionar proyectos es posible (3).

Notas:
1. Las pequeñas mentiras que nos contamos los jefes de proyecto
2. Bromas aparte (más sobre gestión de proyectos)
3. Santi Caballé me pasa un espléndido artículo muy reciente: Willians, L.: “What Agile teams think of Agile principles”. Communications of the ACM (April 2012, Vol 55, num. 4).

Trackbacks/Pingbacks

  1. Bitacoras.com - Información Bitacoras.com... Valora en Bitacoras.com: En nuestros primeros blogs de gestión de proyectos empezamos, como casi todo el mundo,…
  2. Buenas noticias para la gestión de proyectos | iNFoRMáTiCa++ - [...] lo ágil es más hermoso. Los proyectos de desarrollo basados en metodologías ágiles salen tres veces mejor que los basados…
  3. El paradigma PDCA | iNFoRMáTiCa++ - [...] de su desarrollo y aplicación práctica no parece que sean para sentirse orgullosos. Dejad que me autocite: “El enfoque…

Comentar

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Leer entrada anterior
¿Sigue importando la IT?

Se cumplen nueve años de la publicación en la revista de negocios de Harvard del artículo de Nick Carr “Does...

Cerrar