Metodologías ágiles y desarrollo de software moderno

Las compañías necesitan crear software que esté a la altura de buenas experiencias digitales, y las metodologías ágiles son el medio para lograrlo.

La gran mayoría de las empresas tecnológicas implementa algún tipo de proceso de metodologías ágiles, o al menos algo parecido. Ya sean estos conceptos nuevos para vos o estés en el rubro del desarrollo de software hace décadas aplicando procesos tradicionales, es muy posible que hoy en día tu trabajo esté influenciado por metodologías ágiles.

¿Qué son las metodologías y cómo se aplican en desarrollo de software? ¿Cómo se diferencia agile de los procesos más tradicionales? ¿Cuál es el ciclo de vida o SDLC? ¿Qué es scrum o kanban?

Agile se lanzó formalmente en el año 2001 de la mano de un manifiesto escrito por algunos tecnólogos. Escribieron 4 principios con el objetivo de desarrollar mejor software:

  1. Las personas y las interacciones entre ellas por sobre los procesos y herramientas
  2. Software funcional por sobre documentación comprensible
  3. Colaboración con el cliente por sobre negociación de contratos
  4. Responder a los cambios por sobre seguir un plan

Procesos tradicionales: metodología en cascada

Quienes desarrollan software desde hace décadas seguramente hayan trabajado con la metodología en cascada.

Esta metodología requería mucha documentación de antemano antes de empezar a escribir código. Alguien del equipo, por lo general los analistas de negocio, escribían los requerimientos capturando todas las necesidades del negocio.

Como imaginarás, estos documentos eran muy largos y detallaban todo tipo de ítems: la estrategia en general, las especificaciones funcionales, y cuestiones básicas de los diseños de interfaces.

Los desarrolladores luego tomaban esta documentación y hacían su propia versión del documento con los requerimientos técnicos. De esta forma definían la arquitectura de la aplicación, las estructuras de datos, las interfaces, y otros requerimientos no funcionales.

Al finalizar esto, se comenzaba con el proceso de desarrollo, para luego para la integración, y por último testing. Lógicamente, el proceso completo solía llevar un par de años como mínimo.

¿Qué significa esto? Que los procesos eran completamente lineales. Hasta no terminar con una etapa y sus entregables, no se avanzaba.

Si por algún motivo una parte del proyecto se frenaba, todo el trabajo de desarrollo debía ser pausado a la par de este problema.

Además, como el proceso estaba 100% basado en aspectos funcionales y de negocio, algo que solía suceder en ciertos proyectos era la falta de validación con los clientes o usuarios.

De una forma u otra, se desarrollaban los productos “a ciegas”, siguiendo únicamente los requerimientos técnicos y funcionales, y se lograba obtener algún tipo de feedback del mercado únicamente con el producto en la calle, años después de haber comenzado a trabajar.

El pivot hacia el desarrollo de software ágil

La metodología cascada estaba basada en el proceso de fabricación de Henry Ford (1913), que le brindaba claridad a las fábricas en cuanto a qué paso a paso seguir para asegurarse de que el producto final estaba 100% alineado con las especificaciones.

El problema con este proceso se dio cuando los equipos comenzaron a trabajar en productos para internet, en pequeñas startups o compañías basadas en software, requiriendo procesos más iterativos y colaborativos, y contando con menos presupuesto para desarrollar productos.

De pronto se encontraron con el limitante de que no contaban con un año para documentar requerimientos técnicos y análisis funcional a nivel negocio.

En el año 2001, un grupo de desarrolladores comenzó a generar comunidad alrededor de la idea de que estaban desarrollando productos de una forma distinta a la metodología cascada. Y algunos de ellos no trabajaban en startups sino en compañías más tradicionales.

Este grupo creó el Manifiesto Agile documentando experiencias y filosofías sobre el desarrollo moderno de software.

Los roles en las metodologías ágiles

El proceso agile siempre comienza definiendo a los usuarios del producto y documentando una visión simple sobre los problemas, oportunidades y valores a trabajar. El PO (o Product Owner) se encarga de capturar esta visión y trabaja con varios equipos en simultáneo para lograrla. 

Usuario

Antes de comenzar a desarrollar un producto, debemos trabajar pensando en el usuario. Hoy en día se suele llamar al usuario como “user personas” o simplemente “personas” para ilustrar los distintos roles que pueden tener los flujos de navegación de un producto, siempre apoyados en las necesidades y comportamientos de estas personas.

PO o Product Owner

El proceso completo de desarrollo utilizando una metodología ágil comienza con una persona encargada de ser no sólo la voz del cliente, sino también de cualquier decisor interno. El rol de esta persona es aportar ideas y feedback, y principalmente mantener la visión del producto y mantenerla a lo largo de los verticales y equipos del proyecto.

La responsabilidad del PO es tener una visión clara a largo plazo del producto, y trabajar junto a los equipos de desarrollo para lograrla.

El PO será quien trabaje junto al equipo de desarrollo en las historias de usuario o user stories en las que detallarán quien es el usuario (según historia), qué problema podrá resolver, y cuáles son los criterios de aceptación para esa solución.

Equipo de desarrollo

En el mundo agile, cuando hablamos de “el equipo de desarrollo”, nos referimos a un grupo de personas multidisciplinarias y diversas, con las habilidades para desarrollar un producto que tenga un funcionamiento end-to-end.

Este equipo se compone no sólo de programadores (front y back), sino también de diseñadores UX/UI, especialistas en BBDDs, QAs, analistas funcionales, expertos en el negocio, entre otros.

Scrum, Kanban, y otros frameworks

Hay muchas metodologías ágiles que tienen un mismo objetivo pero a partir de distintos procesos de trabajo.

Una de las más populares (sino la más) es scrum. Se apoya en sprints y en estructuras de reuniones que incluyen:

  • Planning: donde se definen las prioridades del sprint
  • Review/Retro: donde el equipo ve los resultados del sprint anterior y pone en común los puntos a favor y a mejorar para próximos sprints
  • Dailys: llamados diarios y breves en los que los miembros del equipo se ponen al tanto del progreso del proyecto, día a día
  • Grooming: llamados de refinamiento para trabajar historias de usuarios, debatir temas, o revisar una lista de backlog y priorizar para próximos sprints, entre otros.

 

Los sprints terminan con la reunión de review, en donde se presenta al PO y equipo una demo funcional del producto, y la reunión de retro.

Las compañías que implementan scrum en el día a día suelen contar en sus equipos con scrum masters o expertos en scrum que no sólo puedan facilitar y conducir los scrums que se llevan a cabo, sino también entrenar al resto del equipo para hacerlo.

Si bien scrum es de los frameworks más populares, otras metodologías como kanban también son relevantes hoy en día.

¿Vale la pena implementar o seguir trabajando con agile?

Por lo general, siguiendo los principios de agile se obtienen mejores productos. Uno de los motivos principales tiene que ver con la flexibilidad y adaptabilidad que nos brinda el proceso. No es necesario definir el 100% de los puntos desde el comienzo, sino desgranar el problema y la necesidad del cliente en muchas partes que se puedan desarrollar de forma iterativa y validando con el usuario.

Además, los procesos agile alientan a los equipos a adoptar una actitud de mejora continua. El software está en constante necesidad de ser actualizado y optimizado, y los procesos agile que son iterativos por naturaleza nos permiten como equipo establecer una mentalidad de mejora continua.

Las compañías necesitan de software de alto nivel que les permita resolver procesos internos y brindar experiencias top notch a sus clientes, y lograrlo rápidamente y con el menor costo posible, y por ese motivo las metodologías ágiles son una excelente herramienta para lograrlo.