Una metodología ágil no es siempre la mejor opción

Sí, así es, aunque no esté de moda decirlo y sea contrario a lo que muchas veces se escucha y lee por ahí. Las metodologías ágiles hay que ponerlas en contexto y utilizarlas en su justa medida, cuando sean la mejor opción, que no es siempre. Y aunque muchas veces el mensaje que nos llega es que todo lo ágil es fácil y bonito, adaptar una metodología a una organización es un trabajo complicado, que requiere extraer lo mejor de la escala de grises que hay entre lo ágil y lo tradicional, además de saber integrarlas con otras actividades de la ingeniería software. La cosa no es tan simple como contar lo malo que es el ciclo de vida en cascada y cambiarlo por el iterativo – incremental.
Y todo esto viene a que viendo el programa de la “Agile Industrial Day – Madrid, Spain encuentro entre sus ponentes a Philippe Kruchten, un tipo de amplia trayectoria en ingeniería del software, con el que hace unos años tuvimos la suerte de participar en un especial de IEEE Software sobre arquitecturas y del que en los últimos años destacan sus trabajos sobre contextualizar a las metodologías ágiles. Y Kruchten no es el único que ha advertido del problema de utilizar las metodologías ágiles sin observar su contexto y el grado de agilidad necesario. Boehm y Turner en “Balancing agility and discipline” ya determinaban la idoneidad de las metodologías ágiles en función del tamaño, criticidad, nivel del equipo, dinamismo y cultura. Similares parámetros utilizaba Cockburn en “A Human-Powered Methodology for Small Teams”. Y Kruchten añade otros como la “necesidad de una arquitectura estable”.
Y es que además de un twet que leí hace poco en @calidadsoftware sobre “Pitfalls in Agile Software Development» hay pocos sitios que nos cuenten los peligros de irnos a lo ágil sin preparación. Kruchten escribía hace unos años sobre uno de los principales temas a resolver cuando se implanta una metodología ágil: lograr una solida arquitectura software; y contaba el caso de una gran reingeniería de un sistema de 2 millones de líneas, para el que se empezó utilizando XP y SCRUM, que a los 4 meses y medio empezó a encontrar dificultades, refactorizaciones que se iban a más de una iteración, donde se fue disparando el retrabajo y donde al no estar clara la arquitectura llegó un momento en que no se sabía cómo avanzar.

Javier Garzás

