Toda organización de desarrollo de software moderna parece practicar la metodología ágil (así le llamaremos en esta entrada de vez en cuando, aunque correctamente se dice «Agile»)de desarrollo de software, o una versión de la misma (o creen que lo hacen).
Si somos nuevos en el desarrollo de aplicaciones o aprendimos hace décadas sobre esto usando la metodología de desarrollo en cascada, hoy vuestro trabajo está al menos influenciado por la metodología ágil.
Agile se lanzó formalmente en 2001 cuando 17 tecnólogos redactaron el Agile Manifesto. En él se redactaron 4 principios fundamentales para el desarrollo de un mejor software:
- Individuos e interacciones sobre procesos y herramientas.
- Software de trabajo sobre documentación completa.
- Colaboración del cliente sobre la negociación del contrato.
- Responde al cambio sobre el siguiente plan.
¿Qué había antes de Agile? La metodología de cascada
Hace algunos años, la tecnología estándar para del desarrollo de software era la metodología en cascada. El proceso de desarrollo de software requería muchísima documentación por adelantado antes de realizar cualquier codificación. Alguien primero escribió un documento de requisitos comerciales que capturaba todo lo que la empresa necesitaba en la aplicación. Estos documentos eran largos y detallaban todo: especificaciones funcionales integrales de la estrategia y diseños de interfaz de usuario.
Este proceso en cascada finalmente iniciaría la codificación, luego la integración y finalmente las pruebas antes de que una aplicación se considerase lista para la producción. Todo este proceso podría llevar fácilmente un par de años.
Lo que se esperaba es que los desarrolladores supieran «la especificación» (la documentación completa) tan bien como los autores de esos documentos, y a menudo esto era contraproducente.
Otro problema estaba en las herramientas de desarrollo, que requerían una capacitación muy específica y en ocasiones eran muy limitadas y los equipos eran grandes, con lo que no había herramientas para todos.
Debido a que el software se desarrollaba en base a la arquitectura técnica, los artefactos de nivel inferior se desarrollaban primero y luego los dependientes. Las tareas eran designadas por habilidad y era común que los ingenieros de bases de datos construyeran primero las tablas y otros de base de datos y después, seguidos por los desarrolladores de aplicaciones que codificaban la funcionalidad y la lógica empresarial, para finalmente superponer la interfaz de usuario.
Comienza el cambio
La metodología en cascada comenzó a cambiar cuando los desarrolladores comenzaron a trabajar en aplicaciones de Internet. Gran parte del trabajo inicial se realizaba en startups donde los equipos eran más pequños, estaban ubicados y, a menudo, no tenían la experiencia en la informática tradicional. Hubo presiones financieras y competitivas para llevar sitios web, aplicaciones y nuevas capacidades al mercado de forma más rápida. La tecnología y las plataformas de desarrollo cambiaron rápidamente en respuesta.
Esto llevó a muchos a trabajar en startups y cuestionar los procesos de desarrollo tradicionales y a buscar formas de ser más eficientes. No se podía realizar toda la documentación de forma tan detallada, las organizaciones no podían estar tan estructuradas y las aplicaciones no podían ser tan complejas, por lo que con mayor frecuencia se apoyaba su fabricación en lugar de comprarlos.
Se comenzó a decir a los ingenieros cómo las aplicaciones de Internet necesitaban ser diseñadas y se entregaban los resultados en un cronograma que se elaboraba de forma iterativa. Resulta que los desarrolladores no eran tan malos en entregar lo que habían dicho que harían cuando se comprometían a ello en intervalos de una a cuatro semanas.
Los roles en la metodología Agile
Un proceso de desarrollo de software Agile siempre comienza definiendo a los usuarios y documentando una declaración de visión sobre el alcance de los problemas, oportunidades y valores a abordar. El propietario del producto captura esta visión y trabaja con uno o varios equipos multidisciplinares para cumplir con esa visión.
Usuario
Los procesos ágiles siempre comienzan con el usuario o cliente en mente. Hoy en día, a menudo se definen como personas de usuario para ilustrar diferentes roles en el workflow que el softeware admite o diferentes tipos de necesidades y comportamientos de los clientes.
Dueño del producto
Este proceso de desarrollo en sí comienza con alguien que debe ser la voz del cliente, incluidas las partes interesadas internas. Esta persona destila todas las ideas y comentarios para crear una visión del producto. Estas visiones son a menudo simples y cortas, pero sin embargo pintan una imagen de quién es el cliente, qué valores se están abordando y una estrategia de cómo abordarlos.
Esta persona es el «dueño del producto» y su responsabilidad es definir esta visión y luego trabajar con un equipo de desarrollo para hacerla realidad.
Para trabajar con el equipo de desarrollo, el propietario del producto desglosa la visión en una serie de historias de usuarios que detallan quién es el objetivo, qué problema se está resolviendo, por qué es importante y qué restricciones, además de los criterios de aceptación que definen la solución.
El equipo de desarrollo del software
En Agile, el equipo de desarrollo y las responsabilidades de sus miembros difieren de las del modelo tradicional.
Los equipos son multidisciplinares, compuestos por un grupo diverso de personas con habilidades para hacer el trabajo. Debido a que el enfoque está en entregar software de trabajo, el equipo tiene que completar aplicaciones de funcionamiento de extremo a extremo. Por lo tanto, la base de datos, la lógica de los negocios y la interfaz de usuario de parte de la aplicación se desarrollan y luego se muestran, aunque no toda la aplicación. Para hacer esto, se reúnen con frecuencia para asegurarse de que todos estén alineados sobre quién está haciendo qué y cómo se está desarrollando el software.