Las metodologías ágiles no existen

En agilidad no hay un único “libro gordo” que defina y cuente exactamente qué hay que hacer y cumplir para ser ágil. De hecho, como te contaba hace unos meses, no hay ni una única y cerrada definición de qué es agilidad (Nadie sabe lo que significa agilidad).

Ciertamente, en ocasiones, esto puede ser un problema (principalmente al introducirse en el mundo ágil), pero, realmente, esto denota la fuerza de la idea.

La agilidad se va, y se ha ido, construyendo, creciendo y madurando como idea desde hace años (incluso antes de llamarse agilidad, véase, como ejemplo, que los primeros ciclos de vida iterativos eran de los 50) y desde muchas fuentes.

Los que empezamos a introducirnos en el mundo ágil hace ya muchos años, mi primer proyecto ágil fue en 2001 (ya te dejé en su día la ppt, la presentación, de mi primer proyecto Agil, ojo, del 2001), recordamos frecuentemente los que con los años ha crecido en madurez.

Hay unos mínimos, pongamos el Manifiesto Ágil, pero si lo lees, veras que lo que hoy la comunidad considera que son buenas prácticas ágiles van mucho más allá de los valores y principios del manifiesto, que juntos apenas ocupan unas páginas.

Por ello, decimos que las metodologías ágiles realmente no son metodologías, son “frameworks” o conjuntos de buenas prácticas, guías. Por eso, más allá de unos mínimos comunes, no hay dos equipos que “usen” la misma agilidad.

Aunque en el día a día sigamos usando la palabra “metodología” y así seguirá siendo.
Scrum, la polémica SAFe, eXtremme Programming, las “metodologías” Crystal, FDD, DSDM, etc., son guías que nos ayudan a no partir de cero, nos ayudan a no enfrentarnos sin más a algo tan abierto como el manifiesto ágil.

Buenas prácticas como equipos multifuncionales, auto-organizados, equipos pequeños, el ciclo de vida iterativo-incremental, etc., son, igualmente, buenas prácticas que se han ido madurando con los años bajo el paraguas de la agilidad (siendo la mayoría previas al término). Y que han madurado desde multitud de fuentes diferentes, no una única, desde multitud de empresas, equipos, organizaciones, etc.

Todos los anteriores, “metodologías” y buenas prácticas, son como las ruedas de ayuda que se ponen a las bicis cuando quieres empezar a pedalear, son una ayuda con la que comenzar, para que cuanto te sientas seguro… crees tu propio pedaleo. Eso sí, sin olvidar los mínimos y buenas prácticas que te ayudaron a pedalear correctamente.

A diferencia de la generación de metodologías previas, recuerda aquello de las 3 metodologías más importantes en los 80 y los 90, de aquellos “libros gordos” de un único autor/es, que pretendía establecer una única manera de trabajar, una especie de “Ley” sobre como ellos creían que se debían hacer las cosas, esas metodologías que, como yo suelo llamar, parecían libros de cocina en los que te decían “cómo se hace la tortilla de patatas, paso 1, paso 2, paso 3, etc.”

Si bien esto puede ser un problema al introducirse en el mundo ágil, ya que no vas a encontrar un único libro-guía-biblia-metodología que te diga exactamente y con todo detalle cómo tienes que trabajar, realmente, y frente a las metodologías de los 80-90, la apertura, bajo unos mínimos, el crecimiento de la agilidad desde numerosas fuentes, es lo que más fuerza le da a las “metodologías” ágiles.

5 comentarios en “Las metodologías ágiles no existen”

  1. Qué rabia da llamar a las cosas lo que no son. Cuando se enteraran la mayoría de las empresas la diferencia entre metodologías y buenas prácticas.

  2. Javier,
    Estoy de acuerdo en que no hay una «definicion canonica» de lo que es la agilidad, porque es un movimiento colectivo mas que una coleccion de procesos y practicas «definidas» por un equipo.
    Lo que si me gustaria destacar es que a los equipos mas inmaduros si les conviene una vision integrada o completa como una base que les ayude a crecer en madurez y resultados, pero explicando siempre el porque de las practicas, nunca siguiendolas de manera dogmatica (ni siquiera a Scrum). Una vez que han ganado en madurez, tienen mas facil escoger la configuracion de practicas y roles que mejor se ajusta a su contexto.
    Disciplined Agile Delivery, de Scott Ambler, es una buena compilacion de practicas agiles (y tradicionales) que puede cubrir ese hueco que identificas.
    Disciplined Agile Delivery, de Scott Ambler, es quizas una buena compilacion de practicas y metodos agiles (y alguna no agil como los casos de uso)

  3. Ninguna metodología software es un libro gordo que haya que seguir de pe a pa. Todas las metodologías son marcos de trabajo o frameworks o conjuntos de buenas prácticas. Todas. Así lo di yo en la carrera y así viene recogido en la wikipedia: http://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_software
    Tampoco hay 2 equipos que sigan el mismo RUP, RAD, Métrica o MARTE. Y en todos esos libros gordos lo primero que te dicen es que debes adaptar la metodología a las circunstancias del proyecto. Pero se ve que son libros tan gordos que mucha gente se salta el primer capítulo 😀
    A partir de aquí simplemente podemos definir que las metodologías ágiles son aquellos frameworks cuyos autores están bajo el paraguas del Agilismo y que siguen los principios del manifiesto ágil. Las hay más técnicas como XP o más orientadas a organizar el trabajo como Scrum.
    Será labor de un buen ingeniero software o jefe de proyecto decidir qué partes de qué framework usar para un proyecto concreto.
    Intentar seguir una metodología de pe a pa es una locura. Hay muy pocos proyectos a los que les convenga usar, pej, un Scrum puro.

  4. Metodología : Latín methodus y éste a su vez del griego μέθοδος (methodos), que significa camino o vía. μέθοδος (methodos) palabras griegas: μετα (metha) y ὁδός (odos). Metha, y odos, que significa camino, Por lo tanto, en su acepción original, la palabra método podría significar el camino para llegar más allá.
    Framework: Marco de trabajo,  conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar.
    Cada quien que le llame como quiera, al final lo que importa es el valor y que les funcione,, lo demás es desperdicio.

Deja un comentario

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

Share This
Ir arriba