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.
 |
| Tracy Chapman en la portada de su álbum homónimo en 1988 (Elektra) |
Este post plantea, ¿porqué (r)evolucionar a Agile?
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.
Las 5 razones que considero más importantes son:
- 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 customerEfectivamente 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.
through early and continuous delivery
of valuable software."
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
 |
| Coste de los cambios en función de la etapa de un proyecto Waterfall |
Pero, el cambio es lo único constante.
Teniendo esto en cuenta, Agile, por su naturaleza iterativa permite proporcionar exactamente lo que el cliente espera. En cada iteración se entregan “minimal viable products” (MVP’s) que incrementan la funcionalidad 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.
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, sólo 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 sólo 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.
Este matiz obliga a incluir en Agile técnicas que en Waterfall son sólo 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
Y lo he dejado para el final conscientemente.
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.
¿Y a ti?, ¿qué razón te importa más?
REFERENCIAS
- 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" tocado en directo en 1988 en el concierto tributo a Nelson Mandela por su 70 cumpleaños.
No hay comentarios:
Publicar un comentario