El difícil equilibrio de la metodología ágil

Hoy en día las empresas están locas por utilizar la metodología ágil, no hay más que echar un vistazo a las ofertas de empleo y cómo tener conocimientos de SCRUM (uno de los marcos de trabajo para desarrollo ágil de software) es algo que se ve mucho. Pero, ¿qué es en realidad la metodología ágil?

Todas las empresas se piensan que es algo novedoso y que hay que implantarlo sí o sí, pero nada más lejos. Todos los que estamos detrás de este blog, estábamos todavía en BUP, cuando ya se empezaba a hablar de metodología ágil, estamos hablando de 1990, así que, moderno, ya os adelantamos que no es.

Por no entrar en detalle, la metodología ágil es lo que ha funcionado siempre, ir desarrollando software, poco a poco, desarrollas un núcleo, al que luego vas añadiendo funcionalidad, para tener al final un producto completo, que sigue vivo y evolucionando. Realmente, todos usamos esta forma de trabajar, porque no hay otra, tienes una idea de lo que quieres, lo montas y con el uso, te van surgiendo nuevas necesidades.

Por eso, los proyectos tienen que ser vivos y nos alegramos que se vuelva esto, pero tiene sus problemas. Y ahí es donde queremos llegar. Nos han vendido durante un tiempo la importancia de los ciclos de vida del software, de definir bien los requerimientos, de tenerlo todo documentado antes de pintar una línea de código, en definitiva, todo lo contrario a la metodología ágil, cuyo objetivo es empezar a trabajar desde el minuto 0 y que los requisitos vayan creciendo con el proyecto.

Y decimos que es un equilibrio difícil, porque los que siguen queriendo tener todo escrito antes de hacer nada y además, quieren metodología ágil, se encuentran con que muchas veces hay código, sin una definición exhaustiva y claro, le rechina.

Así que el equilibrio de un jefe de proyecto, es seguir la metodología ágil, dándole algo al jefe "tradicional", de modo que se cumpla la metodología y además, el jefe tenga sus documentos.