Cargando
5 razones para (r)evolucionar Agile

5 razones para (r)evolucionar Agile

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.

Empecemos aclarando ¿qué es Agile?

Agile es un framework 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.

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.

Metodologia AGILE: Scrum
Esquema Scrum, fuente: Wikipedia

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

El primer principio detrás del Manifesto Agile es:

«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

Agile vs Waterfall
Coste de los cambios en un proyecto tradicional

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.

Teniendo esto en cuenta, Agile, por su naturaleza iterativa permite proporcionar exactamente lo que el cliente espera. En cada iteración se entregan mejoras o nuevas funcionalidades que incrementan el valor del sistema además de permitir la mejora de lo entregado en iteraciones anteriores.

El resultado es la capacidad de aceptar e implementar los cambios reduciendo sus costes y manteniéndolos constantes a lo largo del proyecto.

CALIDAD

En Agile se busca integrar el control de la calidad en el propio proceso de desarrollo mientras que en Waterfall se hace en una etapa posterior. Además, en Agile, solo se mide el avance en base al software completado (desarrollado y funcionando) mientras que en Waterfall puedes finalizar la etapa de desarrollo con un software que no funcione.

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

Aplicando waterfall el riesgo de retrasos o defectos software se materializa en las últimas etapas de proyecto. Una vez el código ha sido entregado y arrancan las etapas de prueba y validación nos encontramos con defectos cuyo impacto puede ser:
  • 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.
Aplicando Agile logramos identificar estos riesgos mucho antes. Hay 2 factores que influyen:
  • 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.
En el mismo artículo Javier Garzás recuerda el famoso fiasco del software del Obama Care  y de como muchos (incluso en periódicos como el New York Times) apuntan el uso de Waterfall como la principal causa de ese fracaso.

VELOCIDAD – TIME TO MARKET

Y he dejado para el final lo que todos esperan ver al principio, el 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.

En Agile tampoco se puede desplegar en producción hasta que se encuentra listo pero la diferencia es que esto es cuestión de semanas (pocas). El enfoque incremental de Agile permite priorizar los requisitos que se abordan en cada iteración logrando disponer en mucho menos tiempo de aquellos aspectos que son más importantes para negocio. Esto enlaza de nuevo con el primer criterio: aportar valor a negocio.
Agile busca la entrega de software funcionando para el usuario.

CONCLUSIÓN

Llevo desde 2009 aplicando Agile y, sin ser un puritano del mismo, soy un seguidor 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
  • http://www.agilemanifesto.org/

TRACY CHAPMAN

Cantante y activista que logró sus mayores éxitos con canciones Folk a finales de los 80 y primera mitad de los 90.
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».

¿Interesante? Suscríbete, compártelo

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *