Bienvenidos a la #Agilidad: ¿Qué es?

Esto tenía repercusiones de todo tipo:

· Contrato cerrado: los clientes firmaban acuerdos con las empresas por un periodo determinado y que una vez llegado a su fin, se debía entregar un producto completo, sin errores ni fallos, y que satisficiera las necesidades del cliente. 

· Horas/Personas: se creía que cuanta más gente hubiera en un equipo, antes se terminaría el desarrollo del producto software. Lo que llevaba a una situación laboral llena de horas extras y proyectos fuera de tiempo de desarrollo. 

· Líneas de código: el avance y el saneamiento de un proyecto se medía en líneas de código. Esto producía códigos poco mantenibles pero con muchas líneas.

· Una única versión del producto: dada la naturaleza de la metodología y de las exigencias del cliente, sólo se tenía una única versión inicial del producto una vez finalizase el contrato. No había prototipos intermedios ya que todo iba en etapas y la documentación era la justificación del paso entre una etapa y la siguiente, como dije anteriormente.

· Perfiles especializados, diferenciados y altamente jerarquizados: se requería un especialista para cada etapa, desde el Arquitecto del Software, al Desarrollador Software o al Analista Funcional o Técnico, donde cada uno de ellos no tenía por qué saber que hacía el resto y además seguían un patrón jerárquico muy férreo (gerente, jefe de equipo, analista, programador, junior, becario..).

Había muchas más, pero estas representan el escenario que se vivía (y vive) en algunos proyectos y/o empresas. Estuve participando en varios proyectos donde este tipo de metodologías eran la ley y el orden de la sala. 

Nadie podía salirse del carril y la frustración de las personas iba creciendo, hasta dar con auténticos brownies, ricos ricos.

Claro, de tanta gente frustrada algo tenía que salir, aunque fuera en "plan rebelión", por lo que poco a poco se fueron ofreciendo alternativas a la metodología de desarrollo que hasta entonces dominaba el desarrollo software en el mundo.

La alternativa propuesta criticaba todos los puntos anteriores e intentaba dar solución a lo que ocurría en el mundo real. Se empezó con el motor de la metodología y se hizo un cambio drástico en su funcionamiento. Se propuso terminar con el modelo en cascada, declarar la guerra a la predictibilidad y se apostó por un modelo evolucionable, basado en prototipos.

Para cambiar el modelo, se dijo que era el fin de la documentación extensa y justificadora. Ahora lo que iba a dominar un proyecto iban a ser las conocidas como "iteraciones".

Una metodología iterativa busca aumentar el número de características de un producto software, de manera que si por ejemplo desarrollábamos una aplicación para iOS, en la iteración 1 haríamos una funcionalidad, en la iteración 2 introduciríamos una funcionalidad y así sucesivamente.

Esto por si mismo es insuficiente ya que por ejemplo si nos encontrábamos con pequeños problemas de código en la primera iteración, esto se arrastra a sucesivas iteraciones y al final el proyecto perdía fuelle y mantenibilidad, teniendo que finalizarlo prematuramente por tener un código lleno de bugs o por ser ilegible.

Por lo que surgió como remedio las metodologías iterativas-incrementables que buscaban no sólo plantear pequeñas iteraciones en las que se resolvía una o varias funcionalidades en concreto, sino que también se debía mejorar el código existente, es decir, refactorizarlo, entre otras muchas medidas. De esta manera el problema de la mantenibilidad se resolvía y se podían entregar prototipos víables al finalizar cada iteración, favoreciendo también el latido (me refiero al flujo constante entre iteraciones, que se acaba asemejando a un latido).

Las siguientes diapositivas ilustran una metodología iterativa-incremental:

Y entonces surgieron las Metodologías Ágiles, las cuales además tienen hasta un código de lo que "debe" ser un proyecto software ágil, conocido como "Agile Manifesto".

¡El Manifiesto Ágil!

Hay varios modos de enfocar la agilidad, tenemos Lean, Kanban o Scrum (y algunas más). Todas ellas se basan en un enfoque "ágil" y tiene a la metodología iterativa-incremental como corazón, con sus pequeñas modificaciones. Hablaré de ellas en próximos posts.

Esto resuelve la problemática de las metodologías en cascada:

· Contrato abierto: ahora se paga por iteraciones, las cuales tendrán una serie de funcionalidades.

· Refactorizar es prioritario: ahora el código debe ser legible y mantenible.

· El avance se mide en funcionalidades completadas.

· Se relaja la documentación: se aumenta la técnica aplicada a cada funcionalidad, lo que no quiere decir que no se documente (que ya os veo quemando los papeles).

· No hay un especialista para una sola cosa: ahora los equipos son multidisciplinares. Todos saben de todo, aunque algunos sepan más de un poco.

· Surgen nuevos roles y figuras: así como nuevos métodos de estimación.

· El cliente tiene un papel activo en el proyecto: no permanece en la sombra, se implica en cada iteración.

Y más características asociadas a los distintos tipos de aplicación de las metodologías ágiles. Esto en cuanto a gestión de proyectos. Después tenemos que gestionar técnicamente al equipo, para lo cuál existen otras metodologías, como eXtreme Programming.

Hasta aquí el post de hoy. Espero que os haya gustado tanto como a mi cuando me lo mostraron.

PD: en miriadaX se está celebrando un curso de agilidad, lean, scrum y kanban, por si os pica el gusanillo, el cual está impartido por Javier Garzás.

Fuentes: 

- javiergarzas.com

- Master en Ingeniería en Sistemas de Información : Nuevas Tendencias en Sistemas de Información

- Ingeniería del Software : Procesos del Software

- MiriadaX.com