Hoy en día, parece que todas las empresas dedicadas al desarrollo de software practican la metodología del desarrollo ágil o alguna versión de ésta. O al menos así lo creen. Pero, ¿qué es exactamente la metodología ágil y cómo debería practicarse en el desarrollo del software?
Lo ágil fue lanzado oficialmente en 2001 cuando 17 tecnologías redactaron el Manifiesto ágil. Entonces se escribieron cuatro principios fundamentales para desarrollar mejores programas de software:
- Individuos e interacciones por encima de procesos y herramientas.
- Software funcionando por encima de documentación extensiva.
- Colaboración con el cliente por encima de negociación contractual.
- Respuesta ante el cambio por encima de seguir un plan.
Antes de lo ágil, la metodología en cascada
Los veteranos como yo recordamos los días en los que la metodología en cascada era la regla de oro del desarrollo del software; requería mucha documentación de antemano antes de programar algo.
El proceso de desarrollo de software en cascada terminaba con la programación, luego la integración y finalmente un periodo de prueba antes de decidir que la aplicación estaba preparada. El proceso completo podía llevar perfectamente un par de años.
En su descargo, la metodología en cascada –inventada en 1970– fue revolucionaria porque introdujo disciplina en el desarrollo de software, asegurando que todo el mundo siguiese especificaciones claras. Se basaba en el método de la cadena de montaje de Henry Ford de 1913, la cual garantizaba que el producto final fuera como se esperaba.
Pero en 2001, un grupo de desarrolladores de software experimentados se reunieron y se dieron cuenta de que estaban practicando un desarrollo de software distinto al de la metodología clásica en cascada. Y no todos trabajaban en startups.
Este grupo escribió el Manifiesto ágil, el cual documentaba sus ideas sobre cómo debería ser el proceso del desarrollo de software moderno. Daban más importancia a la colaboración que a la documentación, a la autoorganización que a las prácticas de gestión rígidas y más a la habilidad de gestionar el cambio constante que a ceñirse a proceso de desarrollo rígidos en cascada. El desarrollo de software con metodologías ágiles surgió con estos principios.
Los roles de la metodología ágil
Un proceso de desarrollo de software ágil siempre comienza definiendo a los usuarios y estableciendo una declaración de principios con los problemas, oportunidades y valores a tratar. El propietario del producto captura esa visión y trabaja con un equipo (o equipos) multidisciplinarios para darle forma. Los roles de ese proceso son:
- Usuario: Los procesos ágiles siempre comienzan pensando en el usuario o cliente. Actualmente se suele definir a través de usuarios a personas que ilustran los diferentes roles que soporta el software o los diferentes tipos de necesidades y comportamientos de los clientes.
- Propietario del producto: El proceso de desarrollo ágil empieza con alguien que debe ser la voz del cliente, incluyendo a todos los interlocutores internos. Esa persona sintetiza conceptos, ideas y opiniones para crear una visión del producto. Tales visiones suelen ser breves y sencillas, pero indican quién es el cliente, qué valores importan y la estrategia para enfocarlos.
- El equipo de desarrollo de software: En una metodología ágil, los equipos son multidisciplinarios, compuestos por un grupo diverso de gente con las habilidades para hacer bien el trabajo. Como el objetivo es entregar un software que funcione, el equipo debe crear aplicaciones integrales que funcionen. Así que se desarrolla la base de datos, la lógica comercial y la interfaz de usuario y luego una demo, no la aplicación completa.
Scrum, Kanban y otros ‘frameworks’ ágiles
Existen muchos frameworks ágiles que proporcionan detalles sobre los procesos de desarrollo y las prácticas de desarrollo ágiles, alineados al ciclo de vida del desarrollo de software.
El framework ágil más popular es Scrum. Se centra en una cadencia de entrega llamada sprint y en cumplir con estructuras que incluyen: planificación (en la que se identifican las prioridades del sprint); compromiso (en la que el equipo revisa la lista o la acumulación de historias de usuario y decide cuánto trabajo se puede hacer durante la duración del sprint); reuniones diarias (para que los equipos puedan comunicar las actualizaciones de estatus y estrategias de desarrollo).
Por qué la metodología ágil es mejor
La razón principal es que lo ágil está diseñado pensando en la flexibilidad y la adaptabilidad. No se definen todas las respuestas de antemano, como el método en cascada, sino que se desglosa el problema en componentes más digeribles y luego se desarrolla y prueba con usuarios.
Si algo no funciona bien o como era de esperar, o si el esfuerzo revela algo en lo que no se había pensado, es posible adaptarse rápidamente para recuperar el rumbo. Lo ágil permite que cada uno de los miembros del equipo contribuya a la solución y exige que todos se responsabilicen de su trabajo.
Para terminar, el desarrollo ágil es mejor porque las personas del equipo son más productivas y están más contentas trabajando así.
Los ingenieros opinan sobre cuánto trabajo hacen y se sienten orgullosos de mostrar sus resultados. A los propietarios del producto les gusta ver su visión transformada en software antes, y ser capaces de hacer cambios basados en sus últimas ideas. A los usuarios les gusta que el software haga lo que realmente necesitan de una manera que encaje con sus procesos, o que los mejore.
Hoy en día, las empresas necesitan competencia de software para ofrecer buenas experiencias digitales y grandes experiencias de cliente en un mundo altamente competitivo. Y para ello necesitan atraer y mantener el talento. El desarrollo ágil es una buena alternativa para que las empresas lleguen allí.
_________________
Issac Sacolick es el autor del libro y eBook Diving Digital: The Leader’s Guide to Business Transformation through Technology, y es un CIO social reconocido, bloguero desde hace años en Social, Agile and Transformation, y CIO.com, además de ser Presidente de StarCIO.
