Bienvenidos a la #Agilidad: ¿Qué es?

21:11


Bienvenidos a la nueva sección de "Agilidad", "Agilismo", "Lo Ágil" en la que explicaré todo lo que tenga que ver sobre estas metodologías.

Tengo mucho conocimiento teórico adquirido y ahora estoy realizando las labores de Scrum Master en el trabajo, por lo que creo que es muy buen momento para ir hablando de este tema en este espacio que tanto quiero.

Estoy muy motivado e ilusionado de poder hablar de Agilidad y compartir con vosotros mis inquietudes. Mi mentor ha sido Javier Garzás, el mejor profesor de Metodologías Ágiles en castellano, al cual os invito a conocer asistiendo a alguna de sus ponencias. Por supuesto, dudo mucho que llegue a su nivel, por lo que si queréis informaros de este mundillo al máximo no dudéis en visitar su blog.

Y pensaréis...¿pero va hablar de SCRUM y pa' lante?. La respuesta es no, también voy a hablar de lo que hay detrás de este modo de ver las cosas pero con mi toque y mi visión personal, porque esto es un blog amig@s. Por supuesto que tendré mis errorcillos, por lo que estáis invitados a participar activamente escribiéndome mails o comentando para corregir posibles errores o aportar valor a la entrada.

Sin más dilación, comencemos en esta nueva aventura.

¿Qué es la agilidad?

Hasta hace muy poco en el mundo del software las cosas se hacían de una manera en concreto y además de forma generalizada. Los proyectos, los equipos y en definitiva, las personas, teníamos un sólo enfoque definido, pre-establecido y con pocas alternativas a la hora de programar aplicaciones. 

Creíamos que programar aplicaciones era como construir casas, es decir, teníamos un enfoque físico del proceso.

Además para poder empezar un proyecto software se creía que se debía tener un plano general de todo el proyecto incluso toda la documentación de cada una de las piezas antes de comenzar, por lo que se dice que son orientados a la predectibilidad, donde todo tiene que estar escrito, diseñado, documentado y firmado de inicio a fin. 

Además cada parte del desarrollo del proyecto estaba muy bien diferenciada, tanto que para cada etapa existían puestos de trabajo especializados

Y no sólo eso, el "papel" era el nexo de unión entre los distintos elementos del proceso, donde para pasar de una etapa a otra se debía generar una documentación extensa, justificando su fin y el comienzo de la siguiente.

A esta "manera" de hacer las cosas se les llama Metodologías en Cascada/Clásicas/Llave en Mano

Las siguientes diapositivas ilustran el proceso:


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: 
- Master en Ingeniería en Sistemas de Información : Nuevas Tendencias en Sistemas de Información
- Ingeniería del Software : Procesos del Software

You Might Also Like

0 comentarios

Sé respetuoso/a, en este blog caben todo tipo de opiniones con respeto y serenidad.

statistics :: ヽ(*・ω・)ノ

Contact Form :: (」゜ロ゜)」