¿Qué son las metodologías ágiles?

Definiciones
sábado, 20 de junio de 2015

Las metodologías ágiles van ganando popularidad en los proyectos informáticos y también en los proyectos de Business Intelligence que interesan a los amables lectores de este blog.

Este modo de trabajo resulta recomendable en aquellos proyectos donde se requiere flexibilidad y donde los requerimientos no son suficientemente conocidos al inicio del proyecto. ¿Os suena?

En este artículo intentaré exponer los principios y características de las metodologías ágiles.

Principios

Los principios tradicionales de las metodologías ágiles se definieron en 2001, en el conocido como "Manifiesto ágil", son cuatro:

  • Personas e interacciones en lugar de procesos y herramientas
  • Software funcionando en lugar de documentación detallada
  • Colaboración con el cliente en lugar de negociación del contrato
  • Responder al cambio en lugar de seguir un plan

El manifiesto defiende que aunque hay valor en los elementos de la derecha, se valoran más y se prefieren los elementos de la izquierda.

Mucha gente asocia esta metodologías ágiles con proyectos sin documentación o proyectos donde existe un control deficiente. Por supuesto, ambas cosas pueden ocurrir, como ocurren en todo tipo de proyectos, pero se trata de una visión simplista o directamente errónea. Lo que defienden estos principios es:

  • La importancia de un equipo fuerte técnicamente, motivado y que sepa coordinarse de manera eficiente y autónoma.
  • El objetivo de cualquier proyecto tecnológico no es documentar, ni siquiera analizar o diseñar el sistema. Lo importante es entregar una solución y que funcione. La documentación, el análisis y el diseño son solo medios para conseguir ese fin.
  • Firmar un contrato, por muy extenso y detallado que sea, nunca ofrecerá unos resultados comparables a la colaboración diaria de todo el equipo. En un proyecto de BI, es muy difícil que el cliente pueda definir los requerimientos con el detalle que un verdadero contrato requeriría. Por ese motivo, es mejor asumirlo, y trabajar con “alcances orientativos”. Por supuesto, para que esto sea posible, es necesario que los proyectos sean cortos y acotados (y no proyectos enormes que intenten abarcarlo todo).
  • Por último, pero no menos importante, las metodologías ágiles asumen que los requerimientos iniciales cambiarán. Los clientes nunca saben el uso que harán de la información disponible hasta que no lo tienen en su escritorio. Hemos de tener un modo de trabajo que permita responder con agilidad a este entorno cambiante.

Características principales

Hasta aquí, unos principios preciosos, pero poco nos dicen sobre cómo trabajar ágilmente. De hecho, existen varias "metodologías ágiles" que se suelen citar, y que cada equipo luego las adapta a sus propias necesidades de manera más o menos estricta.

Personalmente, destaco dos características que deben tener los proyectos ágiles:

  • Entrega frecuente de resultados. Organízate como quieras pero por favor entrega resultados frecuentemente para que el usuario pueda verlos y criticarlo cuanto antes. Olvídate de estar 3 meses diseñando, y 3 meses construyendo. Ni hablar. Hazlo de tal modo que cada 3 o 4 semanas puedas entregar algo de valor al cliente.
  • Simplicidad. Valorar las soluciones sencillas es esencial. Habitualmente, las soluciones excesivamente complejas esconden una pobre comprensión del problema. Además, por supuesto, dificultan exponencialmente el mantenimiento del sistema. El toque de simplicidad debe notarse en todas las áreas del proyecto. Desde las extracciones hasta los informes. Debe darse prioridad siempre a las soluciones sencillas frente a las complejas, a las soluciones automáticas frente a las que requieran un gran trabajo manual, etc. Esta exigencia de simplicidad puede implicar, incluso, la no realización de determinadas tareas o que estas sean pospuestas hasta que se aclaren los aspectos que generan la complejidad. La habilidad de detectar funcionalidades innecesarias es importante (y la falta de simplicidad suele ser un indicador de ello).

Volved a leer el artículo para certificar que no he dicho nada ni he definido ninguna metodología. Sería imposible hacerlo ya que la metodología adecuada en cada caso depende del cliente y de las características del proyecto. Sí que creo que las ideas aquí expuestas son importantes y hay que interiorizarlas para detectar cuanto antes que lo estás haciendo mal. La próxima vez que quieras protestar porque "el usuario no sabe lo que quiere", muérdete la lengua y dí esto otro con pose seria.

Como os amenace con un artículo semanal hasta final de año, podéis contar que volveré a hablar sobre metodologías ágiles, y específicamente sobre sus riesgos y dificultades. Afirmación - apertura.