Hasta en España -más vale tarde que nunca- se suceden los podcasts, encuentros, conferencias, cursos, seminarios y charlas. Por llegar, ha llegado hasta a las LanParties! Lo próximo será un Open Space en Madrid. Todo ello bien apoyado desde agile-spain, la Comunidad Agile en castellano.
Es una gran noticia. Está haciendo mucho ruido. Y eso es bueno. Es muy bueno. Porque ante todo, lo que Agile transmite es un mensaje. Un mensaje que informa de que existen mejores formas de desarrollar software y que por primera vez viene de abajo a arriba, desde la gente que sabe desarrollar software a la gerencia y a los clientes.
Mi experiencia
Éste es un mensaje con el que estoy totalmente de acuerdo y que intento llevar a cabo en todos los equipos y proyectos por los que he pasado en los últimos años. No ha sido fácil. Sin apoyos, autoformándome en mi tiempo libre e introduciendo los cambios poco a poco, sacando horas de donde se podía.Primero adopé la visión y objetivo del Manifiesto y los Principios Ágiles.
Luego fuí aplicando muchas de las llamadas Prácticas Ágiles en el desarrollo de los proyectos, como el diseño y desarrollo dirigido a pruebas (TDD), automatización, integración continua, iteraciones, concepto de hecho, diseño simple y evolutivo, revisiones de código, retrospectivas y documentación inteligente o útil.
Finalmente he utilizado algunas de las técnicas de las Metodologías Ágiles para transformar la forma de organizar el trabajo del día a día y alcanzar un nivel de agilidad más completo.
Consiguiendo así evolucionar la forma de desarrollar software, haciéndo proyectos más estables, eficaces y adaptables a los inevitables cambios, para satisfacción del cliente y propia.
Hoy puedo decir que mis esfuerzos por ser Ágil me han ayudado a ser mejor profesional y, también, a formar equipos que desarrollan mejor software y con los que da gusto trabajar. Aunque aún me queda mucho por aprender y mejorar, hoy soy consciente de que estoy en el camino correcto. Hace unos años no podía decir lo mismo.
Peligro
Sin embargo, últimamente noto el mensaje excesivamente -casi exclusivamente- dirigido a la implantación de las Metodologías Ágiles y principalmente Scrum.Conviene recordar que las Metodologías Ágiles no son metodologías de desarrollo software en sí, sino simplemente de trabajo. Scrum (pej) no define qué entregables debe tener un proyecto, no define ni siquiera tipos de proyecto, si se debe usar UML, Diagramas Gantt, ni nada. Scrum es tan aplicable al desarrollo de software como a cualquier tipo de proceso divisible en tareas, pej. una mudanza! De hecho nuestro tan aclamado Scrum no es una metodología originalmente creada para el desarrollo de software.
En mi opinión, para poder usar una Metodología Ágil, primero es necesario que el proyecto tenga un nivel técnico alto, basado principalmente en automatización, pruebas e integración continua. Cómo podemos adoptar un desarrollo en iteraciones, si no tenemos modo de garantizar (al menos en parte) que el código que funcionaba en la iteración N sigue funcionando en la iteración N+1. ¿Mediante la repetición de fases de pruebas manuales? ¿Y eso es desarrollar mejor software?
Citando a mi colega Alfredo Casado: sin excelencia técnica no hay agilismo, sólo post-it pegados por las paredes. Y sinceramente el nivel técnico medio de los proyectos software a día de hoy deja bastante que desear.
Por otro lado, no puedo dejar de preocuparme cuando leo mucha de la publicidad que se le está haciendo a las Metodologías Ágiles y a Scrum. Cosas del tipo sólo existen 2 tipos de metodologías: en cascada y ágiles, o sólo hay 2 formas de desarrollar buen software: trabajar en la NASA o usar Scrum, o si no obtienes beneficio de aplicar una Metodología Agile es porque no lo estás aplicando en su totalidad, por tanto debes contratar un experto en Agile o Scrum es el remedio contra la crisis mundial. Por supuesto todo rodeado de los nuevos buzzwords de turno, que así como que
Todas estas falacias -y otras más- no hacen sino distorsionar el mensaje original (mejores formas de desarrollar software) y dejar una imagen de vendedor de teletienda que no hace ningún bien, y sólo puede generar desconfianza. Supongo que va asociado al hype, pero ¿qué tal si intentamos todos ser un poco más responsables?
También me preocupa -y mucho- el tema de las certificaciones en Scrum y el ansia de algunos por llegar a ser Agile Coach. Donde algunos ven la luz que iluminará el futuro, yo sólo veo una gallina; de huevos de oro, eso sí. Tiene toda la pinta de convertirse en el MBA de nuestro sector. Y si no, al tiempo.
En realidad Scrum no es aplicable a más de la mitad de los proyectos. Entre otras cosas, requiere una enorme disponibilidad por parte del cliente (el Product Owner es parte del equipo), equipos con dedicación absoluta y de alto nivel técnico y una sala de reuniones por equipo disponible a primera hora. Al final tienes que adaptar Scrum a tus circunstancias, pero entonces yo pregunto: ¿y no será más fácil adaptar la metodología que se esté usando para agilizarla? Ah no, que eso no sería cool.
Conclusión
¿Quiere ésto decir que las Metodologías Ágiles no aportan valor? En absoluto. Claro que aportan. Pero cada cosa en su sitio, sobre todo porque no siempre es posible y viable implantar una Metodología Agile oficial. Una Metodología Agile es la punta del iceberg, la guinda del pastel, debajo necesitamos una sólida base construida a partir del Manifiesto, Principios y Prácticas Ágiles.No podemos dejarnos llevar por el hype de las Metodologías Ágiles, un hype que cada día tiene más parecidos con la religión que con desarrollar software, tanto por el fanatismo como por el negocio generado. De hecho hasta el nombre de Agilismo ha calado. Pero yo no quiero ser Agilista, yo no necesito creer en ninguna Metodología concreta ni en guías espirituales.
Yo quiero ser Ágil. Y se puede ser Ágil sin seguir fielmente una de las Metodologías Ágiles oficiales. Porque el valor de ser ágil es evidente: automatización, pruebas, integración continua, entregas periódicas de un software que funciona, equipos orgullosos y comprometidos con su trabajo, código de mejor calidad, documentación útil, respuesta frente a cambios en los requisitos, compresión y colaboración del cliente,... entre otros. Ésto sí son mejores formas de desarrollar software!
