Surgen muchas dudas siempre sobre qué metodología sería la más adecuada de utilizar a la hora de comenzar un nuevo proyecto de software. Es cierto que desde la creación del manifiesto ágil(1), el 12 de febrero de 2001, se comenzaron a utilizar las metodologías ágiles en la mayoría de proyectos que iniciaban en nuestra industria. En internet hay infinidad de artículos relacionados, la mayoría hablando de lo mismo, y sin embargo ninguno despeja la mayoría de las dudas sobre si realmente es correcto el uso por defecto de este tipo de metodologías.
En este artículo se hablará sobre el uso de las metodologías ágiles en diferentes tipos de proyectos IT, además de extender las miras y ver que existen otras metodologías diferentes a estas. También la idea es dar a conocer los riesgos del mal uso de las metodologías ágiles en proyectos "delicados".
¿Qué son las metodologías ágiles? ¿Para qué sirven? ¿Merece la pena utilizarlas como marco de trabajo? ¿Las puedo utilizar en mi proyecto? ¿Qué roles son necesarios? ¿Qué ceremonias se han de realizar para cumplir con la metodología?
Éstas son algunas de las preguntas que pueden surgir, muchas de sus respuestas se pueden encontrar en diversidad de artículos por internet, la mayoría indicando que estas metodologías son el futuro y la evolución de otras que ya existían antes de llegar estas. A modo de introducción a las respuestas:
Como más adelante se indica, no es sencillo distinguir cuándo sale realmente rentable el uso de una metodología ágil, ya que hay que saber cuándo utilizarlas y cuando no.
¿Y qué es lo básico? ¿Decir que la utilizas en tu proyecto, hacer reuniones periódicas porque lo dicen libros o artículos que hablan de la metodología y olvidarte de lo que realmente te puede llegar a aportar el utilizarla? La verdad es que esto sería un gran error. Hay muchas ocasiones en las que este tipo de metodologías no se aplican correctamente. Hoy en día, muchos de los gurús que firmaron originalmente el manifiesto ágil, se arrepienten de haberlo hecho por la falta de comprensión y desconocimiento de las mismas por parte de multitud de equipos de desarrollo(2). ¿Y qué pueden aportar realmente estas metodologías? Pues permiten la adaptabilidad y el aprendizaje continuo de quienes conforman el equipo de desarrollo, aunque para su correcta implementación, según lo acordado en el manifiesto ágil, se exige que estos partan ya con una buena base previa de conocimientos al inicio del proyecto. Se pueden utilizar bien y generar un increíble ambiente de trabajo además de mantener contento al product owner de forma constante, aunque por dar algo más aterrizado en forma de ejemplos, el uso de estas metodologías podría ofrecer los beneficios de:
Una vez que entras, se abre un mundo de posibilidades, si no entras, no es algo que tenga mucho sentido decir que estás utilizando en tu proyecto ya que realmente no lo estás haciendo. Para utilizar estas metodologías bien se requiere una inversión, ya que necesitarás “moderadores” para las distintas ceremonias que estas metodologías proponen, como la daily, el sprint planning o la retrospectiva. Este rol de “moderador” es popularmente conocido como Scrum Master, aunque este nombre sólo sería correcto si se está trabajando sobre el marco de trabajo SCRUM ya que las metodologías ágiles van mucho más allá de lo que se conoce como SCRUM en sí. Este artículo no se centrará sobre ello así que seguimos.
Como se ha comentado previamente en este artículo, sobre todo la respuesta dependería de si se tiene bien acotado qué va a abarcar el proyecto y sus funcionalidades o si por el contrario estas funcionalidades no se tienen claras del todo y la idea es ir añadiéndolas en base a las necesidades del product owner durante el desarrollo del mismo.
En el primer caso no sería inteligente usar una metodología ágil, lo suyo sería utilizar una metodología más pesada como RUP. Este tipo de metodologías dan mucha importancia al análisis y diseño total del proyecto antes de comenzar el desarrollo, teniendo todo diagramado y documentado. De esta forma los programadores tienen claro desde un principio qué van a programar e incluso cómo lo van a hacer porque todo lo tendrían documentado y desmenuzado en diagramas de clases, de estados etc. De esta forma evitamos muchos Code Smells y errores en el software que podrían ser fatales en proyectos delicados como, por ejemplo, proyectos médicos.
En el segundo caso lo suyo es utilizar una metodología ágil ya que no se podría definir todo el sistema antes de comenzar con el desarrollo. Esto se debe a que no se tendría claro qué funcionalidades han de desarrollarse para el proyecto en su totalidad. Por ello es mejor realizar entregas continuas e ir documentando previamente a comenzar cada uno de los desarrollos. Algo muy útil a destacar también que ha traído el “mundo ágil” sería la integración continua y el despliegue continuo. También una muy buena práctica consiste en realizar tests unitarios y así detectar, si los hay, errores de código tras cada nueva implementación.
A diferencia de lo que se podría pensar de primeras al leer que una metodología es pesada, este tipo de metodologías tienen iteraciones como cualquier metodología ágil. Estas no se basan en la metodología waterfall o cascada como se podría pensar, ya que esta no tiene iteraciones. A diferencia de lo que te dirán muchos libros y artículos sobre metodologías ágiles, no sólo existe la metodología en cascada fuera de lo que son las metodologías ágiles. ¿Podría ser que a los autores de estos libros no les interese que se sepa que existen este otro tipo de metodologías también iterativas? Quien sabe, pero por algo no las suelen mencionar en sus artículos y libros.
Como podemos ver en la imagen, en las primeras iteraciones de la metodología RUP no se desarrolla prácticamente nada y en lo que se invierte el tiempo es en el modelado del negocio, definir los requisitos y realizar el análisis y el diseño. ¿Os suena el sprint 0 de las metodologías ágiles? Pues este está basado en estas primeras fases de las metodologías pesadas. La diferencia está en que en las ágiles no se documenta ni se diagrama a un nivel tan exhaustivo como se hace en las pesadas.
Hay artículos y libros que incluso confunden una cosa con la otra y al sprint 0 lo nombran fase de iniciación o inception (en inglés) (4), que es como se llama la primera fase de RUP.
Hay artículos e información sobre RUP y sobre cómo aplicarlo en internet, por quien pueda estar interesado en utilizarlo en alguno de sus proyectos. Actualmente RUP es propiedad de la empresa IBM.
Los gurús que se juntaron para la creación del manifiesto ágil lo hicieron porque creyeron que no era necesario darle tanto peso a diagramar y a documentar en proyectos más sencillos. Lo que la comunidad “agile” no comenta es que también ellos daban por hecho que serían desarrollados por equipos con perfiles bastantes experimentados. Por ello existen otras metodologías y marcos de trabajo ágiles que no son tan populares como lo es SCRUM por ejemplo, pero que realmente siguen esos principios que los gurús trataron de transmitir cuando firmaron el manifiesto. Un ejemplo sería la metodología XP.
Formulada por uno de los gurús que firmaron el manifiesto, Kent Beck, y que al igual que el resto de metodologías ágiles se diferencia principalmente de las tradicionales en que pone más énfasis en la adaptabilidad que en la previsibilidad. Esta metodología ágil, a diferencia de las más conocidas, exige que los desarrolladores constantemente refactoricen su código además de recomendar que se desarrollen pruebas unitarias antes de escribir el mismo (TDD). También requiere que se haga código simple de entender además de recomendar que las tareas se desarrollen por parejas (pair programming).
Resumiendo, esta metodología requiere un equipo de desarrollo con altos conocimientos para poder desarrollar rápido pero también con una gran calidad de código y con una gran capa de seguridad conseguida con el desarrollo de pruebas unitarias de calidad.
No, a no ser que se haya valorado previamente y llegado a la conclusión de que sí sería correcto el uso de la misma. Hay muchas cosas que se han de valorar antes de decidir qué metodología es la más adecuada para tu proyecto. Podría considerarse que pueden aportar mucho si se tiene un equipo con una buena base de conocimientos técnicos y si al proyecto se le va a ir añadiendo constantemente nuevas funcionalidades que de primeras no han sido definidas por el product owner.
ifgeekthen.nttdata.com es un blog del grupo NTT DATA. Un proyecto que busca compartir con profesionales del mundo digital temas relacionados con la tecnología y el universo geek.
