Con Scrum no alcanza

Empezando un poco con el tema de metodologías ágiles en general quiero pasar a este blog, de alguna manera repitiendo su publicación, un post que habia escrito respecto a una conversación dentro del marco de la lista sobre metodologías agiles en habla hispana, foro-agiles@yahoogroups.com. De paso la idea es "aggiornalo" o mejor dicho, ponerlo un poco mas en contexto dentro de este blog.

Como ya contamos comenzamos a interesarnos en las metodologías ágiles allá por los años 2002/2003, cuando leímos un par de libros sobre eXtreme Programming (XP), "XP Explained" de Kent Beck y "XP Installed", de Ron Reffries que llegaron en el momento justo, cuando estabamos en crisis, en la búsqueda de ciertas respuestas. LLevabamos en ese momento casi 10 años de trabajo profesional y estabamos seguros de que tenía que haber otras formas, mejores, de encarar el desarrollo de software. Ni Waterfall ni RUP, ni la utilización de una gran etapa de relevamiento con UML habian cambiado en lo mas mínimo la mala situación de la mayoría de los proyectos en los que participabamos. Al final sucedia siempre lo mismo: El grupo de desarrollo, realizando una marcha forzada contra reloj, se esforzaba heroica pero inútilmente en terminar un sistema que al usuario luego no le servía.

En los años siguientes, las metodologías ágiles comenzaron a ser cada vez más populares, y se ensanchó grandemente su audiencia. Esto sucedió básicamente a través de la difusión masiva de Scrum y sus certificaciones, por encima de XP (y su relacionada Industrial-XP ) y Cristal Clear (de Alistair Cockburn) , que han quedado mucho mas relegadas. Creo que en parte ganó la noción que estas otras metodologías, particularmente XP, solo se ocupaban de la programación y no de la gestión y organización del proyecto. Esta idea es totalmente errónea pero es un tema que trataremos en otro momento.

LLendo al titulo del post, aclaramos por si las dudas: Estamos a favor de Scrum. Personalmente creo que es una buena metodología/ framework / conj. de buenas prácticas/ comoseaqueunolodefina, de lo mejor que hay dando vuelta por el ala ágil del arco de desarrollo (es la mas difundida, seguro).
Lo que desafío es la noción de que con Scrum sólo alcanza para obtener excelentes resultados en un proyecto de desarrollo de software. Más bien me juego por lo contrario, con Scrum solo solo (valga la redundancia) alcanza para fracasar. Lo digo en serio. Cuando mucho será un fracaso menor o más rápido que con una metodología tradicional, de las monumentales, con más participación del usuario, pero fracaso al fin.

A ver, en teoría es suficiente con hacer muchos Sprints, muchas retrospectivas, cierta transpiración y luego de un cierto numero de iteraciones....voila! van a ir surgiendo en el grupo un conjunto de buenas práacticas de desarrollo, se van a ir corrigiendo errores, eliminando impedimentos y llegaremos a tener un proceso aceitado que permite conseguir un producto de alta calidad deleitando a nuestros usuarios, verdad?

FALSO (IMHO) porque:

1. Muchos proyectos no duran tanto para lograr mejorar la calidad del producto a través de retrospectivas y permitir que surjan buenas practicas de desarrollo, en parte por "culpa" del mismo Scrum. El hecho de realizar reviews cada 2 o 3 semanas del Sprint implica una Alta Exposición ante el usuario (claro que estoy a favor del feedback constante), el hecho es que si estamos construyendo...crap, es decir, porquerías vamos a estar mostrando porquerías... y los usuarios suelen tener poca paciencia... (y ni hablar de nuestros "ágiles" gerentes...).


2. Los equipos de desarrollo no suelen estar juntos y evolucionar juntos en distintos proyectos (algo que mejoraría el punto anterior porque no tiene que producirse la evolución en el proyecto presente sino que puede venir de proyectos anteriores) por la altísima rotación producto (bendita sea) del mercado dinámico y de ciertas condiciones de contratación precarias. Es la realidad en que vivimos por lo menos aquí en Argentina, y me atrevería a arriesgar en muchos lugares del mundo incluso a pesar del impacto de la crisis mundial.


3. Un grupo de desarrolladores (Programadores) no aprende de la nada a ser bueno, de la noche a la mañana, no se aprende a realizar buenos Diseños Simples de manera evolutiva e incremental. Lleva mucho tiempo y trabajo aprender a realizar tests de unidad efectivos y mantenibles en variados ambientes tecnológicos y tipos de proyectos. Cuesta y mucho aprender a Programar Orientado a Objetos, pero en serio, de manera profunda no solo aplicando patrones de diseño a diestra y siniestra. Requiere estudio, requiere mucha práctica, mucho esfuerzo y cierta habilidad o capacidad mínima.


4. Cuesta tiempo aprender a coordinar al grupo, Desarrolladores, Testers, Analistas Funcionales, Usuarios, tiempo este que crece exponencialmente con el tamaño del mismo.


5. Nos enfocamos mucho en el proceso.... Planning Meeting - Sprint - Review - Retrospectiva y nos estamos olvidando de la calidad de la gente.... People over Processes , no se si les suena. Y es la gente la que siempre termina dando la solución.


6. Hay un proceso.... dudo en llamarlo... de pauperización o deterioro de calidad de la programación y desarrollo de software que me preocupa, cada vez mas los programadores solo se centran en dominar el siguiente framework X-Y-J, llamese Enterprise Library, WCF, Spring security-MVC-Whatever, Hibernate, Seam, el siguiente "juguete" o arma que les promete la famosa "bala de plata" en lugar de buscar mejorar activamente la calidad del desarrollo y su capacidad de concepción de un desarrollo de más alto nivel, de practicar y adoptar buenas practicas que permitan pensar en algo mas estratégico en lugar de la táctica de corto alcance...


7. Gran parte del mercado de desarrollo se dirige a una complejización cada vez mayor de la tecnología, lo que nos lleva a estructuras de aplicaciones y ambientes cada vez mas complejos e interdependientes.

Todos estos puntos hacen que los problemas de mala gestión, falta de empiriscmo, falta de autogestion y de feedback que vienen a solucionar Scrum sean males "menores" comparados con no empezar a trabajar bien desde un punto de vista técnico desde el primer dia, utilizando buenas prácticas de desarrollo.

En síntesis es poco realista pretender que aplicando Scrum "a la Talibana" y después de unas pocas iteraciones o muchas el grupo vaya evolucionando y mejorando (ojo, que lo hace peroo no) a una velocidad tal que permita desarrollar un producto de muy buena calidad, sin deuda técnica, con alta cobertura de tests de unidad y con un Diseño de objetos solido y extensible, en pocas palabras, un sistema Mantenible (asi con "M" Mayuscula).

Es como pretender realizar un viaje en barco y comenzar el viaje sabiendo que el barco esta lleno de agujeros y se comienzan a tapar en medio del viaje. Lo mas probable es que cuando lleguemos a mitad del camino, en aguas profundas, el barco tenga tanta agua (léase Deuda Técnica) que ,aunque seamos cada vez mejores y mas rápidos en tapar agujeros, el barco (léase Proyecto) se hunda irremediablemente y sin necesidad de chocar contra algún tempano.