Agile development: ¡así funciona!

El desarrollo ágil de software hace ya un tiempo que existe, pero también en otros ámbitos se han consolidado los métodos ágiles. No obstante, para muchos, el término aún no está muy claro. ¿Cómo diferenciar cuándo una empresa actúa según principios ágiles y cuándo aplica un método tradicional de trabajo adornado con una palabra de moda?

Ya en la década de los noventa, los equipos de desarrolladores de software comenzaron a trabajar con métodos que a día de hoy se consideran agile development. A finales del siglo XX, varios desarrolladores y equipos de software decidieron hacer más ligero, más light, el trabajo de programación, dándose a conocer el método con la palabra clave “lightweight”. Durante este periodo aparecieron también los métodos Scrum y Kanban, que por aquel entonces no podían englobarse bajo el concepto de agile development o desarrollo ágil, pues en ese momento aún no se había desarrollado.

En 2001 se puede encontrar el punto de inflexión: en este año se celebró una reunión, conocida en la actualidad como Snowbird meeting (nombre que hace referencia a las estaciones de esquí de Utah donde se produjo el encuentro), en la que 17 desarrolladores crearon el Agile Manifesto o Manifiesto por el desarrollo ágil de software: todos ellos presentaron sus respectivas experiencias en el desarrollo de software y en el trato conjunto con equipos, encontraron soluciones, establecieron principios y resumieron todo en el concepto de desarrollo ágil que hoy es sinónimo de métodos de trabajo modernos.

Trabajar de forma más flexible, creativa y productiva había sido siempre el objetivo, tanto cuando se empezaron a cuestionar los métodos de desarrollo de software a pequeña escala, como cuando se logró establecer una nueva forma de trabajo con el Manifiesto Ágil. A diferencia de otros métodos tradicionales, como por ejemplo el modelo en cascada, que sigue un proceso muy planificado, lineal y burocrático, en este caso el proyecto se pone en marcha con más facilidad. El desarrollo ágil otorga mucha más responsabilidad al equipo de programadores.

Además, prácticamente permite decir adiós a los proyectos de gran envergadura: en lugar de pasar meses o incluso años desarrollando un producto, los equipos ágiles necesitan solo unas pocas semanas para finalizar una fase de trabajo. Como resultado se obtiene un producto terminado, una actualización o una parte del programa que se puede presentar al cliente. Para obtener un buen resultado, el Manifiesto Ágil ha acordado doce principios y cuatro valores.

Los valores del desarrollo ágil de software establecen el enfoque que han de tener en cuenta los equipos en su trabajo de desarrollo. Se anotan como pares de opuestos: ambos aspectos son importantes, pero uno se antepone al otro en el desarrollo ágil:

• Individuos e interacciones sobre procesos y herramientas: las personas involucradas y su cooperación entre sí son más importantes que las cuestiones en torno a un proceso o herramienta en particular.
• Software funcional sobre documentación detallada: se busca conseguir un producto final que funcione. La documentación del trabajo tiene una importancia secundaria.
• Colaboración con el cliente sobre negociación contractual: el desarrollo ágil de productos está más enfocado a ajustarse al cliente y sus requisitos que a negociar contratos.
• Responder ante el cambio sobre seguir un plan establecido: el desarrollo de software debe responder a cambios constantes. Por ello, puede ser necesario anular un plan previamente definido.

Estos valores deben entenderse a modo de mantra. No proporcionan instrucciones detalladas, pero están diseñados para que los desarrolladores no olviden los aspectos más importantes de la producción: trabajar en equipo, concentrarse en el software, pensar en el cliente y ser flexible ante los cambios. Todas las demás facetas, sin duda también importantes, han de estar subordinadas a estos puntos.

Los doce principios del Manifiesto Ágil se asimilan más a instrucciones concretas. Estos proporcionan información adicional y amplían las ideas de los valores. Pero, incluso en este caso, no se trata de una guía como tal, pues no es ese el fin del manifiesto. Los principios son muy extensos y sirven para separar los métodos ágiles de los no ágiles.

