Desarrollo ágil o tradicional: ¿existe el punto intermedio?

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.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

0 comentarios en “Desarrollo ágil o tradicional: ¿existe el punto intermedio?”

  1. Hola Javier,
    Interesante experiencia, sin duda. A ver si nos comentas algo de lo que has aprendido para gestionar grupos… si te parece…
    Gracias…

  2. Algunas prácticas normalmente asociadas al tema ágil, en particular las «técnicas» de XP son perfectamente aplicables en entornos formales y burocráticos; y está muy bien que así sea.
    Sin embargo aplicar esas prácticas no significa que estés siendo ágil en un entorno burocrático, y está muy bien que así sea.
    Ágil no es algo que todos deban ser, no hay necesidad ni es posible. Ver escala de Cockburn (http://alistair.cockburn.us/Cockburn+Scale).

  3. Estás totalmente equivocado en lo que se refiere a los métodos formales.
    Dicho de forma corta y burda, los métodos formales son aquellas formas de desarrollar software que permiten validarlo matemática y automáticamente (sería como testear el 100% de las posibles ejecuciones) frente al testeo explícito (del 50%, 60%, 80%) que se hace con las pruebas unitarias.
    Puedes verlo aquí:
    http://en.wikipedia.org/wiki/Formal_methods
    Hay infinidad de métodos formales:
    -MDD, desarrollo dirigido por modelos, usado por ejemplo en el Chevy Volt.
    http://www.eetimes.com/discussion/-include/4215057/Ten-million-lines-in-29-months–model-driven-development-on-the-Chevy-Volt
    -DSL, lenguajes del dominio específico. Te dejo unas traspas con varias aplicaciones en la industria.
    http://www.bits-chips.nl/fileadmin/uploads_redactie_bc/docs/HPL2011/Presentaties/Juha-Pekka_Tolvanen.pdf
    -Otros paradigmas o modelos computacionales, como el paradigma funcional y el lógico, que usan la teoría de la rescritura y la unificación, usado por lenguajes como Haskell o Prolog. O híbridos como Maude (usado en la NASA), este lenguaje al usar otro paradigma se puede validar, es decir, pasarle un proceso automático para ver si «falla».
    http://maude.cs.uiuc.edu/
    Irónicamente, con MDD y DSL, al ser más abstractos, se es más productivo y rápido, y por el hecho de validar los programas, no pierdes el tiempo buscando bugs o testeando los programas con pruebas unitarias.
    Si quieres estar más actualizado y aprender lo que realmente son los métodos formales, puedes ir a este taller que se hace durante una semana en Italia:
    http://modeling-languages.com/sfm-12-mde-summer-school/
    Dale a «Programme» para ver las temáticas, que son las que te he comentado.

  4. Mucha gente piensa que los métodos formales son costosos en tiempo y dinero, y hace falta casi un doctorado para usarlos. Que gran error.
    MDD/MDE (y DSLs) busca la abstracción, industrialización y validación. Y un ejemplo es la página web de Acer, hecha con modelos, usando un lenguaje llamado WebML (el UML de la web). La misma empresa que lo hizo dice en un white paper que tardo mucho menos que haciéndolo con J2E y además el mantenimiento es más fácil. Lo cual es evidente, es más fácil trabajar a mayor nivel de abstracción, y se puede abarcar más complejidad (y para los agilistas, se puede improvisar, cambiar, prueba y error más rápidamente que con un lenguaje imperativo):
    http://vsr.informatik.tu-chemnitz.de/edu/2011/webe-seminar-ws/material/10/Chapter%209%20-%20WebML.pdf
    http://www.webml.org/webml/upload/ent5/1/LNCS_final_printed_46070539.pdf (te recomiendo leer las conclusiones de este paper)
    De hecho, algunos «gurús agilistas» ya se han dado cuenta y han inventado «Agile Modeling» y «Extreme Modeling» (puedes buscarlos en Internet).
    Por contra, muchos «expertos» en XP opinan que el diseño/modelo es el propio código.
    http://www.developerdotstar.com/mag/articles/reeves_design_main.html
    No imagino nada más aberrante que esa afirmación. Sería como afirmar que que los planos de los edificios son los propios ladrillos pegados con cemento. No se puede razonar de forma abstracta sobre cachos en JAVA o C++. Y tampoco se pueden validar, debido al modelo de computación que se usan los lenguajes imperativos, tanto objetuales como procedurales (datos, instrucciones, efectos colaterales).
    Por todo ello, XP, SCRUM, y cualquier cosa que se le parezca jamás podrá hacer que se de un salto cualitativo y cuantitativo (aplícatelo también a la calidad, busca por internet «quality assurance model driven») en el desarrollo del software, mientras que ciertos métodos formales ya están dando ese salto, aunque este tema sería otra discusión y me acabo de dar cuenta que he escrito un ladrillo.
    Además, muchos «agilistas» tienen una especie de alergía frente a modelos y cualquier cosa que parezca «formal» o simplemente seria o académica. La única razón es una profunda ignorancia. Un ejemplo lo tienes en el propio Linus Tolvards. Te dejo que lo leas y lo veas por ti mismo, no tiene desperdicio, se puede fácilmente ver lo obtuso de mente que es esta clase de gente:
    http://lwn.net/Articles/249460/
    Por tanto, en tu artículo, para que sea correcto, cambia «métodos formales» por «ciclo de vida en cascada», que es lo creo que quieres decir.

  5. Estimado Ricardo,
    Antes de nada te agradezco la enorme cantidad de links que has puesto en el comentario. Muy útiles, sin ninguna duda.
    No obstante, creo que ya que conoces el tema de los “método formales” te sería bueno saber que “método formal” además de, como bien mencionas, hacer referencia a los métodos más cercanos a la parte matemática también hace referencia a un enfoque de desarrollo “Big Design Up Front”, generalmente con ciclo de vida en cascada, plan driven, y normalmente considerado opuesto al ágil. Es decir, que “método formal” tiene dos significados.
    Si te fijas en el post, este está basado en un artículo de IEEE Computer llamado “Agility versus Maturity: Is There Really a Trade-Off? May 2010 (vol. 43 no. 5)”. Si lees el mencionado artículo verás que aparte de este quien escribe en este blog, también el autor del artículo de IEEE usa “método formal” como concepto opuesto a lo ágil. He aquí un extracto: “Agile and formal software developers often contend that their method is superior to the other”.
    Y es más, unido a los dos anteriores, Barry W. Boehm y Richard Turner en “Balancing agility and discipline” tienen escritas cosas en su libro como “Heavyweight formal methods” o “formal, process-based methods”.
    Y hay más sitios que utilizan formal en este contexto:
    http://www.testingreflections.com/node/view/3699
    http://stevesanderson.com/2003/01/13/formal-versus-agile-youve-got-it-all-wrong/
    etc.
    En cualquier caso, si que estoy de acuerdo que en este contexto la palabra tradicional (en vez de formal) evita malos entendidos y se usa más.
    Agradezco tu invitación a ir a Italia, y te aseguro que iría con mucho gusto, ya que es un país muy bonito, pero un compromiso me impide ir.
    Recibe un cordial saludo.

  6. Pingback: La agilidad está muriendo. Bienvenido el postagilismo - Javier Garzás, sobre calidad software y otros temas relacionados

Dejar un comentario

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