Hace aproximadamente un año y en conjunto con nuestro cliente Inria Chile, fundación dedicada a la investigación, desarrollo y transferencia de tecnologías en el área de las ciencias y tecnologías de la información y comunicación, iniciamos el desafío de esquematizar un contrato de desarrollo de software que abordara las particularidades de las “metodologías ágiles”.
La creación de software utiliza metodologías que exigen poder reescribir una y otra vez las tareas y objetivos inicialmente acordados, siendo esenciales para este enfoque de trabajo la confianza y la colaboración con el cliente. Regular hitos, objetivos, tareas y plazos –como lo hace un contrato tradicional de desarrollo de software– no resulta útil ni conveniente, porque todos esos ítems se van modificando rápidamente con el avance del proyecto, con lo que pronto el contrato se vuelve un papel obsoleto, que no es más que un dolor de cabeza para los desarrolladores y el cliente.
A lo largo de tres artículos, expondremos el proceso que emprendimos con nuestro cliente Inria Chile para estructurar un contrato de desarrollo bajo metodologías ágiles, y en particular, la experiencia y conclusiones a las que llegamos tras utilizar las metodologías ágiles en el ejercicio mismo de diseño del contrato.
Para iniciar esta serie de artículos, comenzaremos por explicar, de forma muy breve, qué son las metodologías ágiles para el desarrollo de software y por qué han resultado más convenientes y son preferidas por los desarrolladores actualmente.
Breve reseña de las metodologías empleadas para el desarrollo de software
En sus albores, el desarrollo de software se realizaba de una forma más bien improvisada: Los desarrolladores tenían una idea del software que querían crear y comenzaban a escribir código para llegar a esa idea. Consecuentemente, los primeros contratos de desarrollo se limitaban a fijar un conjunto de características y funcionalidades deseadas y le daban un plazo al equipo de desarrollo para alcanzarlas.
Bajo una mirada retrospectiva, se le ha llamado a este antiguo esquema –con un tono irónico quizás– el modelo de desarrollo “big bang”, porque el contrato y la metodología (o más bien la ausencia de ella) se limitan a enumerar un conjunto de funcionalidades que se espera aparezcan “de la nada” en una fecha determinada. Este esquema tardó muy poco en dejar al descubierto sus graves falencias: Los desarrolladores se ponían a trabajar con un listado de funcionalidades deseadas, que muchas veces resultaban ambiguas y que por tanto había que interpretar. El proceso tampoco contaba con instancias de retroalimentación del cliente, ni menos de los usuarios finales del producto. Por todos estos factores, el resultado usualmente era el mismo: el día del estreno del producto los clientes generalmente quedaban insatisfechos con el resultado, dando lugar a conflictos entre las partes involucradas.
La industria del software se dio cuenta rápidamente de que era necesario implementar metodologías de planificación que permitieran hacer frente a estos problemas, y tomó prestadas las de otras ramas de la ingeniería, como la construcción, por ejemplo, articulando lo que se conoció como el modelo de desarrollo de software de “cascadas”, bajo el cual se dividen las diferentes etapas del proyecto y se van ejecutando una a una íntegramente. Por ejemplo: (i) identificación de los requerimientos y funcionalidades; (ii) diseño de la solución (iii) implementación (escritura del código); (iv) pruebas del software y (v) mantenimiento. Una vez que se termina una etapa se pasa a la siguiente sin mirar atrás.
Esta metodología predominó en la industria y en la academia durante los años ochenta y noventa, principalmente sostenida por la creencia de que una buena planificación en el inicio del proyecto haría más eficiente y exitoso el desarrollo.
Sin embargo, ya en los años ochenta se comenzaban a oír importantes críticas a este modelo. Algunos desarrolladores observaron que, durante el proceso, el equipo de desarrollo va aprendiendo constantemente, recibe retroalimentación de quien le encargó el desarrollo o de los futuros usuarios del software, corrige lineamientos que no estuvieron bien enfocados en el inicio e incluso descubre la necesidad de incorporar funcionalidades no contempladas al momento de la planificación y eliminar algunas que sí fueron consideradas en el comienzo.
Ninguno de estos elementos es recogido por el modelo de cascadas, que avanza etapa tras etapa de forma inexorable y sin mirar atrás, porque así mandan la planificación y las funcionalidades acordadas por las partes en el momento que se encargó el desarrollo. Volver una y otra vez a la etapa de “identificación de requerimientos” sería un contrasentido para el espíritu del modelo de cascadas pues su finalidad es, precisamente, ordenar cómo se avanza en el proyecto estableciendo etapas bien definidas.
Esta importante falencia del modelo comenzó a notarse en el producto resultante: El software terminado no recogía los requerimientos o funcionalidades que pudieron haber sido “descubiertos” en las últimas etapas del proyecto, y además, tenía usualmente un importante desfase con la tecnología de la época y las necesidades del negocio, pues había sido diseñado a partir de las ideas y la realidad de la época en que se realizaron las primeras etapas de la planificación de cascada, que en algunas ocasiones podía llegar a tener años de distancia con la fecha de lanzamiento del producto.
Con el correr de los años, los desarrolladores se fueron dando cuenta, entre otras cosas, de que: (i) es imposible reunir todos los requerimientos al principio de un proyecto, y que estos deben ser descubiertos en la marcha; (ii) los requisitos deben ser plasmados en un listado flexible, que admita modificaciones futuras, pues con seguridad irán cambiado con el avance del proyecto; y (iii) la metodología debe recoger el hecho de que siempre habrá más cosas por hacer que tiempo y dinero, por lo que debe incorporar mecanismos para ir cambiando las prioridades del desarrollo e ir usando eficientemente los recursos disponibles.
Para hacer frente a esta realidad, durante el año 2001 un grupo de importantes desarrolladores de software se reunió a diseñar un nuevo modelo de trabajo. El grupo, que se autodenominó la “Alianza Ágil” (The Agile Alliance) sentó las bases de este nuevo modelo en un breve documento que denominó el “Manifiesto ágil” y en una precisa enunciación de doce principios respecto a cómo debería estructurarse el desarrollo de software. En aquellos documentos, la Alianza recalcó la importancia de privilegiar conceptos como la colaboración con el cliente y la respuesta al cambio por sobre otros como la negociación contractual, la documentación técnica o el seguimiento estricto de planes. Desde su publicación a esta fecha, el manifiesto ha sido firmado por un creciente número de desarrolladores y sus principios han ido siendo adoptados con cada vez más fuerza en la industria del software.
Desde la publicación del manifiesto ágil a esta fecha han emergido numerosas metodologías de desarrollo, que pretenden recoger los principios antes enumerados (p. ej. metodología Scrum, programación extrema, desarrollo de software lean, entre otros). Aunque existen diferencias importantes entre unas y otras, todas comparten el principio de “responder al cambio por sobre seguir un plan”. Recoger este importante principio en los contratos que regulen el desarrollo de software bajo estas metodologías representa un desafío significativo.
En nuestro próximo artículo, abordaremos nuestros hallazgos tras este ejercicio y el producto final que resultó de dicho esfuerzo.