|
Good Agile, Bad Agile y otros fundamentalismos |
|
|
30.09.2006 |
Good Agile, Bad Agile es el título del artículo en el que Steve Yegge, programador de Google, cuestiona aspectos y prácticas de los modelos ágiles, y que estos días ha causado cierto revuelo entre blogs y foros del mundillo.
Este tipo de situaciones: de críticas entre posturas diferentes, mejor o peor argumentadas son de un análisis muy rico tanto para aprender sobre el tema que tratan, como por la miga sociológica que revelan.
Los humanos necesitamos conocer el porqué de las cosas, aprehender la realidad del entorno en el que trabajamos; pero la realidad no es lineal y plana, es multidimensional. No se trata de la melodía simple de una flauta dulce sino del concierto de un una orquesta sinfónica.
Trabajamos y nos movemos en sistemas complejos de múltiples dimensiones en las que operan muchas variables que actúan de forma relacionada y coordinada.
En la construcción de conocimiento que vamos desarrollando y mejorando de forma continua para explicar porqué determinada realidad se comporta así, vamos revelando algunas variables, sus relaciones y parte de alguna dimensión.
Con ellas elaboramos hipótesis, y desarrollamos modelos de la realidad que nos muestran un poco la explicación que andamos buscando.
Pero un modelo es sólo el boceto de una visión parcial de la realidad.
El desarrollo de software, como cualquier realidad, es my rica y compleja, y además cada empresa debe operar con esas variables y dimensiones para adecuarla a sus circunstancias y entorno e interpretar su propio concierto.
Por supuesto que en la realidad del desarrollo de software interviene la "dimensión" de procesos, por supuesto que también interviene la de las personas; también la tecnología, la cultura organizacional...
Y si miramos los entornos posibles...
Hay quien desarrolla software para guiar misiles balísticos, para gestionar los saldos bancarios de sus clientes, para crear juegos en videoconsolas, para retocar fotografías, etc.
En este escenario es en el que un buen día Steve Yegge se da cuenta de lo bien que funciona en "su realidad" de trabajo de Google: el que los programadores no tengan directrices pre-fijadas, que dediquen un buen porcentaje del tiempo de trabajo a mirar e investigar cosas diferentes al proyecto que tienen entre manos, que los gestores dediquen la mitad de su tiempo a programación, etc.
Y todo lo que ve es cierto, funciona bien y le da valor a Google. Tiene razón.
Podría sintetizar un modelo, una metodología de trabajo, etiquetarla como "Google-Agile" y difundirla.
Jeff Sutherland hizo algo parecido hace 10 años, sintetizó el conocimiento de una metodología de trabajo que empleaba en su empresa: Easel Corporation. Lo etiquetó como Scrum y junto con Ken Schweber lo presentó como metodología de desarrollo.
Profesores de universidades, investigadores y expertos de nuestra industria han descubierto también mecanismos e interacciones de variables y dimensiones que funcionan bien: CMMI, ISO, ITIL...
El problema surge al decir: "¡Eh chicos, no le déis más vueltas!. Este es el modelo bueno, y no el vuestro!. ¡Pero dónde váis, madre mía que tonterías decís!.
Y ya metido en harina, el artículo de Steve, aunque peca de esta tendencia fundamentalista, tiene también algunas incorrecciones políticas interesantes al cuestionarse el tema de los "$eminario$ de formación" que, si bien por su enfoque anti-agilidad sólo ve los abusos en un lado, en realidad se producen en todas las líneas que enseñan forman y asesoran sobre "su" modelo de la realidad.
Se puede llegar a entender que merezca la pena pagar bien por oir hablar a Watts Humphrey sobre CMMI o a Jeff Sutherland sobre Scrum, pero en esta realidad tan compleja resulta que al final, estos enseñaron a otros, que hicieron un modelo en el que mantienen su negocio enseñando a otros que llevan gráficos y textos en proyectores y leen los guiones.
Si la corrección no me lo impidiera os diría detalles y anécdotas sobre el nivel del seminario de 3 días de introducción a CMMI que me costó 2.000 eurazos que harían sonrojar (espero) al formador y la firma de consultoría que lo impartió, o las dudas que me plantean los conocimientos que pese al diploma de "ScrumMaster", puede tener alguien que no sabe inglés, tras haber estado 2 días en un curso de scrum impartido en inglés por un formador de menos experiencia en programación que los propios asistentes.
Pero claro, es que también hay otra realidad compleja: la de la formación consultoría y asesoría que se generan alrededor de los diferentes modelos de conocimiento, en el que se da con frecuencia que personas con muy poca experiencia y preparación, muestran a empresas que no tienen nada que ver con Easel Corporation lo bien que les va a ir aplicar Scrum "a calcetín", o que nada más entrar por la puerta, sin diagnosticar ni observar la realidad de esa empresa saben que lo mejor va a ser que implanten CMMI o incluso, como me ocurrió a mi personalmente me dijera una firma de asesoría que, bueno, nunca habían trabajado con empresas de software, pero que eso no tenía nada que ver, que ellos eran expertos en implantar ISO9001 y que seguro que si mi departamento era conforme con ISO 9001 lo sería con esa ISO 12207 o 15504 que yo decía (¿?¿?¿?).
Blogalaxia Tags: CMMI agilidad scrum extreme+programming formación crítica
|
|
|
Suscripción RSS 
