En lo últimos años palabras como Agile o Lean se han convertido en buzz words que todo el mundo dice aplicar en sus desarrollos de software y de producto
Las empresas han hecho grandes inversiones en programas de transformación de procesos y cultura con el objetivo de ser ágiles en el desarrollo de productos y servicios basados en software, tratando de cambiar la forma de trabajo y adoptando metodologías ágiles tipo Scrum, XP, Kanban. Incluso la industria se ha profesionalizado, llegando a aparecer certificaciones como Scrum Master.
No seré yo quien ponga en cuestión ni la validez de los programas de transformación, ni de las metodologías ágiles (aunque prefiero llamarlos métodos o buenas prácticas). Todo lo contrario, bien aplicados pueden ser muy útiles y generar el cambio deseado. Pero mas allá de los manifiestos y de los libros de metodologías ágiles (un buen ejemplo es Métodos Ágiles y Scrum – Manuales Imprescindibles), muchas veces se pierde de vista lo que realmente significa ser Agile en el desarrollo de productos basados en software.
Lo primero que hay que entender es la naturaleza del desarrollo de software. Tal como explicábamos en el post «Hay música en el desarrollo de software», también en el libro «Historias de Developers», el desarrollo de software es incierto por naturaleza y por tanto, no es planificable ni predecible a priori. En el mundo científico e ingenieril, siempre que en un sistema o problema hay incertidumbre, se aplican técnicas de gestión adaptativa.
En el fondo estas técnicas se basan en la ejecución de ciclos de hypotesis-sintesis-realization-feedback, hasta que se hace converger el sistema a un determinado estado o se hace emerger una solución al problema. El equivalente a esos ciclos en el desarrollo de software son lo que llamamos ciclos de intention-sintesis-realization-feedback (ISRF), que de una forma tácita se pueden observar en un desarrollador cuando está programando.
Para hacer que su código funcione, el desarrollador está inmerso en ciclos continuos y entrelazados de diseño, codificación, ejecución y pruebas que duran desde segundos hasta horas y días. Una dificultad añadida en el desarrollo de software está en que hay que descubrir a la vez tanto el problema a resolver como su solución software. Ambos son inciertos. Ahora bien, mediante la gestión adaptativa basada en la ejecución de ciclos ISRF se puede hacer emerger tanto la especificación del software como su realización (arquitectura, código, ejecutables).
Podríamos decir que, en el fondo, los métodos ágiles no son más que una serie de buenas prácticas para la gestión adaptativa del desarrollo software. El fin último es manejar la incertidumbre inherente al desarrollo de software, para hacer que un equipo de personas creativas con altos conocimientos hagan emerger tanto la especificación del problema como su solución software.
Diría que ésta es la parte fundamental a entender y a aplicar de forma correcta. Idealmente en la vida real esta gestión adaptativa se debería llevar a cabo en un espacio de tiempo y con recursos limitados (de lo contrario el coste sería infinito), con un equipo totalmente comprometido a llegar al máximo posible en cuanto a funcionalidad y calidad del software (el coste es fijo, la calidad y funcionalidad software a la variable). El feedback y la comunicación continua entre el equipo es absolutamente clave para poder ejecutar ciclos ISRF cortos, rápidos y efectivos.
En algunos equipos, especialmente los pequeños y con personas de alta capacidad, en los que las prácticas ágiles se manifiestan de forma tácita (como ocurre muchas veces en el “garaje” de una startup). En otros casos, los métodos ágiles pueden servir de guía. No obstante, siempre que se apliquen de una forma explícita, se deberían adaptar de acuerdo a los skills y a la naturaleza del equipo, y nunca forzarlos de forma imperativa. Muchas veces se aplican métodos y prácticas ágiles religiosamente, perdiendo de vista lo que es verdaderamente importante: llevar a cabo una gestión adaptativa de la incertidumbre inherente al desarrollo de software, sea con un método o sin él.
Imágenes: Riebart / Allan / Thomas Guest
