Algunas estadísticas dicen que el 73% de las empresas consideran que están aplicando Agile en diferentes estadios pero la realidad es que son muy pocas (y menos las grandes empresas) que realmente lo estén aplicando correctamente.
¿QUÉ ES AGILE (DESARROLLO ÁGIL O AGILISMO)?
Agilismo es un conjunto de frameworks de desarrollo software, no una metodología, capaz de adaptarse a las necesidades del proyecto, el equipo y sus circunstancias.
Los frameworks Agile se basan en el desarrollo iterativo e incremental en los que los requisitos (historias de usuario) evolucionan a lo largo del tiempo. Otra característica es que los equipos ágiles son autoorganizados y multidisciplinares.
MANIFIESTO AGILE
En Febrero de 2001, 17 desarrolladores de software críticos con la forma en la que en aquel momento trabajábamos la mayor parte de los profesionales se unieron para cambiarnos las reglas. Desconozco si en 2001 eran conscientes del enorme impacto que aquel cónclave tendría pero el resultado fue su manifiesto Agile para el desarrollo de software.
Su manifiesto prioriza:
• Personas e interacciones sobre procesos y herramientas
• Software funcionando sobre documentación
• Colaboración con usuarios sobre negociación de contratos
• Respuesta al cambio sobre cumplimiento de plan
Para lo cual plantean los siguientes 12 principios del desarrollo de software Ágil:
• 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.
FRAMEWORKS AGILE
Existen diferentes frameworks de trabajo ágiles entre los que los más extendidos son Scrum, Kanban y Extreme Programming. A continuación incluyo un esquema del proceso típico de un proceso Scrum.
En el ejemplo del diagrama anterior partimos de un Backlog de requisitos que son encajados, en función de su prioridad y dificultad, en Sprints de 30 días. Cada día se revisan los avances, tareas del día y riesgos en una sesión rápida con el objetivo de facilitar que el final del Sprint se posible entregar valor al usuario. Este valor es un incremento del Software existente.
Los frameworks Agile no solo pueden ser aplicados al desarrollo del software sino a gran parte de los procesos de una empresa. Cabe destacar que Lean Startup herede de Agile una parte importante de sus principios. Si te interesa puedes ver más detalle en «Lean Startup: sentido común«.
Como cantaba Tracy Chapman, «we’re talkin’ bout a revolution»:
«Don’t you know
They’re talkin’ bout a revolution
It sounds like a whisper(…)
«Don’t you know
You better run, run, run»
En esta línea el pasado 7 Julio, Javier Garzás publicaba un artículo titulado “Hay mejores formas de desarrollar software” en el que hablaba de Agilidad.
En el artículo Javier destacaba que Agile no es nada nuevo, la mayor parte de las prácticas tienen más de 20 años, y finalizaba el artículo con los siguientes párrafos:
“Así, la agilidad está marcando hoy un nuevo salto evolutivo en el desarrollo software«
(…)
«Un salto evolutivo como el que en su día supuso la programación estructurada, las BBDD relacionales o la OO» (…) «hubo quien supo aprovecharse del salto y quien no supo evolucionar, y a día de hoy» (…) «nadie discute.”
Estoy de acuerdo.
Agile supone un salto y una oportunidad. Debemos aprovecharla y, para hacerlo, primero es ser consciente de la necesidad y oportunidad que supone.
Por mi experiencia, destacaría 5 razones que justifican la evolución a Agile:
- Mayor valor para negocio
- Gestión del cambio
- Calidad del Software
- Riesgo del Proyecto
- Velocidad (entendida como Time to Market)
A continuación describo cada una de estas razones.
MAYOR VALOR PARA NEGOCIO
«Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.»
Efectivamente el objetivo debe ser proporcionar a valor a negocio lo antes posible. Para eso se priorizan las historias de usuario en función del valor que aportan y se ejecutan siguiendo esta priorización.
En un estudio también de Julio de la ScrumAlliance se entrevistaba a casi 4.500 profesionales que actualmente están empleando Scrum. Una de las preguntas era: ¿cuales son tus objetivos al aplicar Scrum? La respuesta mayoritaria era la «Entrega de Valor a Negocio».
Aquí tenéis un enlace a un post anterior «El estado del arte en SCRUM en 2015» con un resumen de dicho estudio.
REACCIÓN AL CAMBIO
Los modelos tradicionales de desarrollo (waterfall) están pensados para minimizar los riesgos poniendo barreras a la necesidad de cambios. La teoría es que si algo está suficientemente bien definido, no será necesario cambiarlo. De esta forma el coste de los cambios crece según evoluciona un proyecto.
Porque el cambio es lo único constante.
Además, el grado de incertidumbre de los requisitos se reduce según se pasan etapas del proyecto. Cuando tratamos de decidirlo todo es cuando mayor grado de incertidumbre hay.
El resultado es la capacidad de aceptar e implementar los cambios reduciendo sus costes y manteniéndolos constantes a lo largo del proyecto.
CALIDAD
Este matiz obliga a incluir en Agile técnicas que en Waterfall son solo opcionales. Esas técnicas incluyen la gestión del código (que un equipo Agile debe tener mucho más madura), la integración contínua, pruebas automatizadas o análisis de calidad automatizadas.
Además, en Agile se incorpora el desarrollo guiado por pruebas (TDD) o guiado por pruebas de aceptación (ATDD) que garantizan que el software desarrollado cumple con los criterios de aceptación definidos por los propios usuarios.
Finalmente no podemos olvidar que uno de los objetivos de calidad de cualquier proyecto o servicio debe ser la satisfacción del cliente. En ese sentido, el planteamiento incremental e iterativo de Agile facilita el alineamiento en las expectativas y, por tanto, en la satisfacción final.
RIESGO
- Retraso en plazos: si no es viable resolver los defectos graves en los plazos necesarios para el cumplimiento de la planificación.
- Despliegue con defectos: si la fecha de lanzamiento es inamovible y tenemos defectos pendientes de resolver y reprobar.
- Los mecanismos de calidad descritos arriba (que la práctica de Agile implica y en waterfall son opcionales)
- La naturaleza iterativa e incremental que garantiza que dispondremos de la funcionalidad más importante para negocio mucho antes en producción por lo que los riesgos de “big bang” final desaparecen.
- En Agile en cada iteración analizaremos los resultados, buscaremos los puntos mejorables y aplicaremos mejoras en la siguiente iteración.
VELOCIDAD – TIME TO MARKET
En un Proyecto clásico el software no puede ser implantado en producción hasta que es entregado y estable (después de las pruebas de aceptación finales). Desde el momento en que se inicia la toma de requisitos hasta que el software está listo para su implantación pueden pasar meses.
CONCLUSIÓN
Llevo desde 2009 aplicando Agile y, sin ser un puritano del mismo, soy un convencido.
Destacaría que Agile permite la adaptación de los frameworks a las diferentes circunstancias de proyectos, equipos, usuarios, etc. Esa capacidad de adaptación permite su aplicación a todo tipo de proyectos, los locales, los globales, los grandes, los pequeños, …
¿Y tú?, ¿cuándo piensas (r)evolucionar a Agile?
REFERENCIAS
- Lean Startup: Sentido Común
- El estado del arte en SCRUM en 2015
- Scrum y XP desde las trincheras por Henrik Kniberg
- Revista Española de Innovación, Calidad e Ingeniería del Software, Vol.5, No. 3, 2009: «Las metodologías ágiles como garantía de calidad del software» por José Ramón Díaz
- Computing, 7 Julio 2015: «Hay mejores formas de desarrollar software» por Javier Garzás
- The 2015 State of Scrum Report by ScrumAlliance.org
- https://agilemanifesto.org/
TRACY CHAPMAN
Destacó su álbum homónimo de 1988 «Tracy Chapman» que incluía las canciones «Fast Car» y «Talkin’ Bout a Revolution». Tracy ha ganado 4 premios Grammy (3 de ellos en 1989).
Os dejo con «Talkin’ Bout a Revolution».
