¿Qué es la Metodología Ágil?

En este artículo, les voy a contar cómo decidimos dejar de seguir una metodología en cascada para seguir una metodología más ágil.

Una vez fuí contratada por una empresa que desarrollaba software y aplicaciones para otras empresas. En esta empresa, uno de mis primeros trabajos fue ayudar en el desarrollo de una aplicación que tenía como objetivo permitir que las personas encuentren restaurantes baratos cerca de donde ellas se encontraban.

Cuando conocí al equipo de desarrollo, me explicaron que seguían una estructura clásica: planificación, análisis, diseño, documentación, codificación, realizar testeos, implementar y, si es necesario, realizar el mantenimiento de la aplicación.

Esta es una metodología de desarrollo llamada en cascada, lo que significa que el proceso se lleva a cabo a través de fases y una de ellas solo se inicia cuando finaliza la anterior y, por lo tanto, no es necesario volver a un trabajo específico, visto que se ha completado totalmente.

Sin embargo, nos tomó mucho tiempo la etapa de planificación, análisis y documentación de todo el proyecto y el cliente estaba impaciente porque no habíamos mostrado nada nuevo hasta ese momento.

Además, lo que habíamos hecho no era material para presentarle al cliente, ya que la documentación es para consulta de analistas, arquitectos, desarrolladores y evaluadores del proyecto, es decir, absolutamente nada de eso agrega valor al cliente.

Luego, el cliente nos informó que el software ahora tenía un propósito diferente al inicial. Intentamos realizar los ajustes, sin embargo, después de analizar vimos que prácticamente tendríamos que planificar y empezar de nuevo toda la documentación. Consciente de todo el tiempo que demoramos en hacer la primera planificación, el cliente canceló todo el proyecto y perdimos ese trabajo.

A esa altura ya habíamos aprendido que ese método no funcionaba. ¿Y cuál fue nuestro error?

Agilidad

Comenzamos a pensar en formas de hacer que los próximos proyectos sean llevados a cabo más rápido. Entonces, decidimos no continuar con esta metodología en cascada y seguir una metodología más ágil.

Pero entonces, ¿Cómo podemos hacer eso? ¿Eliminar todas las reglas?

Con eso en mente, dividimos las tareas entre todos los miembros del equipo. Entonces, decidimos que cada persona tomaría una actividad definida para llevar a cabo en ese mes y desarrollaría sólo aquello.

Cuando comenzamos el proyecto, lo desarrollamos de esta manera: las tareas se dividieron y cada tarea se asignó a una persona que tenía más facilidad para desarrollarla.

Sin embargo, como el equipo se dividió, no sabíamos qué estaba haciendo cada uno y qué parte estaba lista o no. Esto, con el tiempo, comenzó a dejarnos confusos, sin saber en qué fase estábamos y cuándo podríamos comenzar a desarrollar otro requisito.

Y la situación empeoró cuando tocó presentarle al cliente, porque como no sabíamos el estado de cada etapa, algunas partes estaban completamente avanzadas y otras en estado inicial.

Sin mencionar que algunas personas estaban teniendo dificultades para realizar sus tareas, sin embargo, no podían pedir ayuda, ya que no había una comunicación entre el equipo.

Además, teníamos los requisitos, pero no sabíamos por qué eran necesarios y esto nos dejaba confundidos sobre cómo hacerlo de la mejor manera para el usuario.

Nos dimos cuenta de que un método sin reglas tampoco funcionaba. ¿Y cómo podríamos resolverlo? ¿Volver a las reglas que tampoco funcionaron?

Entonces, decidimos tratar de colocar algunas premisas que se cumplirían durante el proceso.

Foco en las personas y sus interacciones más que en los procesos y sus herramientas

Cuando nos dimos cuenta de que había un obstáculo para que el equipo se pueda comunicar de forma correcta, decidimos que deberíamos tener una mayor integración entre nosotros, a través de almuerzos y conversaciones durante el café.

Y, además, conocer el trabajo del otro, a través de reuniones donde cada uno podría decir lo que estaba haciendo, lo que iba a hacer a continuación y si tenía alguna dificultad o facilidad. En estas reuniones planificamos lo que haríamos a continuación, además de integrar a todo el equipo en el proceso de desarrollo.

Concordamos que los procesos y las herramientas son importantes, pero son realizados y utilizados por las personas del equipo. Por lo tanto, la interacción entre todos debe ser fluida y equilibrada para que la eficacia de los procesos y las herramientas se produzca sin mayores problemas.

