Metodologías ágiles: malas, buenas,... y la de Google

Vía JoelOnSoftware llego a este interesantísimo, aunque larguísimo, post de Steve Yegge: " Good Agile, Bad Agile". En él hace un dura crítica a las metodologías ágiles como metodología de desarrollo de software. Lo curioso es que lo que comenta como ejemplo de una buena metodología de ágil es lo que nos cuenta de cómo trabajan en Google: (traducido "más o menos")

• Existen "managers", pero la mayoría de ellos escriben código al enos la mitad de su tiempo, haciendoles más como "gurús-tecnológicos"
• Los desarrolladores pueden cambiar de equipo o proyectos en cualquier momento que quieran, sin preguntas.
• Google tiene la filosofía de no decir nunca a los desarrolladores en qué deben trabajar, y se lo toman muy en serio.
• Los desarrolladores son fuertemente animados a gasta el 20% de su tiempo (de horario laboral) en trabajar en lo que ellos quieran, con tal que no sea en su proyecto principal.
• No hay muchas reuniones. Quizás de media tres por semana, incluyendo una charla con su líder.
• Hay tranquilidad. Los ingenieros están silenciosamente centrados en su trabajo, individualemtne o en pequeños grupos de 2 a 5 personas.
• No existen diagramas de Gantt o hojas con tareas-personas-fechas ni otros artefactos de gestión de proyectos visibles, no que yo haya visto.
• Incluso los relativamente raros periodos de estrés, la gente todavía va a comer y cenar, las cuales son gratuitas, y no se trabaja en horas intempestivas a menos que se quiera .

Vaya, Impresionante, no? Seguro que se te hace un poco raro trabajar en una empresa así. No parece una empresa típica-media de desarrollo de software, al menos de las que yo he pasado o conozco. En el artículo comenta que hay tres tipos de empresas que funcionan más o menos así: las "start-ups", las universitarias y Google. el mérito de Google es haber mantenido ese tipo de trabajo con su escala actual, con el tamaño que tiene, sin haberse burocratizado.
Pero de todas maneras ¿es esto una metodología ágil? más bien creo que esto son directivas de funcionamiento de la empresa, o su filosofía, pero de ahí a poder afirmar que estas técnicas son las buenas ágiles, y las de XP o Scrum las malas, me parece que va un abismo.
Hay que diferenciar claramente dónde y para quién se desarrolla el software. Según parece en Google !no tienen presiones con las fechas de lanzamiento! Vamos, la panacea. Parece que el interés de los desarrolladores en crear algo ya es suficiente. Cuando el proyecto está terminado, se lanza. ¿Dónde hay que firmar?... Pero bueno, en el mundo real, los clientes presionan, los de márketing anuncian un producto mucho antes de su finalización, los directores cuentan ya con sus ingresos... o sea, que las fechas existen, y sobre todo, un día llegan.
Y ahí es precisamente donde creo que las metodologías ágiles ayudan con sus ciclos cortos de desarrollo (entre otras cosas) para poder acercarse las fechas objetivo con productos cada vez más cercanos a las peticiones reales de los clientes.
Sin duda un gran artículo que os recomiendo leer sobre el funcionamiento interno de Google. Un funcionamiento que dificilmente puede ser extrapolado a otro tipo de empresas de software, pero del que se podrán aprender muchas cosas. Otra cosa es que como crítica a las metodologías ágiles ande un poco desencaminado, pues compara metodologías muy pragmáticas, con filosofías de empresa, que para nada son incompatibles, simplemente son niveles distintos en muchos aspectos.
Eso sí, un día Google dominará el mundo :D aunque sea únicamente por que tendrá los mejores desarrolladores de software. Bueno, menos a mi, que me pilla un poco lejos.