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...
