Estoy cansado del movimiento ágil...

En mi anterior post reproducía algunos comentarios de Ivar Jacobson acerca del movimiento ágil. Creo que sus dichos reflejan lo que muchos pensamos: las principales ideas del movimiento ágil ya forman parte (o al menos deberían) del background de la mayoría de la gente (de ahí a que las pongan en práctica es otro tema). Se habla tanto de "agilidad" que prácticamente ha perdido su significado (lo mismo está pasando con lean).

Por esa misma razón, creo que no tiene sentido ya hablar de "ágil" versus "no ágil." Los que estamos en este negocio desde hace años sabemos que para cada problema hay un enfoque determinado; para un desarrollo pequeño, de baja complejidad, las herramientas deben ser forzosamente sencillas. Para emprendimientos más complejos, el enfoque debe ser diferente. En todos los casos debemos ser ágiles y estar en condiciones de adaptarnos.

Por supuesto que debemos aceptar que en todos estos años hemos aprendido mucho. Algunos "evangelistas" que se inmolan en el púlpito olvidan que el enfoque "tradicional" era el único que había para desarrollar software, aunque en general lo que se hiciera fuera "codificar y probar". Lo que muy bien ha hecho el movimiento ágil fue integrar ideas que estaban dando vueltas desde hace mucho, tomar prestadas algunas otras de otros dominios (por ejemplo, del desarrollo de productos) y agregar las suyas. Su filosofía y las prácticas que propone ya forman parte del cuerpo de conocimiento de la ingeniería de software.

Lo que creo que nunca terminaremos de entender como profesionales es cuánto es suficiente. Me he topado con gente que no entiende que el planeamiento debe ser gradual y progesivo y piden "planes detallados" cuando no es el momento. O supuestos "especialistas" que hacen planes de proyecto con tareas tan granulares que duran menos de quince minutos ("Agendar reunión"). O gente que quiere cerrar los requerimientos antes de empezar con el desarrollo y se consume la mitad del tiempo y los recursos en preparar una propuesta de proyecto. Hace años que sabemos que en la mayoría de los proyectos los planes y los requerimientos se irán refinando en forma progresiva. Me causa un poco de gracia cuando algunos agilistas acusan al ciclo de vida en cascada de todos los males de este mundo. La verdad, no he visto en veinte años un proyecto con ese ciclo de vida (y dicho sea de paso, muy pocos con algún ciclo de vida). ¿Alguien vio alguno?

En el otro extremo, me he encontrado con desarrolladores que no pueden estimar el esfuerzo de hacer algo. Sus argumentos son que simplemente no pueden hacerlo. "OK, pero estamos hablando de una componente de tal tipo, de tales características, para hacer esto". "No puedo hasta que no lo haga". ¿No es de locos? Por supuesto que el desarrollo de software es buena medida exploratorio, pero sigue siendo imporante para el negocio hacer pronósticos. "¿Vamos a gastar 20 pesos o dos millones de dólares?".

En definitiva, creo que el único camino es balancear constantemente lo que sabemos y aplicar adecuadamente las herramientas. Los extremos son malos...

Jacobson habla del movimiento ágil

Acabo de topar con un muy interesante post de Ivar Jacobson de abril de este año. Hace allí algunas reflexiones acerca de la saturación que está produciendo el movimiento ágil en algunos actores. Aparentemente, la gente está empezando a aburrirse de todo lo que tenga la etiqueta "ágil" (últimamente, casi todo).

Jacobson no está en contra del movimiento ágil, pero llama a tener una actitud un poco más equilibrada para balancear la práctica con la postura de los evangelistas desenfrenados.

Uno sólo de los párrafos da para iniciar un debate que probablemente sea interminable:

"Fortunately agile has grown up a bit – and the zealots have mostly been replaced by more reasonable proponents who know that there are many good things in agile approaches, but they need to be blended with other things to really be successful."

Que lo disfruten.

40 años de ingeniería de software. ¿Valieron la pena?

Tom DeMarco acaba de publicar un excelente artículo en donde presenta algunas reflexiones con motivo de cumplirse cuarenta años de la famosa conferencia de la OTAN en la que se presentó por primera vez el término ingeniería de software.

DeMarco hace una profunda autocrítica del papel que jugó su libro Controlling Software Projects: Management, Measurement, and Estimation en el establecimiento de una obsesión colectiva en torno a la predictibilidad y el control, aspectos que se tornaron en algo demasiado relevante dentro de la ingeniería de software.

A continuación, reproduzco algunos de los párrafos más importantes:

"...strict control is something that matters a lot on relatively useless projects and much less on useful projects."

"Can I really be saying that it’s OK to run projects without control or with relatively little control? Almost. I’m suggesting that first we need to select projects where precise control won’t matter so much. Then we need to reduce our expectations for exactly how much we’re going to be able to Control them, no matter how assiduously we apply ourselves to control."

"Consistency and predictability are still desirable, but they haven’t ever been the most important things. For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business."

DeMarco concluye su artículo con una clarificadora reflexión:

"Software development is and always will be somewhat experimental. The actual software construction isn’t necessarily experimental, but its conception is. And this is where our focus ought to be. It’s where our focus always ought to have been."

Una crítica al sistema lean

En estos últimos días he estado leyendo un excelente libro llamado "Myths at Work", en donde se analizan y critican varias de las creencias más arraigadas en el management moderno, tales como la globalización, la participación de la mujer en el mundo del trabajo,el sistema lean, etc.

Más allá de estar de acuerdo o no con todo lo que los autores plantean, creo que es muy interesante el análisis que hacen de cada uno de los temas. La mayoría de las veces se adoptan escuelas de pensamiento como si fueran "modas", lo cual genera expectativas desmedidas que después no se cumplen y que terminan "quemando" el tema. El mundo de la tecnología está repleto de ideas que prometieron resolver todos nuestros problemas y que luego cayeron en el olvido.

Hay muy buenas ideas en el movimiento lean, pero hay que sopesar -como en todo los órdenes de la vida- todos sus aspectos. Los autores de este libro lo hacen y demuestran que no todo es color de rosa.

Se pueden consultar algunos capítulos en Google Books.