Metodologías ágiles para gestionar los proyectos y negocios del s. XXI

Cada vez son más los proyectos que siguen una metodología ágil (Scrum, XP, Crystal Clear, etc.).
Su crecimiento ha sido tal que este tipo de gestión es una práctica ya común en multitud de empresas y equipos de desarrollo software.
Los profesionales de la tecnología y del desarrollo software de hoy están obligados a conocer cómo se gestionan proyectos ágiles.


¿Qué es el desarrollo ágil de software?

El desarrollo ágil de software se refiere a métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requisitos y soluciones evolucionan con el tiempo según la necesidad del proyecto.
Así el trabajo es realizado mediante la colaboración de equipos auto-organizados y multidisciplinarios, inmersos en un proceso compartido de toma de decisiones a corto plazo.

Cada iteración del ciclo de vida incluye: planificación, análisis de requisitos, diseño, codificación, pruebas y documentación. Teniendo gran importancia el concepto de "Finalizado" (Done), ya que el objetivo de cada iteración no es agregar toda la funcionalidad para justificar el lanzamiento del producto al mercado, sino incrementar el valor por medio de "software que funciona" (sin errores). Fuente: Wikipedia

Construir software no es igual que construir un puente, un edificio o un coche.
Y ésto es así porque en ingeniería software, a diferencia de otras ingenierías tradicionales como la arquitectura, la industria o la ingeniería civil, no se puede separar tan claramente la fase de diseño de la de construcción.
Las ingenierías clásicas precisan mucho de un diseño previo a la construcción, el disponer de los planos del arquitecto siempre antes de empezar el edificio.
Los planos para construir son precisos y pocas veces varían, ya que la mayoría de los diseños de las ingenierías clásicas, arquitecturas, etc., pueden hacer un mayor uso de las matemáticas o la física.
Por tanto, existen dos actividades claramente diferenciadas: el diseño y la construcción.

Desde sus orígenes, la ingeniería del software intentó perseverantemente emular a las ingenierías clásicas.
Tener una fase de diseño muy separada de la codificación o lo que es lo mismo, que la codificación no comenzase hasta que terminase el diseño.
Que una vez que se hace un diseño éste no se modifique. De hecho, notaciones para "planos" como UML y ciclos de vida como el cascada puro (donde cada fase se hace una sola vez y no se pasa a la siguiente fase hasta que se termina la previa) nacieron con este objetivo.

En software, la experiencia nos dice que es muy difícil especificar los requisitos en una única y primera fase. Por la complejidad de muchas de las reglas de negocio que automatizamos cuando construimos software, es muy difícil saber qué software se quiere hasta que se trabaja en su implementación y se ven las primeras versiones o prototipos.

Otro aspecto a tener en cuenta es la diferente distribución de los costes del proyecto.

Por lo general, realizar un cambio en el producto final que construyen las ingenierías clásicas o la arquitectura es muy costoso en términos económicos.
Cambiar, por ejemplo, la posición de una columna en un edificio o realizar modificaciones a la estructura de un puente ya construido tiene un alto coste. Y de ahí que la arquitectura o las ingenierías clásicas pretendan lograr a toda costa diseños o planos de un alto nivel de detalle, que una vez que comience la fase de construcción no tengan que ser modificados.
Además, normalmente, en la arquitectura o en las ingenierías clásicas los costes de construir son muy elevados en comparación con los de diseñar. El coste del equipo de diseñadores es sustancialmente inferior al de la realización de la obra, del puente, edificio, etc.

Las anteriores pautas para costes no se comportan igual en el caso del software.
Por un lado, el software, por su naturaleza (y si se construye mínimamente bien), es más fácil de modificar. Cambiar líneas de código tiene menos impacto que cambiar los pilares de un edificio ya construido.
De ahí que existan numerosas propuestas que recomiendan construir rápido una versión software y modificarla evolutivamente (la técnica de refactorización trabaja sobre esta idea).
En software no existe esa división tan clara entre los costes del diseño y los de la construcción.

Diferenciar el cómo se construye software del cómo se construyen los productos físicos es uno de los pilares de las metodologías ágiles (M. Fowler, 2005).
Y es que en software, es frecuente que diseño y construcción muchas veces se solapen, y por ello se recomiende construir por iteraciones, por partes, y el uso de prototipos incrementales.

El ciclo de vida ágil es un ciclo de vida iterativo e incremental, con iteraciones cortas (semanas) y sin que dentro de cada iteración tenga porque haber fases lineales (tipo cascada).

Quizá el caso más popular es el de Scrum. Hace ya sus años, en el 85, y en la primera presentación oficial de Scrum, Ken Schwaber, uno de sus creadores, hablaba sobre el ciclo de vida de Scrum, y sus diferencias con los anteriores ciclos de vida.

Según comenta Ken Schwaber, el ciclo de vida en Cascada y el Espiral cierran el contexto y la entrega al inicio de un proyecto. La principal diferencia entre cascada, espiral e iterativo y los ciclos de vida ágiles, concretamente en Scrum, es que estos últimos asumen que el análisis, diseño, etc., de cada iteración o Sprint son impredecibles. Los Sprints, o iteraciones cortas, no son (o a priori no tienen porqué) lineales y son flexibles.
Pero cada metodología de las llamadas ágiles, FDD, Crystal, DSDM, XP, etc., matizará su ciclo de vida.

Un proyecto ágil lleva la iteración al extremo:

• Se busca dividir las tareas del proyecto software en incrementos de una corta duración (según la metodología ágil, típicamente entre 1 y 4 semanas).
• Cada iteración suele concluir con un prototipo operativo. Al final de cada incremento se obtiene un producto entregable que es revisado junto con el cliente, posibilitando la aparición de nuevos requisitos o la perfección de los existentes, reduciendo riesgos globales y permitiendo la adaptación rápida a los cambios.

Lo Principios Ágiles que diferencian un proceso ágil de uno tradicional son los siguientes:

• La prioridad es satisfacer al cliente mediante entregas tempranas y continuas de software que le aporten valor.
• Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva.
• Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.
• La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
• Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.
• 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.
• El software que funciona es la medida fundamental de progreso.
• Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante.
• La atención continua a la calidad técnica y al buen diseño mejora la agilidad.
• La simplicidad es esencial.
• Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos.
• En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según esto ajusta su comportamiento.

Extracto del curso "Agilidad y Lean. Gestionando los proyectos y negocios del s. XXI" impartido por Javier Garzás, profesor en la Universidad Rey Juan Carlos a través de la plataforma online MiríadaX

Certificado de participación: https://miriadax.net/files/10132/badge/66283a75-ef83-4738-915b-9a5a9244ed0f.pdf

Jose Maria Acuña Morgado - Desarrollador Web