Ser ágil no es ser rápido

Hoy vamos a hablar de la diferencia entre agilidad y rapidez. Y porqué las metodologías ágiles, no tienen que ver con hacer un proyecto más rápidamente, y por tanto, con acabar antes. Cuánta confusión veo constantemente, generada precisamente por los desconocedores y los interesados en las metodologías ágiles. Los primeros, porque asocian automaticamente ágil=rápido, ya que la semántica nos induce a ello. Y los segundos, porque siembran la red de confusión en este sentido ya que tienen intereses profesionales y económicos al respecto. No hay mejor argumento de venta que el decir: ágil=rápido=barato.

Sinceramente, creo que hemos llegado a un nivel de información en la red en el que tenemos que empezar a dudar en la credibilidad de todo lo que vemos escrito, y darle un poco de trabajo a nuestro sentido común (que en ocasiones parece el menos común de los sentidos), y a nuestro sentido crítico.

Este artículo, viene inspirado en diversas entradas que estoy leyendo en las redes y que insisten consistentemente en sembrar la confusión entre estos conceptos. Y señores, no son iguales.

Podemos encontrar multitud de artículos en la web en que incluso defensores del agilismo, admiten la confusión entre estos dos términos. Pero vamos a tratar aquí de usar un poco de sentido común para entender un poco más el problema.

El concepto de rapidez en los proyectos ágiles.

En los proyectos ágiles, la medida del avance es la rapidez. Otra contradicción, por otro lado necesaria, ya que la única forma de saber cómo vamos y cuándo vamos a acabar, es utilizar esta métrica.

Al contrario que los proyectos que no usan metodologías ágiles, el estar abiertos al cambio hace que los requisitos estén permanentemente sujetos al cambio. La única forma de anticipar cuándo acabaremos, no está por tanto en medir el avance por requisitos, sino basarnos en la velocidad. La velocidad o rapidez, es por tanto, lo único cierto y medible. El resto: dependerá de cuántos cambios asumamos. Puede que ahora tengamos 20 historias de usuario. Pero pueden cambiar, y ser mañana 30, o 15...

Notemos aquí lo curioso del tema. Al hacer proyectos con metodologías ágiles, también necesitamos predecir y controlar cuándo va a finalizar el proyecto. La diferencia es la que estamos comentando, que no se basa en el cuánto (nº de requisitos), sino en el cómo (rapidez). Es por eso que los diagramas burndown chart son los principales referentes a la hora de conocer el avance y tratar de predecir cuándo tendremos el producto.

La rapidez en estos proyectos con metodologías ágiles será el número de puntos de historia de usuario (u otra métrica relativa) que realizamos por unidad de tiempo. De esta forma, si hemos estimado bien, podremos predecir el futuro.

El concepto de agilidad en los proyectos ágiles.

En las metodologías ágiles, el término agilidad o ágil está relacionado con la capacidad de adaptación al cambio. Pero no tiene nada que ver, e insisto en el NADA, con la velocidad del proyecto.

Agilidad, es la capacidad para adaptar el curso del desarrollo a la evolución de los requisitos y a las circunstancias del entorno (fuente: Navegapolis.Net, "Gestión de proyectos ágil: conceptos básicos").

Es decir, que la palabra "ágiles" en metodologías ágiles, no tiene nada que ver con rapidez del proyecto, sino con la adaptabilidad al cambio: la disponibilidad y facilidad para asumir cambios en el alcance (nuevos requisitos, o requisitos existentes).

¿Confusión interesada?

Llegados a este punto, empiezo a preguntarme si la confusión de términos no es interesada. A ver, no tengo nada en contra de los defensores del agilismo. Yo también defiendo el agilismo. Pero si lees este blog, sabrás que la cuestión no es defenderlo, sino defenderlo si aplica. No defenderlo porque sí. Todo dependerá del proyecto, equipo de trabajo, cliente, y metodologías actualmente en uso.