Surgidas principalmente durante los años 90 las metodologías ágiles marcaron un punto de quiebre en la definición y uso de procesos para desarrollo de software. Los conceptos “extremos” y con frecuencia contrapuestos a los establecidos hasta el momento por casi 20 años de estudios en ingeniería de software se extendieron como una inflamación provocando reacciones que fueron desde la idolatría irracional, pasando por el escepticismo prudente, hasta el rechazo categórico y creando una polémica que hoy en día no está zanjada completamente.
Lo que no se discute es que nadie quedó indiferente y hoy son una alternativa real para mejorar los procesos de software. El problema de la polémica es que las posiciones se han radicalizado tanto que las exageraciones y malas interpretaciones están a la orden del día, no sólo por parte de sus detractores sino también de sus promotores.
La idea de este artículo no es resolver la polémica, sino ofrecer algunas herramientas básicas para interpretar correctamente los principios de lo “ágil” de modo que permitan tomar alguna posición propia y descubrir si realmente estos conceptos pueden ser aprovechados en sus proyectos o su organización.
Lo “Ágil” por los “Agilistas”
Para empezar es bueno escuchar lo que dicen los agilistas sobre si mismos y para ello la mejor fuente es el “Manifiesto Ágil”, disponible en www.agilemanifesto.org. Esta es una declaración de los valores y principios que orientan a todas las metodologías ágiles. Fue publicado en 2001 cuando un grupo de creadores y practicantes de las metodologías ágiles más conocidas (XP, SCRUM, Crystal, ASD, FDD, DSDM y Lean Development) notaron que compartían conceptos y visiones y decidieron reunirse para crear un movimiento. Este movimiento se llamó la Alianza Ágil y su primer producto fue este Manifiesto, El mismo término “ágil” se acuñó en esta reunión. Antes de eso las metodologías eran conocidas, a veces despectivamente, como “livianas”.
El texto del Manifiesto dice:
“Estamos descubriendo mejores formas de desarrollar software al hacerlo y al ayudar a otros a hacerlo. A través de este trabajo hemos llegado a valorar:
- • A los individuos y sus interacciones por encima de los procesos y herramientas
• Software que funcione por encima de la documentación exhaustiva
• Colaboración con el cliente por encima de la negociación de contratos
• Capacidad de respuesta al cambio por encima de el seguimiento de un plan
Esto significa, que mientras reconocemos que hay valor en los elementos de la derecha, valoramos más los de la izquierda.”
Cada punto del manifiesto tiene una interpretación: así, en el primer párrafo, la palabra “descubriendo” indica que el grupo reconoce que no se tienen todas las respuestas y por otra parte al decir “al hacerlo...” se quiere indicar que esto se realiza a través de la práctica diaria en proyectos y no con base en estudios teóricos.
Después viene la declaración de valores. Cuando se lee resulta evidente por qué se desató la polémica considerando que se estatuyó sobre elementos fundamentales de la ingeniería de software tradicional (mejorar los procesos para mejorar los resultados, fuerte énfasis en la documentación, contratos, planes etc.). Así para los “agilistas” estos elementos son importantes en los proyectos pero siempre serían menos importantes que las personas y sus interacciones, el producto funcionando, la colaboración con el cliente y la respuesta versátil al cambio. Esto queda explícito en la oración que cierra el manifiesto.
Posteriormente, tenemos los principios que “realizan” los valores y determinan los elementos clave del desarrollo “ágil”. Por falta de espacio no puedo incluir aquí los 12 principios, pero entre los puntos más importantes están los siguientes:
• El objetivo fundamental es la satisfacción de las necesidades del cliente, por lo cual se aceptan los cambios que se consideren necesarios para dar más valor a las soluciones.
• El equipo debe generar un ambiente que permita responder efectivamente a tales cambios.
• El proceso de desarrollo es iterativo e incremental, tratando de entregar al final de cada iteración un producto que el cliente pueda usar, con preferencia por iteraciones cortas (de un par de semanas a un par de meses).
• El equipo es el principal factor de éxito. La gestión del proyecto se orienta a mantener el ambiente adecuado para el equipo, y a favorecer la comunicación frecuente y directa. Al equipo se le da la confianza y el poder de participar en la organización y toma de decisiones. El equipo se hace responsable de reflexionar sobre su desempeño y de promover mejoras a los esquemas de trabajo.
• El cliente se convierte en parte del equipo, incluyéndolo también en el círculo de comunicación frecuente y directa a lo largo de todo el proyecto.
La lista completa de principios también está disponible en www.agilemanifesto.org
Entendiendo lo Ágil
Lo “ágil” surge de reconocer por un lado que el desarrollo de software es una labor compleja que requiere de métodos para poderla llevar a buen término y por otro que los métodos que se venían aplicando ya no estaban siendo tan efectivos para lidiar con los nuevos retos a los que se enfrentaban los proyectos. Esto no significa que los métodos fueran malos sino que no eran apropiados y que la causa principal de esta situación es que los métodos eran demasiado “pesados”. Es decir, que el esfuerzo de mantener el proceso resultaba en una carga que hacía más lento el andar del equipo en vez de ser una herramienta en pro de la eficiencia del trabajo. Así se podía ir del extremo de no tener ningún proceso (el clásico caos) a tener un proceso excesivo más allá de las demandas reales del proyecto.
Lo ágil se sitúa en el justo medio, reconociendo la necesidad del proceso pero concediendo espacio al proceso “suficiente”: aquel que permite mantener control del trabajo y hacerlo más eficiente a un costo (esfuerzo) razonable.
Por lo mismo, los procesos ágiles si son “livianos”, ya que tienen por lo general menos prácticas, roles o actividades definidas y porque las definiciones de estos elementos de proceso son menos rigurosas y formales que en los métodos tradicionales. Este bajo formalismo es compensado dentro del mismo método ágil por prácticas de comunicación que aumentan la visibilidad sobre el proceso que se ejecuta. Un ejemplo de esto es la gestión de proyecto en SCRUM: el menor rigor de la planificación es compensado por seguimiento diario de actividades, y problemas y reestimación, también diaria, del esfuerzo pendiente.
Hay dos conclusiones importantes que podemos derivar: una es que el criterio de lo “suficiente” se puede usar como regla general en cada instancia de aplicación de lo ágil. Por ejemplo con la documentación: no se trata de no documentar, sino de documentar lo exclusivamente necesario. La segunda conclusión es que eventualmente las necesidades del proyecto pueden implicar procesos más rigurosos: un diseño liviano levantado en una pizarra al que se le toma una foto digital puede ser insuficiente en el desarrollo de un sistema de control de misiles. El ejemplo puede ser algo extremo pero revela la necesidad de que cada equipo determine el proceso que requiere su proyecto realizando las adaptaciones correspondientes. Esto también se traduce en que algunos de los métodos ágiles de definiciones conocidas (como Extreme Programming, por ejemplo) resulten inaplicables en ciertos tipos de proyecto.
Ampliando las Perspectivas
Hoy existen varias corrientes de evolución de lo ágil en actividad constante. Una destacable es la extensión de los valores, principios y prácticas a disciplinas más allá del desarrollo de software: gestión de proyectos y gestión organizacional por mencionar algunos. Otra muy importante es la que propone que los conceptos derivados de lo ágil y lo tradicional no son contradictorios sino complementarios. En lo personal comparto esta perspectiva y con base en ello hemos desarrollado e implementado métodos que usando prácticas ágiles cumplen con los requerimientos del modelo CMMI. En otra ocasión escribiré al respecto.
Para Profundizar
La mejor fuente para conocer más es el sitio de la alianza ágil (www.agilealliance.com), que tiene muchos vínculos valiosos a artículos, herramientas, eventos y grupos de noticias. Una buena lectura inicial es el artículo “The New Methodology” de Martin Fowler (www.martinfowler.com), uno de los firmantes originales del manifiesto y que contiene muchos vínculos interesantes.
Ya implementando, lo mejor suele ser usar parcial o totalmente algunos de los métodos ágiles conocidos. Mis favoritos y recomendados en ese sentido son SCRUM de Jeff Sutherland y Ken Schwaber y Crystal Clear de Alistair Cockburn. Para los interesados en el balance de métodos, un imperdible es el trabajo de nada menos que Barry Boehm y Richard Turner “Balancing Agility and Discipline”, publicado por Addison Wesley en el 2003. Por cierto, el Dr. Turner es Keynote Speaker invitado a SEPG LA en Guadalajara este año.
Acerca del autor
John Gómez es consultor senior en Practia Consulting Chile. Tiene más de 15 años de experiencia en desarrollo de software asumiendo roles de programador, diseñador, arquitecto y jefe de proyecto. Desde el año 2002 colabora con la implementación de prácticas ágiles en proyectos de desarrollo y ha dirigido proyectos de mejora basados en metodologías ágiles. Hoy John está a cargo de varios proyectos de mejora, incluyendo algunos orientados a obtener evaluaciones de CMMI niveles 2 y3.
jgomez@pragmaconsultores.com
- Log in to post comments