• Satisfacción del cliente: con una publicación rápida y continua, conocida como entrega continua, el cliente ha de estar satisfecho en todo momento.
• Flexibilidad: los equipos ágiles siempre ven el cambio como algo positivo, incluso si tienen lugar al final del proceso de desarrollo. Siguiendo el Manifiesto Ágil, las adaptaciones a los requerimientos cambiantes ofrecen a los clientes una ventaja frente a la competencia.
• Entrega: el software operativo se entrega directamente en un plazo de unas pocas semanas o meses. Los plazos de entrega cortos son siempre bienvenidos.
• Trabajo en equipo: los desarrolladores y miembros del área de ventas tienen que trabajar mano a mano. El Manifiesto Ágil contempla reuniones diarias.
• Apoyo: para que los trabajadores desempeñen su tarea con motivación y los equipos trabajen de forma creativa, el ambiente debe ser el adecuado. Para ello necesitan el apoyo de los demás y, sobre todo, la confianza de sus superiores.
• Cultura de diálogo: para transmitir información de la manera más eficaz posible y sin malentendidos, lo mejor es la comunicación directa. Hablar cara a cara permite hacer preguntas y evitar conclusiones erróneas.
• Éxitos: el éxito de un equipo puede medirse sobre todo con la publicación de software funcional.
• Sostenibilidad: conviene que el desarrollo siga un proceso uniforme. Todos los participantes, y no solo los desarrolladores, deben continuar trabajando de forma constante en las entregas.
• Calidad: los desarrolladores siempre deben asegurarse de que sus productos cumplan con los estándares más altos, tanto desde el punto de vista técnico como en términos de diseño.
• Sencillez: el trabajo debe ser lo más simple posible. Eliminar lo superfluo conduce a un proceso más ágil y, por lo tanto, a mejores resultados.
• Organización: solo si se permite que los equipos se organicen por su cuenta, se pueden esperar resultados extraordinarios.
• Retrospectiva: un aspecto importante del desarrollo ágil de software es cuestionar los propios métodos cuando sea necesario. Para mejorar constantemente el trabajo del equipo, es importante que los miembros intercambien sus puntos de vista sobre la forma en que trabajan y que adapten sus acciones en consecuencia.

En el ámbito del agile development, se han establecido algunas prácticas con las que se puede implementar el enfoque ágil en tu equipo o empresa –el desarrollo ágil se convierte, así, en el término general. Muchas de estas técnicas se pueden encontrar en materializaciones del desarrollo ágil de software como, por ejemplo, Scrum, Kanban, programación extrema, desarrollo basado en funcionalidades, desarrollo guiado por comportamiento o Chrystal.

• Backlog: la idea de un catálogo que reúne todas las tareas que aún deben realizarse, pero en las que actualmente no se está trabajando, es indicativa del enfoque ágil. La razón de esto radica en las fases breves de trabajo. En lugar de ocuparse de varias tareas al mismo tiempo o de asignar un intervalo de tiempo fijo a cada tarea dentro de un plan determinado, se cuenta con una serie de tareas flexibles en segundo plano. A partir de esto, el equipo puede seleccionar la siguiente tarea.
• Retrospectiva: las reuniones regulares no solo están presentes en los métodos ágiles como un principio abstracto, sino que se fomentan en parte. Scrum, por ejemplo, incluso fija un plan de reuniones. Solo si el equipo no solo aborda los desafíos y problemas, sino también los logros, se puede conseguir una mejora a largo plazo.
• Historia de usuario: las historias de usuario sirven para asegurarse de que el cliente o el usuario está en el centro del desarrollo. Con esta técnica se recurre a un lenguaje sencillo para explicar brevemente lo que una función debe poder hacer desde la perspectiva del usuario. Esta descripción se anota en una tarjeta (story card) y con todas se elabora un mapa (story map).
• Agile testing: en el desarrollo ágil de software, las pruebas se consideran parte integral del proceso. Normalmente, al final de una iteración (fase de trabajo corta), el producto se prueba en equipo antes de que se considere “terminado” y se entregue al cliente. Solo entonces comenzará la siguiente iteración con una nueva tarea.
• Programación en pareja: el principio de los cuatro ojos encuentra aplicación en la programación en pareja, también conocida por su denominación en inglés pair programming. Dos desarrolladores comparten un espacio de trabajo. Mientras uno de ellos escribe el código, el otro verifica la entrada. Aunque esto conlleva más tiempo (el examinador podría estar escribiendo código también), pero reduce los errores en el código.
• Timeboxing: algunas formas de desarrollo ágil tienen restricciones de tiempo. Nuevamente, Scrum es un buen ejemplo de ello, ya que aquí los sprints tienen una longitud determinada. Al final, el equipo tiene que presentar un producto terminado. Esto requiere que las tareas se diseñen y seleccionen adecuadamente.

Hay muchas más técnicas encontradas en los métodos ágiles. Todas tienen en común el objetivo de hacer que el flujo de trabajo sea más efectivo y de aumentar la calidad del producto.

A sus defensores les gusta presentar el enfoque del desarrollo ágil de software como la única forma de desarrollar productos en la actualidad. Pero la agilidad no es la solución adecuada para todos los equipos y empresas. Dependiendo de la situación de la empresa, las desventajas pueden superar los beneficios.