Métodos ágiles.

Sin duda alguna, ser “ágil” es lo de hoy. Con esto, nos referimos a la capacidad para proveer respuestas rápidas y ser adaptables al cambio. Ambas cualidades siempre habían sido deseables, pero en el entorno de negocios actual son indispensables. Este requerimiento de agilidad en las empresas, gobiernos, y cualquier otra organización, provoca que el software (que a fin de cuentas es el motor del mundo actual) también deba ser desarrollado de manera ágil.

Las necesidades de un cliente pueden sufrir cambios importantes del momento de contratación de un proyecto de software, al momento de su entrega; y es mucho más importante satisfacer estas últimas que las primeras. Esto requiere procesos de software diferentes, que en lugar de rechazar los cambios, sean capaces de incorporarlos. Dichos procesos también deben:
• Producir versiones ejecutables del software en pocas semanas, con el fin de quedar bien con el cliente y obtener retroalimentación en cuanto al producto.
• Inventar soluciones sencillas, de tal forma que el impacto de los cambios se minimice.
• Mejorar la calidad del diseño de manera continua, haciendo que la siguiente iteración requiera menos esfuerzo que la actual.
• Probar desde temprano y de manera continua, para encontrar defectos antes de que tengan un alto impacto.

En los últimos años hemos visto surgir métodos que capturan y fomentan dichas prácticas, y en su conjunto son conocidos como métodos “Ágiles”. Algunos de estos cuentan con más de una década de existencia. Sin embargo, fue en el año 2001, cuando varios de sus creadores se reunieron para formar la “Alianza Ágil” y dar a conocer el “Manifiesto Ágil”, que define los valores en que se basan dichos métodos:
• Individuos e interacciones por encima de procesos y herramientas.
• Software funcional por encima de documentación abundante.
• Colaboración con los clientes por encima de negociación de contratos.
• Respuesta al cambio por encima de seguimiento a planes.

De acuerdo con Jim Highsmith y Alistair Cockburn, ambos miembros fundadores de dicha alianza, lo nuevo de estos métodos no son las prácticas que utilizan, sino su reconocimiento de la gente como principal factor de éxito de los proyectos. Adicionalmente, Cockburn define estos métodos como el uso de reglas “ligeras pero suficientes” y la aplicación de técnicas orientadas a las personas y su comunicación.

En las páginas siguientes conoceremos más sobre los métodos ágiles y su aplicación, y aprenderemos a distinguir entre los mitos y realidades asociados a estos.

eXtreme Programming (XP) www.extremeprogramming.org
XP es probablemente el método ágil que más atención ha recibido desde que fue dado a conocer en 1999 a través del libro “Extreme Programming Explained” de Kent Beck. XP está formado por valores, principios y prácticas. Las prácticas son actividades concretas que un equipo puede realizar día a día, mientras que los valores representan el conocimiento fundamental que sustenta dichas prácticas. Tanto los valores como las prácticas son necesarios, pero hay un gran espacio entre ambos. Esta brecha es cubierta por los principios. La edición actual de XP (2004) define cinco valores, catorce principios, trece prácticas primarias y once prácticas adicionales.

Los cinco valores son:
• Comunicación. La comunicación entre miembros del equipo y con clientes, se debe maximizar.
• Simplicidad. Usar la solución más sencilla que pueda funcionar.
• Retroalimentación. Siempre debe ser posible medir el producto que se está desarrollando, y conocer qué le falta para satisfacer los requerimientos.
• Coraje. Es necesario armarse de valor para incorporar cambios durante un proyecto. El coraje por sí sólo es peligroso, pero sustentado con comunicación, simplicidad y retroalimentación, es una herramienta poderosa.
• Respeto. Los valores anteriores implican respeto. Ninguna metodología puede funcionar mientras los miembros del equipo no se tengan respeto entre sí, ni al trabajo que realizan.

Entre las prácticas más significativas de XP están el diseño incremental, programación en pares (dos personas en una computadora), integración continua (cada dos horas), y test-first programming (antes de desarrollar código nuevo, debes crear las pruebas que van a verificar este código).

Scrum www.controlchaos.com
Scrum fue desarrollado durante los ochentas y noventas por Ken Schwaber, Jeff Sutherland y Mike Beedle. Este método se concentra en la administración de los proyectos de software, dividiendo el desarrollo en iteraciones de 30 días (denominadas “sprints”), y monitoreando/controlando el proyecto a través de juntas diarias. De hecho, “scrum” se refiere a la jugada en el rugby donde los jugadores trabajan en equipo para obtener posesión del balón.

Scrum aplica ideas de la teoría de control de procesos industriales con el objetivo de lograr adaptabilidad y productividad. Scrum no define actividades ni técnicas específicas para la construcción de software. En cambio, se concentra en las reglas de funcionamiento de un equipo de trabajo para poder producir sistemas flexibles en un ambiente de cambios.

Dado que Scrum hace poco énfasis en las actividades de ingeniería, es común complementarlo con otros métodos fuertes en cuanto a prácticas de ingeniería, como lo es XP.

Crystal
Crystal es una familia de métodos que comparten principios en común. Estos principios comunes, o “código genético” (como lo llama su creador Alistair Cockburn), se enfocan en las entregas frecuentes, la comunicación cercana y la mejora a través de la reflexión. Existen diferentes métodos Crystal para diferentes tipos de proyectos, y las organizaciones pueden personalizar un proceso específico para cada proyecto.

El nombre Crystal surge de la caracterización de los proyectos de software de acuerdo a su tamaño e importancia (criticality) del producto a desarrollar, de la misma forma que los cristales son caracterizados por su color y dureza. El tamaño del proyecto indica el método a utilizar —Crystal Clear es para equipos pequeños (menos de 8 personas), seguido por Yellow (10 a 20), Orange (20 a 50), y así sucesivamente hasta Violet—, mientras que la importancia indica la dureza con que se debe aplicar, esta va de cuarzo (quartz) hasta diamante (diamond).

Las prioridades que comparten todos los métodos de Crystal son:
• Seguridad en el desenlace del proyecto.
• Eficiencia en el desarrollo.
• Habitabilidad de las reglas (el equipo se siente cómodo con ellas).

El énfasis de las metodologías Crystal está en la comunicación y la cooperación entre las personas. De hecho, a diferencia de otros métodos que se centran en arquitectura, procesos, o incluso herramientas, podríamos decir que Crystal está “centrado en personas” (people-centric).

A pesar de su popularidad, no existe un sitio web que sirva como punto central para conocer más sobre Crystal. El sitio de Alistair Cockburn (alistair.cockburn.us) contiene referencias a algunos sitios y artículos, sin embargo la mejor fuente de conocimiento sobre Crystal es el libro titulado Crystal Clear, escrito por Cockburn y publicado por Addison Wesley en 2004.