Translate

8/16/2015

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 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


Coste de los cambios en función
de la etapa de un proyecto Waterfall
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.


Pero, 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 “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.


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.


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.






0 comentarios :

Publicar un comentario