En los últimos meses, un tema se viene entrometiendo en las conversaciones que mantenemos con Alejandro Siri de Quanbit sobre los resultados finales de cada proceso de desarrollo de productos de software: un concepto denominado “Jardinería de Software” que se contrapone a la idea de “Ingeniería de Software”.
Es cotidiano comprobar que en cada situación en la que se le presenta una pieza de software recientemente terminada a la persona que ideó la pieza o producto, nacen de manera explosiva una incontable cantidad de nuevas ideas: ideas de mejoras a la pieza, ideas para interrelacionar o combinar esa pieza con otras y disparadores de ideas laterales no vinculadas directamente a la pieza original.
Estos desencadenantes de ideas, son sin duda un avance hacia el fin último: lograr implementación de la mejor idea posible. Además, cada nueva idea suele ser superadora respecto de la anterior. Este es un proceso dinámico muy ligado a la conducta humana en la que, de forma iterativa e incremental, se va logrando una maduración de la idea. Nuestra expectativa es que la implementación tecnológica vaya acompañando a esa maduración.
Pero la Ingeniería de Software tradicional propone una metodología de abordaje a la construcción de software que consiste básicamente en: definir la idea completa desde el principio, analizarla, diseñarla, implementarla y testearla, priorizando lospasos del proceso antes que la dinámica creativa de las personas.
El proceso ingenieril puede ser técnicamente excelente aún cuando se implemente una idea que se volvió obsoleta luego de ser diseñada. Agrega previsibilidad en tiempo y forma aún cuando la implementación de una “funcion del software” carezca de sentido.
El software suele valorarse por su utilidad en la implementación de una idea o concepto. Pero para poder implementar una idea que sufre una evolución continua, es necesario adoptar una metodología de construcción de software que permita incorporar al cambio como un elemento más del desarrollo. Para poder lograr un software últil, es necesario de priorizar a las personas y sus cambios por sobre los planes y procesos. Este enfoque es la base de las nuevas tendencias en materia de metodologías de construcción de software: las Metodologías Ágiles.
Es sabido que las Metodologías Ágiles ayudan a crear un software que implementa la mejor de las ideas posibles o la más perfeccionada, pero agregan incertidumbre para prever cuales, cuantas y cómo serán las funcionalidades a implementar… las respuestas aparecerán a lo largo del proyecto de desarrollo.
Siendo muy creativos con la siguiente analogía, podríamos pensar que al comienzo de un proyecto de desarrollo de software con Metodologías Ágiles solo contamos con una semilla (la idea) que nos da una noción del resultado final en base a las características de la especie a la que pertenece. Que si la plantamos y la regamos con un mix de creatividad, diseño, herramientas y programación, lograremos con el tiempo hacer crecer la planta (software) que buscábamos.
Lo curioso es que si el día de la plantación tuviéramos que describir cómo será exactamente esa planta cuando esté crecida, no podríamos saberlo, al menos no más allá de sus rasgos generales. Quizá podríamos estimar cuánto tiempo necesita para crecer, pero no podríamos predecirlo. Quizá podríamos prever que va a tener hojas verdes y ramas, pero no cuántas ni de qué tamaño exacto será cada una.
En definitiva, a la hora de construir software con Metodologías Ágiles, nos encontramos con que el proceso se asemeja más al de un trabajo de Jardinería que al de un trabajo de Ingeniería. Obviamente es un punto de vista gracioso pero tiene muchos disparadores que sirven para hacernos reflexionar cada vez que estamos en una conversación con alguien que piense que la construcción de software es un proceso exacto, previsible o estructurado.
Mientras tanto, podemos divertirnos (a nuestra manera) jugando con el nombre.
