martes, 29 de abril de 2014

A las metodologias agiles se las comio el sistema I




Si Señores y Señoras (para ser politicamente incorrectos) aqui estamos nuevamente despues de un nuevo impasse en escribir este blog y antes del siguiente impasse cuando dejaremos de escribir en este blog. El show debe continuar, que no se corte, asi que aquí vamos.


Hace poco en foro-agiles, el foro sobre metodologías agiles de la comunidad hispanoparlante, hubo una discusión sobre la corrupción de Agiles como concepto, originada en  sendos articulos de Uncle Bob Martin, The True Corruption of Agile, y Dave Thomas, Agile is dead.

A raiz de eso @gabrielMorrisS escribio un interesante post Corrupcion o acomodacion Agil del cual rescato la siguiente frase:

"No estoy diciendo que la corriente ágil sea la verdad absoluta, de hecho no
lo es, pero si creo que se debe ser consecuente con los principios que se
recitan a viva voz. No creo en fanatismos desbordados pero tampoco en la
acomodación relativa de las cosas por simple conveniencia."



En mi opinión, el problema de la corrupción de agiles no tiene tanto que ver con la proliferación de cursos solo focalizados en practicas soft  o los cursos que se basan solo en como gestionar proyectos agiles, o en temas humanos y de comunicación. Aunque claro,  en uno de estos cursos, como parte del mismo  hacían olerse las manos unos a otros, en otro te hacían representar películas con tus cuerpos...okay  quizás si esas practicas sean demasiado _________,  no se como nombrarlas.

Es decir, estas practicas (y principios y valores) bien dictados y por gente capaz y honesta cson interesantes y útiles y tan solo por la simple imposición de un proceso ordenado y simple (valga la redundancia) con foco en la comunicación y en las personas generan una gran mejora inicial respecto al caos anterior. 

Pero el problema es cuando es lo único que se enseña y aplica porque entonces la mejora no se sostiene a largo plazo.

Y lo que veo que pasa habitualmente es lo siguiente:

Una empresa  quiere  empezar a aplicar metodologías ágiles va y entonces contrata precisamente uno de
esos cursos. Supongamos que el curso esta bien dado, todos tienen los rudimientos de un proceso como Scrum y terminan todos muy contentos. Listo.
Respecto a la  parte técnica, bueno , claro, eso  ya vendrá mas tarde, todavía no estamos maduros, la gente tecnica ya sabe lo que tiene que hacer, solo aplicando scrum nos alcanza, etc etc , pongan aqui la excusa que quieran pero lo que sucede es que la empresa empieza a aplicar Scrum sin aprender, sin practicar, sin EXIGIR, ningun cambio en como se escribe el codigo sin intentar siquiera aplicar las mal llamadas practicas hard, las practicas mayoritariamente tecnicas como  TDD, pair programming, refactoring, clean code, continous integration, etc.

Lo cierto es que aprender la parte tecnica, las 13 practicas originales (surgidas de XP) es mucho mas difícil y trabajoso,  y conlleva mucho mas tiempo y esfuerzo que las practicas soft. Los gerentes y/o PMs no las entienden ni entienden cuan imprescindibles son, y cuando si lo hacen de cualquier manera el  tiempo apremia, los deadlines se acercan, y se corta el hilo por lo mas hard (quiero decir, lo mas delgado :P , por lo técnico). 

Entonces, la tipica implementacion de agiles que veo, una y otra vez es la siguiente:

1 - Los que eran Lideres o Project Managers antes ahora se llaman Scrum masters. Los Usuarios clave ahora son Product Owners.

2 - Hacemos Sprints de una semana o dos o tres o tres meses, da lo mismo, total, lo importante es hacer iteraciones.

3 - Se hará alguna que otra reunión a la que llamaremos planning meeting y alguna otra cada dos o tres dias que llamaremos Daily (?).

4- Hacemos reunion al final de cada sprint o proyecto, para festejar o echarnos la culpa a todos, las llaman "retrospectivas"


Y es verdad que la sensacion dentro del equipo y hasta para el usuario es la de ir mas rapido. Y el foco en las historias mas importantes hace que se vea mas valor agregado. Y al ir pasando los sprints por lo menos los usuarios se ven mas involucrados, se los consulta. Y todo esto es fantastico, estamos llendo ahora en un auto cada vez mas rapido a 150 km por hora hasta que....
Hasta que empieza a acumularse codigo mal hecho, a las apuradas ("ey, ni siquiera hay tiempo de testear demasiado, lo haremos al final"), comienzan a aparecer presiones (estas historias tienen que estar terminadas para el fin de este sprint). Y el codigo comienza a acumular deuda tecnica, rapido porque la corrupcion del codigo crece siempre de manera exponencial y antes de que nos demos cuenta.....el auto comienza a vibrar, cuesta cada vez mantenerlo en la ruta deseada y luego de un par de sprint mas  estrellamos el proyecto contra el arbol del codigo inmantenible (lo confieso, la metafora me quedo algo forzada). 

Hay un sintoma que no falla: cuando comienza a haber modulos que no tocamos por miedo, cuando un simple cambio produce regresiones importantes, ya sabemos como sigue,y  lo peor, ya sabemos como termina esa pelicula (los buenos mueren).

Asi se terminan usando *solo* las practicas soft de agiles (y en la palabra "solo" reside el problema) y entonces los miembros de los equipos, usuarios y clientes terminan pensando  que  agiles es solo eso. Y esto es tremandamente peligroso porque no solo fracasa un proyecto sino que el mismo concepto agil se ve manchado, como dice Uncle Bob, corrompido.


 Asi en lugar de una verdadera metodologia agil, tenemos una especie de Cargo Cultismo Agile ( http://en.wikipedia.org/wiki/Cargo_cult o aqui mismo), honran todas las ceremonias del culto,  tocan tambores, construyen torres de control de madera pero.... los aviones no llegan.

2 comentarios:

  1. Creo que las llamadas "prácticas soft" lograron entrar en el mundo de las empresas y eso es un logro importante. Ahora es tiempo de encontrar la forma de mostrar que las prácticas de ingeniería (o más duras) son importantes tambipen. Escribí sobre esto acá: http://ernestokiszkurno.blogspot.com.ar/2014/04/las-practicas-de-gestion-no-son-mas.html

    Seguimos pensando..

    ResponderEliminar
  2. Conteste a Ernesto en su blog y olvide comentarlo aca tambien....Comment duplications is evil!!!!! Pero bue, aca va: Gracias por comentar Ernesto. Coincidimos, Sucede exactamente lo mismo en las empresas que estan aplicando las metodologias de desarrollo Agiles. Se focalizan solo en las practicas de gestion, de mejora de la comunicacion y organizacion de los proyectos pero de las practicas duras o tecnicas nadie se ocupa. Y es una lastima porque de acuerdo a los autores XP en particular y Agiles en general historicamente surgieron como un contrapeso de la parte de gestion, como una forma de tender un puente entre el gerenciamiento y la parte puramente tecnica, de ingenieria. "Old habits die hard" dice la cancion.

    ResponderEliminar