Metodologías Ágiles - Todo lo que hay que saber
¿Sirven realmente las metodologías ágiles? Las que no lo son, ¿están obsoletas? ¿Cómo sé si una metodología es ágil o no? ¿No será sólo una cuestión de moda? ¿Hay alguna otra metodología ágil que no sea Scrum? ¿Es un diagrama de Gantt algo totalmente incompatible con «agile»? Si mi visibilidad se limita únicamente a la siguiente iteración, ¿qué le respondo a mi jefe cuando me pregunta cuánto tardaremos o cuánto costará terminar el proyecto?
Si te has hecho alguna de estas preguntas, este artículo es para ti.
Lo primero que tienes que saber es que todas las metodologías para enmarcar las reglas con las cuales se lleva adelante un proyecto de cualquier tipo (aunque aquí me voy a referir sólo a proyectos informáticos) son buenas. Lo realmente malo es no usar una metodología.
Tradicionalmente, existían lo que comúnmente se conocía como metodologías estructuradas. Hace algunos años, comenzó a sonar mucho el término de metodologías ágiles.
La diferencia es muy sencilla de entender en líneas generales (para los entendidos, me voy a tomar varias licencias en este artículo con fines didácticos que pueden llegar a molestar a algunas mentes un poco más conservadoras o rigurosas).
Las primeras son más estrictas y apuntan casi todas ellas a llevar un riguroso control del avance y etapas del proyecto. Las últimas, por el contrario, son más flexibles y apuntan a generar resultados lo más frecuentemente posible, eliminando cualquier tarea que no sea necesaria para llegar a dicho resultado (como por ejemplo, la documentación).
Voy a tomar esto último como ejemplo para que quede claro. Digamos que tenemos que construir una versión X de una cierta funcionalidad de un sistema para dentro de una semana. Como el tiempo y los recursos son muy limitados, voy a eliminar todas aquellas tareas que no sean imprescindibles para lograr mi objetivo. Entonces me preguntaré: ¿puedo conseguir el objetivo planteado sin hacer un diagrama de clases de lo que voy a construir? La respuesta seguramente será que «Sí». Pues entonces, no lo hago. Si la respuesta es «NO» porque el algoritmo es muy complejo y necesito diagramarlo, entonces lo incluiré en las tareas a realizar, pero no porque sea correcto documentar todo, sino porque lo necesito para lograr mi objetivo.
Dicho lo anterior, es evidente por qué las metodologías ágiles tienen tanta difusión. Desde el punto de vista del cliente, éste gana en visibilidad porque obtiene versiones parciales del producto cada pocas semanas. El desarrollador puede concentrarse en lo importante (construir el producto) sin perder tiempo en tareas secundarias o improductivas.
Otra característica muy importante de este tipo de metodologías es la flexibilidad. Esto es porque se planifican sólo las tareas de la siguiente iteración (o ciclo de desarrollo), cuya duración es de 2 a 3 semanas (en general), por lo que cualquier error en el rumbo del proyecto no puede exceder ese plazo, por lo que es muy poco costoso cambiar de rumbo si cambiaron las condiciones del mercado o el entorno del cual el producto depende.
Una consecuencia negativa de este tipo de planificación de corto plazo es que se pierde la visión global o de conjunto del proyecto. No conozco a un solo jefe (que sea responsable del presupuesto a gastar) que no quiera saber el tiempo/costo total del proyecto (si tu conoces a alguno, por favor me lo presentas).
Aquí viene la primera licencia o trampita que todos los project manager hacemos con las metodologías ágiles: hacemos un plan global (en general un Gantt) y lo escondemos para que los fanáticos de Scrum no se ofendan.
Si me has seguido hasta aquí, entenderás por qué son tan atractivas las metodologías ágiles, pero que tampoco son la respuesta a todos los problemas. Una metodología ágil agiliza los ciclos de desarrollo, pero a veces se necesita mezclar un poco con otras herramientas más propias de otras metodologías.
Pongamos otro ejemplo. Digamos que tienes que construir en la siguiente iteración de 3 semanas una funcionalidad (una página web) que es el núcleo de todo el sistema, por lo cual no sólo es compleja por la cantidad de información que maneja, sino que tiene varios requisitos de usabilidad, rendimiento y seguridad. En general, eso implicará tareas de diseñadores, personal de UX, técnicos que definan una buena arquitectura, gente de seguridad informática, el usuario que apruebe el formato y uso de la página, etc.
Es verdad que esto puede hacerse perfectamente con Scrum si el equipo es lo suficientemente experimentado. Pero también podría planificarse una iteración que sea un poco más «estructurada» (perdón por la palabra). Digamos que, como PM (project manager) a cargo del equipo me tomo la licencia de empezar a agregar dependencias y establecer circuitos internos dentro de la iteración, para que un desarrollador no decida codificar algo que el usuario no haya aprobado previamente, o de una forma que seguridad informática no lo autorice. ¿Piensas que estaría mal hacer algo así? Si ello contribuye a cumplir con el objetivo planteado, aunque vaya en contra del manifiesto de Scrum, yo lo haría.
¿Cuál es entonces la conclusión? La conclusión es que el objetivo de todo PM es llevar el proyecto adelante, cumplir con los requerimientos planteados en tiempo y forma, dentro de los costos establecidos. El objetivo no es ser estricto con la metodología, sino ordenado, pero lo suficientemente flexible para cumplir con tu trabajo.
A lo largo de este artículo, utilicé ejemplos de Scrum porque es la más difundida de todas las metodologías ágiles (siendo estrictos, Scrum es un framework, no una metodología, aunque la diferencia es demasiado sutil para mi gusto). Sin embargo, no es la única (podemos nombrar Kanban o XP si quieren Googlearlas). En cuanto a metodologías estructuradas, hay muchísimas (desarrollo en cascada, prototipado evolutivo, CMMI, etc.).
Habrás notado que no he explicado ninguna de esas metodologías o ciclos de vida de proyectos ni comparé sus diferencias, pros y contras. Todo eso lo encuentras en la web. Mi objetivo fue darte una visión un poco más amplia y general del problema. No te ates a una única metodología, ya que cada organización es un mundo y cada proyecto tiene su naturaleza propia que lo hace único en algún sentido. Sé abierto al momento de decidir cómo llevar adelante un proyecto y trata de elegir unas herramientas de gestión que te permitan ejercer esa flexibilidad.