Además, para cada requisito, en lugar de escribir lo que necesitamos hacer, por ejemplo, agregar un campo de búsqueda, escribimos cómo esto ayudará al usuario, por ejemplo, el usuario necesita buscar términos para encontrar las funciones del software de modo más rápido .

Software funcionando vale más que una documentación completa e integral

Como perdimos mucho tiempo con la documentación, decidimos que nuestro enfoque estaría más en el desarrollo, visto que agrega mucho valor al cliente.

Entonces, cuando recibimos un proyecto, analizamos cómo cada requisito puede ayudar al usuario y comenzamos a desarrollarlo.

De esta manera, tenemos menos trabajo con la documentación, ya que lo hacemos por partes, al mismo tiempo que desarrollamos el software y se lo presentamos al cliente.

Más colaboración con los clientes y menos interacciones para discutir negociaciones y contratos

También definimos que el cliente debería estar más presente en todo el proceso de desarrollo, evaluando lo que se ha hecho e indicándonos las próximas prioridades.

Además, de esta manera, si el proyecto necesita algo más, el cliente puede informarnos fácil y rápidamente, ya que el cliente es parte del proyecto y participa en cada etapa.

Para tener esta colaboración, a menudo programamos una reunión por mes con el cliente. En ella, mostraremos lo que se hizo, recibimos nuevas exigencias o cambios de las anteriores entregas de forma frecuente y sin tener que desechar todo el proyecto, porque, si hay algún cambio, lo sabremos pronto.

Responder y adaptarse a los cambios es más importante que seguir el plan inicial

Ya que las necesidades del cliente y del proyecto cambian, siempre debemos estar atentos. Entonces, en lugar de planificar todo el proyecto de una sola vez, ahora planificamos cada etapa individualmente y junto con el cliente.

Al tener este contacto más directo con el cliente y al desarrollar parte por parte, podemos adaptarnos a los cambios más rápidamente ya que tendremos que rediseñar solo una parte y no la totalidad.

Después de unos meses, esta nueva forma mostraba resultados debido a los beneficios que brindaba ese método, que entre ellos eran: satisfacción del cliente, mejor gestión de prioridades, mejor visibilidad de los proyectos, ya que todos sabían lo que estaba sucediendo; mayor productividad del equipo, ya que estaba más motivado por seguir un ritmo más saludable valorizando la objetividad y simpleza del sistema en desarrollo.

Fue cuando se contrató a un nuevo integrante para el equipo, así que le explicamos cómo habíamos organizado las tareas, respondió que era una metodología ágil, y que la forma en que lo hacíamos seguía los valores del manifiesto ágil.

Manifiesto ágil

El Manifiesto para el Desarrollo Ágil de Software fue escrito en 2001 por un grupo de 17 desarrolladores. Ellos agruparon y refinaron varios conceptos de metodología de desarrollo ágil en el manifiesto.

Estos conceptos iban en sentido contrario al método en cascada, es decir, rígido, donde se deben seguir las reglas y una orden específica, y contra el método sin regla ni definición, que se pierde. La metodología ágil está en el medio entre lo rígido y lo libre.

Este manifiesto tiene cuatro valores y doce principios que deben incluirse en la rutina de la empresa.

Los valores, que ya estábamos siguiendo son:

• Individuos e interacciones sobre procesos y herramientas
• Software funcionando sobre documentación extensiva
• Colaboración con el cliente sobre negociación contractual
• Respuesta ante el cambio sobre seguir un plan

Y no es que solo la parte antes del "más que" sea importante, sin embargo, es una prioridad más alta que lo que viene después.

Ahora, los principios detrás de los valores, que siempre deben tenerse en cuenta mientras se desarrolla el software, son:

• Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
• Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
• Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
• Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
• Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
• El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
• El software funcionando es la medida principal de progreso.
• Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
• La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
• La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
• Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
• A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

El manifiesto ágil es como una base filosófica para las metodologías ágiles y, en base a estos valores y principios, se han creado muchos. Entre ellos, Scrum, Kanban y EXtreme Programming, conocido como XP.

Ahora que nuestro equipo ya conoce los valores del manifiesto ágil, podemos utilizar algunas de las metodologías a seguir en el desarrollo del día a día.

¿Estás interesado en los métodos Agile y Scrum o quieres mejorar la gestión de equipos en tu empresa? ¡Consulta los cursos de Alura para guiarte en el proceso de convertirte en un experto en Agile y Scrum!