7 comentarios en “Una metodología ágil no es siempre la mejor opción”

  1. Interesante post Javier.
    Estoy de acuerdo contigo en que lo Agile no es «siempre» la mejor opción y que antes de aplicarlo hay que tener ciertas cosas muy claras.
    Suerte con las críticas que desde el mundo Agile te puedan venir 😉
    Saludos

  2. Igualmente de acuerdo. Este tema no es tan fácil, y requiere de mucho ciudado y conocimiento el implantar una metodología, sabiendo elegir lo mejor de todo lo que tenemos en ing soft.

  3. Estoy totalmente de acuerdo contigo Javier… llevo algún tiempo trabajando con metodologías ágiles y parece que ya no hay otra forma de hacer las cosas, y evidentemente no es así. Además de aprender metodologías ágiles, deberíamos aprender ¡cuándo utilizarlas! ¡Buen artículo, Javier!

  4. Bueno, varios temas para comentar en este post, yo haré de paladín de las ágiles por ahora 🙂
    Por un lado, no creo que el mensaje real sea que implantar ágiles sea fácil y sencillo, que se diga eso (algún descerebrado, quizás). Siempre se repite que no es una bala de plata, y de sencillo no tiene nada, desde luego.
    Las metodologías ágiles han servido para poner el foco donde más importa, en la personas. Y en que el código es importante.
    No creo que hoy en día nadie haga una metodología en cascada pura, y habrá muy poca gente que haga una metodología ágil en todos sus aspectos. Todos nos adaptamos un poco al entorno en el que nos movemos, como bien dices, y hay que coger ideas de todas partes.
    Pero yo no tengo duda de que las metodologías ágiles te llevan a un mejor desarrollo de proyecto en cualquier tipo de ellos. Ahora bien, ciertamente hay grados de ágiles, y muchas práctics y técnicas diferentes. Acertar con la que necesitas no es fácil. Puedes ser ágil sin iteraciones o con ellas, por ejemplo…
    Comentas: «hay pocos sitios que nos cuenten los peligros de irnos a lo ágil sin preparación»… pero es que… lo peligroso es desarrollar software sin preparación!! independientemente de la metodología. Y esas pegas de ese post a las metodlogías ágiles, ¿acaso no lo son también para las tradicionales? ¿acaso no requerirían de atención especial gestionandolo por ejemplo con Metrica3 :\ ?
    Salu2

  5. Pingback: “Deadly Sins”, o “walking deads”, de implantar una metodología software. (1/2) Tres “walking deads” desde la experiencia. | Javier Garzás

  6. Las metodologias agiles no son estructuras, es una filosofia, una corriente de pensamiento. Despues desarrollar software nunca se hace facil, hay miles de deficiencias tecnicas y humanas. En desarrollo deberiamos tener todo el personal altamente experimentado y entrenado, suena algo utopico. Otro punto a tener en cuenta es que la universidad no es demasiado agil que digamos para el contexto cambiante de sistemas. Las herramientas que se enseñan no son las mas modernas, y se pierden mucho tiempo aprendiendo analisis matematico, geometria, fisica, quimica. Cuando salen tienen que empezar de cero otra vez viendo todo lo que no aprendieron. Otro gran problema es que una vez que ya funciona el sistema, las incidencias cobran prioridad principal y es el mayor distractor de la continuacion de los proyectos para los lideres y desarrolladores. A medida que van vendiendo productos, la compañia intenta brindar mantenimiento con el mismo personal que en un inicio. Esto no es un ser o no ser, un blanco o negro. Las personas tienen diferentes culturas, habilidades, preparaciones y hay que saber negociar y encontrar el mejor resultado.

  7. Me parece muy bueno y valiente este post de Javier Garzás sobre observar y evaluar elementos en los que es poco factible aplicar metodologías agiles en ciertas organizaciones.
    Apoyo ciertas acciones y valoro el trabajo de las comunidades ágiles, para intentar mejorar la calidad de vida de los fabricantes de software y los procesos de desarrollo en ciertos contextos. Pero actualmente, hablo con muchos jovenes que se insertan en estos movimientos de metodologías agiles como forma de ver la vida y forma de trabajar en la industria, y aún no han experimentado estudiar y revisar bibliografía de las metodologías anteriores a las nacidas post «Manifesto Ágil».
    ¿Desarrollo en Espiral, Desarrollo en Cascada Retroalimentado, Desarrollo basado en Prototipos, RUP… los conocen y saben como funcionan?
    Hablar de actividades Analisis-Diseño-Arquitectua-Implementacion-Pruebas y hablar de modelos de especificación (UML, Especificacion de Casos de Uso, Diseño de Casos de Prueba u otros) parecieran que fueran «mala palabra» en las comunidades ágiles, cuando se habla de la importancia de mantenerlas y el riesgo que se corre no mantenerlas.
    Es muy importante tener presente el contexto, equipo de trabajo y cultura de la organización, evaluando en donde y cómo agilizar ciertos aspectos del proceso de desarrollo de una organizacion o fabrica de software.
    Es importante reconocer cuando es util utilizar cada una de las propuestas, cómo adecuarlas a ciertas organizaciones y evalar las desventajas de cada una (las ventajas siempre vienen fácil de identificar).
    A partir de esto, podemos discernir a conciencia y como profesionales de la industria. No es cuestión de fanatismos por las metodologías agiles…sino ser profesionales y reconocer tambien que hay lugares que no aplica la filosofia y es adecuado aplicar metodologias mas duras como RUP (x ej.).

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Ir arriba