Á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 *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

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