Metodologías ágiles ¿Aplican siempre?

[[AzidRain]]

En los últimos años se pusieron de moda las metodologías ágiles para desarrollar software. De ahí surgieron varias propuestas, siendo las más exitosas o al menos las que más acogida han tenido extreme y scrum. Al igual como pasa con cualquier nuevo lenguaje hubo un boom de "ingenieros" que a la voz de "es lo de hoy" a diestra y siniestra empezaron a aplicarlas para toda clase de proyectos aunque no siempre el proyecto se prestara para ello.

Es interesante ver que una de las características de este tipo de metodologías es la de sacar las cosas rápido y dejar documentación para después. Es muy adecuado para pequeños desarrollos innovadores que requieren un tiempo mínimo para salir a producción. Pero a mi juicio no lo es para desarrollos importantes tipo sistemas CRM o ERP, misión crítica, automatización, etc. en donde las cosas pueden tornarse enormes y con un alto grado de complejidad en cuanto a interdependencia y demás. Mi especialidad es el software administrativo y operativo para empresas. El objetivo siempre es partir de un proceso o procesos, identificar todo lo necesario respecto al mismo, modelarlo, hacer la arquitectura del mismo y ya con ella en mano entonces sí partir hacia el desarrollo. En el software empresarial casi siempre es imposible que todos los módulos del sistema trabajen de forma independiente pues esa es la forma en que trabajan todas las empresas: a base de interrelaciones y operaciones cruzadas entre los diversos departamentos de manera que lo que pasa en un proceso A puede afectar lo que pasa en un proceso B y a su vez puede requerir que se efectúe un proceso C.

Bajo este planteamiento, considero que las metodologías ágiles, en mi caso particlar, scrum, se enfocan más a ver pequeños pedazos de un todo aplicando el famoso "divide y venceras" y deja de lado la importancia de las interrelaciones. En un sprint es posible que no pueda incluirse solo una o dos partes de ese todo ya que dependen para funcionar como se debe de el resto de ellas, por lo que forzosamente hay que desarrollarlas todas para poder obtener algo utilizable. Si vemos el software como un auto, es como querer armar solo la transmision y el chasis y dejar para el siguiente sprint las ruedas y el motor. Y aún así si se arma el chasis, motor y dirección en un primer sprint, al cliente no le aporta ningún valor todavía.

Además de lo que comento, siento que está diseñado pensando en equipos más o menos grandes de desarrolladores enfocados en un mismo proyecto. La filosofía de que "tiene que salir en el tiempo que tiene que salir" también me parece errónea pues implica que todo mundo trabaje jornadas extenuantes cuando se aproximan las fechas de entrega. Además si no se cuenta con un buen scrum master no se va a ningún lado, pues el desarrollador termina usando mejor google que el consejo de él y entonces todo se viene para abajo. Por otro lado requiere de un compromiso de parte del cliente para contar con un representante que trabaje junto al equipo todo el tiempo, lo cual es casi imposible en la mayoría de las empresas. Al menos en la mentalidad latinoamericana.

No se si esté yo equivocado pero creo que estas metodologías van más por el lado de "hagamos una app que nos haga 3 o 4 cosas" que por el de hagamos todo un sistema completo que controle todas las operaciones habidas y por haber de una empresa (por ejemplo SAP pero a menor escala). También me parece una muy buena estrategia para implementar mejoras e innovaciones sobre algo ya diseñado y probado. Es decir, si ya tienes un sistema mas o menos completo trabajando y solo te faltan algunas piezas, entonces sí que se puede aplicar este esquema.

Pero bueno, yo solo opino. No se si alguien tenga alguna experiencia por ahí sobre este tipo de metodologías en proyectos similares.