Que son eso de las metodologías ágiles

Ya hemos visto que entiendo por Business Intelligence, así que ahora le toca el turno al otro puntal de lo que debería ser el objetivo de este espacio: las metodologías ágiles.


En el Manifiesto Ágil se definen los cuatro valores por las que se deberían guiar las metodologías ágiles.

“ Estamos buscando mejores maneras para desarrollar software y ayudar a otros a desarrollarlo. En este trabajo valoramos:
· Al individuo y sus interacciones más que al proceso y las herramientas.
· Desarrollar software que funciona más que a obtener una buena documentación
· La colaboración con el cliente más que la negociación de un contrato.
· Responder a los cambios más que seguir una planificación.
De esta manera, mientras mayor valor tengamos en la parte derecha más apreciaremos los de la parte izquierda “

Manifiesto Ágil.

Firmado por Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas.

Veamos que significa cada uno de estos valores:

1) Al individuo y sus interacciones más que al proceso y las herramientas.

Sin duda la herramienta fundamental del desarrollo de sistemas decisionales es el cerebro humano. Unas jornadas maratonianas de 14 horas de trabajo van en detrimento de la calidad del producto final. Pero una persona sola no realiza un proyecto, necesita de un entorno en el que desarrollar su trabajo y de un equipo con el que colaborar. Estas interacciones deben también cuidarse. Un factor clave para el éxito es construir un buen equipo, que se lleve bien entre ellos, y que además sepan como construir su propio entorno de desarrollo. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte a él. Esto nos resta eficiencia, es mejor que el equipo lo configure en base a sus necesidades y sus características personales.

Además las interacciones que haga el equipo con el usuario final deberían ser igual de fluidas siendo este usuario un miembro más del equipo, con un objetivo común, que es conseguir que el proyecto funcione y sea útil para él.

Si todo esto funciona bien es obvio que la elección de las herramientas y el proceso mismo de desarrollo pasan a estar en un plano totalmente secundario en la ecuación del éxito del proyecto.

2) Desarrollar software que funciona más que a obtener una buena documentación

Uno de los objetivos de una buena documentación es poder ir a consultarla cuando haya que modificar algo del sistema. Sin duda es un arma de doble filo, una buena documentación actualizada en cada modificación y bien mantenida al día, te permite saber el estado de la aplicación y como realizar las modificaciones pertinentes, pero son pocos los que con las presiones externas de tiempo y dinero acaban actualizando la documentación.

En la filosofía ágil lo primordial es evitar estos fallos, la regla no escrita es no producir documentos superfluos, y solo producir aquellos que sean necesarios de forma inmediata para tomar una decisión importante durante el proceso de desarrollo. Estos documentos deben “ir al grano”, ser cortos y centrarse en lo fundamental, olvidándonos de los circunloquios que no aportan nada a la comprensión del problema.

3) La colaboración con el cliente más que la negociación de un contrato.

La consultoría informática de los últimos años se ha convertido en una lucha a muerte entre el proveedor del servicio y el cliente que lo contrata. Por una parte el cliente intenta que se hagan el mayor número de funcionalidades con el mismo dinero, por otra parte el consultor intenta que por ese dinero solo se realicen las funcionalidades contratadas inicialmente. En las reuniones de seguimiento de los proyecto es fácil oír frases del tipo “esta modificación no entra en el contrato” respondida generalmente por la tan típica “pues yo ya no tengo más presupuesto y así no podemos trabajar”. Al final este tipo de proyectos hacen que el consultor informático sea un híbrido entre analista y abogado. Desarrollando habilidades legales para salvaguardarse en caso de conflicto jurídico.
Sin embargo para que un proyecto tenga éxito la complicidad y el contacto continuo entre el cliente y el equipo de desarrollo es fundamental. El cliente debe ser y sentirse parte del equipo. De esta manera ambos entenderán las dificultades del otro y trabajarán de forma conjunta para solucionarlo.

4) Responder a los cambios más que seguir una planificación.

Una organización cambia constantemente, se adapta a las necesidades del mercado y reorganiza sus flujos de trabaja para ser mas eficiente. Es difícil pues, que en el desarrollo de un proyecto, este no sufra ningún cambio, pues es seguro que las necesidades de información de la empresa habrán cambiado y mas cuando se trata de sistemas decisionales, no siempre tomamos las decisones de la misma manera. . Son muchos los factores que alterarán nuestra planificación inicial del proyecto, si la adaptamos a estos cambios corremos el riesgo de que cuando acabemos, nuestra aplicación no sirva para nada y el cliente se haya gastado el dinero en vano. La habilidad de responder a los cambios de requisitos, tecnología, presupuestarios o estrategia, marca sin duda el camino del éxito del proyecto.

Como consecuencia de estos cuatro valores, el Manifiesto Ágil también enuncia los doce principios que caracterizan un proceso ágil diferenciándolo de otro tradicional en los que este enfoque no se había aplicado lo suficiente, siempre se había dejado implícito pero sin hacer hincapié en ellos.

I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor.
II. Dar la bienvenida a los cambios incluso al final del desarrollo. Los cambios le darán una ventaja competitiva a nuestro cliente.
III. Hacer entregas frecuentes de software que funcione, desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.
IV. Las personas del negocio y los desarrolladores deben trabajar juntos diariamente a lo largo de todo el proyecto.
V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos.
VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo.
VII. El software que funciona es la principal medida del progreso.
VIII. Los procesos ágiles promueven un desarrollo sostenido. Los promotores, usuarios y desarrolladores deben poder mantener un ritmo de trabajo constante de forma indefinida
IX. La atención continua a la calidad técnica y al buen diseño mejoran la agilidad.
X. La simplicidad es esencial. Se ha de saber maximizar el trabajo que NO se debe realizar.
XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos que se han organizado ellos mismos.
XII. En intervalos regulares, el equipo debe reflexionar con respecto a cómo llegar a ser más efectivo, y ajustar su comportamiento para conseguirlo.

Llegados a este punto podemos intuir que las formas de hacer las cosas están cambiando, adaptándose más a las personas y a las organizaciones en las que han de funcionar las aplicaciones.
Para completar todo esto os adjunto un link imprescindible http://agilemanifesto.org/

¿Estamos en la antesala de una revolución?. Posiblemente. ¿Pero podemos aplicar esta metodología a los sistemas decisionales o solo es aplicable a los sistemas operacionales?

Esa es mi gran duda.