Desarrollo ágil o tradicional: ¿existe el punto intermedio?
Archivado en agil, buenas prácticas en Aug.15, 2010 por jgarzas
Un muy interesante artículo en Computer me volvió a recordar como desde hace ya tiempo se observa en el día a día que cuando las organizaciones se plantean implantar un método ágil, y estudian en detalle la idoneidad para su organización, con sus clientes y tipo de proyectos, raramente implantan el método ágil al 100%, y lo que hacen son adaptaciones al mismo, muchas veces incorporándole prácticas formales, como, por ejemplo, el robustecer y hacer menos iterativa la fase de diseño de la arquitectura software.
Y aunque muchas veces se leen y escuchan ciertas “posturas ágiles” que insisten y recomiendan el “todo o nada” a la hora de adoptar prácticas ágiles, la realidad en las empresas parece que refleja posturas más moderadas, hibridas y orientadas por la necesidad, negocio y mejor práctica para cada organización y proyecto (como por ejemplo muestran estudios y encuestas realizadas en conferencias ágiles, en las que la mayoría de las personas que usaban métodos ágiles no usaban todos los principios ágiles). La experiencia dice que raramente se usan todos los principios ágiles o un método formal al 100%, si no que maneras de trabajar hibridas parecen estar imponiéndose.
Está bastante aceptado, y documentado, que el desarrollo ágil es más idóneo en proyectos con cambios considerables, y que para proyectos estables se obtiene más beneficio de realizar diseños más rigurosos y desarrollos “upfront”. Por otro lado existen dos tipos de organizaciones: las flexibles (poco jerárquicas, poco burocráticas, etc.) y las rígidas (jerárquicas, burocráticas, etc.), siendo una de las principales razones para no migrar de métodos formales a ágiles “la cultura rígida” de la organización. Los métodos ágiles se adaptan más a organizaciones flexibles y proyectos con cambios, mientras que los métodos más formales son más apropiados en organizaciones rígidas y proyectos estables. Pero ¿qué sucede si la organización es flexible y el proyecto estable? ¿Y qué sucede si la organización es rígida pero el proyecto es cambiante?
De mezclar culturas organizacionales flexibles o rígidas con proyectos cambiantes o estables están apareciendo cuatro métodos de desarrollo. Los ya mencionados métodos formales (más apropiados para organizaciones rígidas con proyectos estables) y los métodos ágiles (más apropiados en organizaciones flexibles con proyectos cambiantes), a los que se añaden los iterativos-formales (más apropiados para organizaciones rígidas con proyectos cambiantes) y los métodos ágiles optimizados o con algo de diseño “upfront” (más apropiados en organizaciones flexibles con proyectos estables)
En organizaciones rígidas en las que es difícil seguir un método ágil parecen adecuarse bien los Iterativos formales. Para estas organizaciones es difícil seguir los principios del manifiesto ágil que hablan de evitar procesos rígidos o que afectan a la documentación. Pero, no obstante, pueden añadir con más facilidad aquello que el manifiesto ágil recomienda a nivel de proyecto (aunque les sea difícil añadir lo que dice a nivel de organización), como, por ejemplo, incluir reuniones frecuentes con el cliente, iteraciones, etc. Métodos como el “agile unified process” o agile UP siguen esta filosofía.
En organizaciones flexibles con proyectos poco cambiantes (sistemas embebidos, proyectos críticos, proyectos con requisitos no funcionales, etc.) seguir un ágil optimizado puede traer muchas ventajas, como optimizar la arquitectura, minimizar el retrabajo y la integración.
Numerosas evidencias muestran que mayoritariamente se están usando alguno de estos nuevos métodos híbridos (ágiles con “upfront” o formales con componentes iterativos). Esto indica que argumentos en contra de los métodos ágiles, como que no hacen diseño de la arquitectura, o contra los métodos formales, como que no responden al cambio, pueden evitarse y que las posturas radicales son muchas veces teorías que finalmente se acaban adaptando a la realidad de cada empresa.
