Si bien las metodologías ágiles venían gestándose y aplicándose desde los años noventa, la formación de la Alianza Ágil y subsiguiente publicación del Manifiesto para Desarrollo de Software Ágil en febrero del 2001, marcaron una inflexión en el uso de procesos para desarrollo de software desatando una fuerte polémica entre promotores y detractores de lo “ágil”.
Las malas interpretaciones de uno y otro lado marcaron el tono de la discusión que cada vez se hizo más radical. Sería pretencioso querer resolver en este artículo toda esta polémica; el objetivo es ilustrar algunos de los principales puntos en disputa, aclarando los conceptos erróneamente interpretados sin tomar partido por ninguno de los dos bandos.
Ni “Silver Bullet” ni “Licencia para Hackear”
Kent Beck, creador de Extreme Programming (XP), comenta que tuvo esta conversación con un practicante:
Agradecido practicante: Sr. Beck, tengo que agradecerle, XP nos cambió la vida, sin embargo, ahora tenemos algunos problemas con el testing.
Kent Beck: Muchas gracias. ¿Quiere decir que no logran codificar las pruebas antes de los programas?
AP: Bueno, en realidad no codificamos pruebas...
KB: Entiendo, ¿entonces logran realizar integración frecuente generando una nueva versión funcional al menos una vez al día?
AP: Mmm, en realidad no...
KB: ¿Pero funcionan la programación en pares, las historias de usuario o el refactoring?
AP: Mmm, no...
KB: Entonces, ¿cómo es que hacen XP?
AP: Ah, bueno, dejamos de documentar...
Beck ejemplificaba de esta forma exagerada lo que estaba dándose en la realidad: las nuevas metodologías fueron acogidas por muchos practicantes con gran entusiasmo y poco criterio. Además, a partir de un par de experiencias exitosas muchos se dedicaron a criticar con desprecio la llamada ingeniería “tradicional”.
Del otro bando también surgieron posiciones radicales. Steven Rakitin envió a los editores de IEEE Computer una carta con la siguiente interpretación escéptica del Manifiesto:
• Individuos y sus interacciones sobre procesos y herramientas. Traducción: hablar con la gente nos da la flexibilidad de hacer lo que nosotros queramos de la forma en que queramos. Por supuesto, se da por sentado que nosotros sabemos lo que usted quiere, incluso si usted no”.
• Software funcional sobre documentación exhaustiva. Traducción: queremos pasar todo el tiempo codificando. ¡Los verdaderos programadores no escriben documentos!
• Colaboración con el cliente sobre negociación de contratos. Traducción: “no perdamos tiempo discutiendo detalles, eso limita nuestra capacidad de pasar todo el tiempo codificando. Ya veremos qué pasa cuando entreguemos algo”.
• Responder al cambio sobre seguimiento de un plan. Traducción: “seguir un plan significa que deebemos pensar en el problema y cómo vamos realmente a resolverlo. ¿Por qué gastar tiempo en eso cuando podríamos estar codificando?”.
Estos extremos reflejan lo álgido de la discusión. Para algunos las metodologías ágiles eran la nueva “bala de plata” que venía a triunfar donde la ingeniería “tradicional” había fracasado. Para otros, las metodologías ágiles eran sólo una excusa para desarrollar software sin planes, diseño ni documentación. Ambos extremos son erróneos; por una parte, varias prácticas ágiles tienen nichos donde funcionan muy bien, pero hay otros ambientes donde pierden su efectividad o deben ser modificadas para lograr el objetivo. Sólo hay que imaginar realizar la reunión diaria de seguimiento que propone SCRUM, XP o Crystal en un proyecto con cincuenta personas.
Tampoco es correcto que lo ágil se contraponga a la ingeniería de software. De hecho, muchas prácticas ágiles vienen de estudios realizados desde antes de la década de los sesentas. Varios de los autores de estas metodologías vienen de la comunidad de desarrollo orientado a objetos, donde se gestaron varios de los avances más importantes en arquitectura y diseño de software. Este y otros puntos se tocarán en mayor detalle empezando por uno de los más discutidos: el ciclo de vida de desarrollo.
El Mito de la Cascada
Después de conocer tantos equipos de proyecto aún me asombra como para muchos el único ciclo de vida conocido es el de cascada, donde se ejecutan secuencialmente las actividades de análisis, diseño, construcción, etc.
RUP y las metodologías ágiles han contribuido a generar más visibilidad sobre los ciclos de vida iterativos e incrementales, pero se han dado algunas confusiones. Primero, erróneamente muchos practicantes de las metodologías ágiles creen que los ciclos de vida incrementales son exclusivos de estas o que son propuestos por ellas. Esto dista mucho de la realidad: hay evidencias de la definición y uso de ciclos de vida incrementales incluso en los años cincuenta. Un ejemplo es el ciclo de vida evolutivo en espiral de Boehm [Boehm86].
Otro gran error cometido tanto por agilistas como por tradicionalistas, es asumir que el ciclo de vida en cascada es absolutamente secuencial. He conocido ingenieros que están convencidos de que es posible realizar todo el trabajo de requerimientos antes de iniciar el diseño de modo que dicha etapa se “cierre” y no haya necesidad de volver atrás. Creer en esto es negar que se vayan a presentar cambios a los requerimientos en etapas posteriores del desarrollo lo cual es querer tapar el sol con las manos.
El ciclo de vida en cascada secuencial data de 1957 [Benington57], sin embargo el ciclo de vida en cascada conocido hoy es la versión de Royce [Royce70]. En esta propuesta, el ciclo de vida en cascada tiene una visión incremental, reconociendo que el cambio es innegable y que por lo tanto siempre habrá que volver atrás para refinar sucesivamente los resultados de cada etapa de acuerdo con los cambios que se presentan.
La elección del ciclo de vida debe realizarse según las condiciones del proyecto. ¿Qué tan práctico es planear iteraciones para un mantenimiento donde trabajan dos personas por un par de días? También pasa que es mucho más sencillo planificar un proyecto con ciclo de vida en cascada; además, los procesos de gestión de configuración e integración deben ser mucho más rigurosos en el desarrollo incremental. Por otro lado, sería suicida proponer un desarrollo en cascada en un proyecto con alta incertidumbre donde los requerimientos son vagos o muy susceptibles de cambio.
En resumen, ni cascada significa fracaso o arcaísmo, ni incremental significa éxito o ágil, cada equipo debe decidir cuál es el ciclo más conveniente para su proyecto.
Ingeniería vs. Agilidad
La rigurosidad y disciplina en las prácticas de ingeniería también se ha discutido mucho. El discurso de los “agilistas” de erradicar el ciclo en cascada y por lo tanto las grandes etapas de análisis y diseño antes de construir cualquier parte del producto ha llevado a la mala interpretación de que en las metodologías ágiles se desincentivan las prácticas de ingeniería de software. Esto se complementa con la aparentemente declarada aversión a la documentación presente en las metodologías ágiles.
En realidad las metodologías ágiles proponen reducir las actividades tipo “big up-front”. Por ejemplo, cuando el equipo tiene que dedicarse días enteros a actividades de diseño antes de codificar. En cambio se propone que el diseño sea una actividad permanente cuyos resultados se validan continuamente a la luz de lo construido. Según esto, el equipo dedica diariamente una parte de su tiempo a actividades de diseño, el cual evoluciona en paralelo con la construcción. Esto se complementa con otras prácticas: la integración frecuente presente en la mayoría de las metodologías ágiles sólo puede sostenerse con el respaldo de un adecuado trabajo de diseño.
Otro tema es la documentación. Muchos practicantes de los métodos tradicionales han implementado sus procesos con dependencia extrema de los documentos. Malas interpretaciones han llevado a que una compañía tenga un estándar de plan de proyecto de 20 secciones y 40 páginas y lo exija para todos sus proyectos sin importar si uno es de 60 horas hombre y otro de 6000.
< También he visto como compañías exigen a sus equipos documentar el diseño usando TODOS los diagramas de UML, sin distinción de cuáles son realmente útiles para cada proyecto o situación.
El otro extremo también se presenta debido a una mala interpretación. Críticos de las metodologías ágiles y muchos de sus practicantes han creído que no hay valor en documentar. Si bien varios autores han asumido posiciones relativamente extremas sobre el asunto, en general hay consenso en que cada equipo debe determinar la cantidad y forma de documentación requerida, sea que se use el generador de reportes de la herramienta de modelado, o una foto de la pizarra de la sesión de diseño. Además, deben tomarse en cuenta los requerimientos del cliente y condiciones debidas a regulaciones o estándares. Cumplir con los requerimientos de documentación no significa que el equipo deje de ser “ágil”.
Finalmente, la documentación no reemplaza la comunicación. Más de una vez he visto como la información de requerimientos se comparte en un equipo enviando el documento de casos de uso por e-mail: ¿es posible que se logre entendimiento de esta forma?
“Predecible” versus “Adaptable”: ¿Planificamos o No?
Varios agilistas han coincidido en describir los procesos ágiles como “adaptables” en contraposición a los métodos tradicionales o “dirigidos por planes”. Hay malas interpretaciones sobre esto también. Los agilistas critican que se pretende planificar en excesivo detalle asumiendo que hay una capacidad de predicción que no es posible. Los tradicionalistas responden afirmando que no hay planificación en lo “ágil”. He visto líderes de proyecto que pasan semanas desarrollando un plan de trabajo, estableciendo en el cronograma actividades de 1 ó 2 horas de duración que se van a iniciar en 6 meses más. Son pocos los proyectos de software que se pueden predecir con ese nivel de precisión, y por lo tanto lo más probable es que esas actividades se redefinan y el esfuerzo en planificación sea un desperdicio. Ningún método tradicional propone esto como buena práctica.
Por otro lado, es erróneo indicar que en los métodos ágiles no hay planificación. Todos incluyen prácticas específicas al respecto donde lo que está variando es la estrategia empleada y las técnicas utilizadas. En los métodos ágiles puede haber varios niveles de planificación: un plan de “releases” de alto nivel, un plan de iteraciones con un poco más de detalle y finalmente un plan de iteración donde aparecen las actividades concretas. También es erróneo pensar que estas técnicas son exclusivas de las metodologías ágiles. Esta planificación por ventanas o “Rolling Wave Planning” es una técnica recomendada por el PMBOK.
La connotación de predecible versus adaptable también está asociada a críticas a los métodos tradicionales indicando que no pueden o no saben lidiar eficientemente con el cambio. Malas interpretaciones han llevado a equipos a establecer excesivos y rigurosos procesos de control de cambio. Pocos métodos tradicionales establecen que el cambio debe ser limitado. La incertidumbre en los requerimientos y por lo tanto la omnipresencia del cambio ha sido aceptada desde siempre.
El Factor Humano
Uno de los puntos más distintivos de las metodologías ágiles fue su reconocimiento explícito de que la gente y sus interacciones eran el factor más importante de éxito en los proyectos de software. Sobre esto también ha habido confusiones. Para empezar, se ha creído que los métodos tradicionales no sólo desvalorizan el rol de las personas sino que además contienen intrínsecamente la visión de que los procesos pueden reemplazarlas.
He conocido gerentes que creen que con base en sus procesos pueden tomar un “programador X” y reemplazarlo por “programador Y” como si fueran piezas de maquinaria, pero eso es una pésima interpretación. Los conceptos sobre los que se fundamenta el manejo de las personas en los métodos ágiles vienen de muchos años atrás. Además, varios autores de metodologías tradicionales han declarado la importancia de las personas sobre los procesos. Lo que hay que reconocer es que las metodologías ágiles sí contienen de modo más explícito prácticas que favorecen esta visión y fortalecen el desarrollo del equipo a través de la comunicación y colaboración.
Otra crítica común a los métodos ágiles es que crean una enorme dependencia en las personas debido a la ausencia de procesos formales y documentación. Lo que yo he observado en los proyectos es lo contrario: un equipo que se reúne diariamente y sabe qué está haciendo cada uno de sus miembros y donde la planificación o el diseño se realiza con todo el equipo presente ha compartido de mejor forma el conocimiento y la experiencia y está más preparado para soportar un cambio en el equipo, que otro donde el análisis está perfectamente documentado, pero sólo una persona lo entiende.
La Necesidad del Balance
Son muchos temas más los que se han discutido a lo largo de esta polémica y que no alcanzamos a ver aquí: pruebas, manejo de riesgos o si CMMI puede ser implantado con prácticas ágiles, son algunos de ellos.
Probablemente la polémica continuará por algún tiempo más. Hoy, sin embargo, cada vez más practicantes han visto la necesidad de encontrar un balance. Las prácticas ágiles y las más tradicionales han demostrado tener nichos en los cuales se comportan bien y favorecen el éxito. También se ha probado que cuando dejan ese nicho las experiencias pueden ser desastrosas. Antes podía decirse que estos nichos eran independientes y un equipo podía escoger entre ir ágil o tradicional. Lo que sucede cada vez con mayor frecuencia en el vertiginoso mundo que vivimos, es que estos nichos se entrecruzan frecuentemente, y por lo tanto ningún esquema resulta completo o favorable por sí sólo.
No hay que quedarse en ningún extremo. Eso puede llevarnos a ignorar los objetivos del proyecto y conducirnos ciegamente al fracaso. Por el contrario, reconociendo el valor que una mezcla adecuada puede generar, aumentaremos notablemente la probabilidad de éxito de nuestros proyectos no sólo en los parámetros usuales de plazo, alcance y costo, sino también en el desarrollo del conocimiento y experiencia para el equipo y la organización.
Referencias
1. Barry Boehm. “A Spiral Model of Software Development and Enhancement”. Proceedings of the Second International Software Process Workshop, Marzo 1985.
2. H.D. Benington, “Production of Large Computer Programs,” Proceedings of the ONR Symposium on Advanced Program Methods for Digital Computers, 1956.
3. E.V. Berard, “Misconceptions of the Agile Zealots”, The Object Agency, 2003. 4. F. P. Brooks, Jr., “No Silver Bullet: Essence and Accidents of Software Engineering,” IEEE Computer, Vol. 20, No. 4, Abril 1987.
5. Martin Fowler, “Is Design Dead?”, www.martinfowler.com
Acerca del autor
John Gómez es PMP y se desempeña como Consultor Senior para mejora de procesos en Practia Consulting Chile. Tiene más de 15 años de experiencia en proyectos de desarrollo de software asumiendo roles de programador, diseñador, arquitecto y jefe de proyecto. Desde el año 2002 colabora con la implementación de prácticas ágiles en proyectos de desarrollo y ha dirigido proyectos de mejora basados únicamente en metodologías ágiles. John ha sido relator de charlas sobre metodologías ágiles en varias oportunidades incluyendo las ediciones de SEPG LA de 2005 y 2006.
- Log in to post comments