Las empresas en período
de transformación organizacional se enfrentan a la dicotomía de seguir paradas
sobre el triángulo de hierro en lo
que se refiere a planificación y gestión de proyectos de software o moverse a
una zona que en principio se les parece más al Triángulo de las Bermudas que al área de confort por donde han
transitado durante las últimas décadas.
De lo más valioso que
hemos aprendido en el desarrollo de software es que muchas de las prácticas y
técnicas usadas desde aquella histórica reunión del Comité Científico de la OTAN en 1968 en la ciudad de Garmisch, Alemania y que diera inicio a
la Ingeniería de Software como profesión, fueron tomadas a manera de préstamo
de otras áreas de la ingeniería y de otras ciencias aplicadas.
Algunas de esas
prácticas influyeron directamente en la forma de realizar estimaciones y de planificar
proyectos de software. Específicamente, hemos aprendido que no podemos estimar
ni planificar proyectos de software como lo hacen en proyectos de la industria
de la construcción… ¡a no ser que vayamos
a usar piezas de Lego® para construir ciudades!
Afortunadamente ya
sabemos con certeza que la ingeniería de software tiene su propia personalidad.
Se trata de un sello que la hace única y que hace que sus practicantes se
distingan del resto de profesionales de la ingeniería y de otros cuerpos de
conocimiento. Por ejemplo, en su libro Agile Project Management,
Jim Highsmith[1]
sugirió que si aplicamos el enfoque Ágil al Triángulo de hierro encontraríamos
los siguientes vértices:
- Valor, para el usuario en términos de un producto que se pueda distribuir y cuyo uso genere beneficios para la organización.
- Calidad, para entregar continuamente valor al usuario en términos de un producto confiable y adaptativo.
- Restricciones, los ya tradicionales alcance, tiempo y costo, en donde, si movemos uno, usualmente el primero, se mueven los otros dos.
Como dice el mismo
Highsmith [2], las restricciones siguen siendo parámetros importantes de un
proyecto pero no constituyen el objetivo del mismo. En cambio, el Valor y la
Calidad establecen la meta del proyecto y las restricciones mencionadas se
ajustan a medida que el proyecto incrementa el valor para el usuario. En
particular, El tiempo podría seguir siendo una restricción fija pero entonces
el alcance debería ajustarse para entregar el valor más alto posible dadas las
restricciones impuestas.
Más allá de este enfoque de planificación y de gestión de proyectos (ágiles), quienes ya hemos trasegado algunos años por los vericuetos, subido a los riscos y caminado por los valles complejos del desarrollo ágil de software, sabemos que todo momento es una oportunidad de mejorar: de mejorar como personas y como profesionales, de mejorar los procesos y las técnicas, de mejorar la calidad de los productos y de incrementar el valor que estos entregan a nuestros usuarios. ¡Es la mejora continua!
Ahora bien, la mejora
continua junto al valor y a la calidad forma otro vértice del triángulo, el del
resultado. A los agilistas no nos
interesa simplemente crear un producto, por más disruptivo o benéfico que este
sea. Nos interesa pensar en lo que viene, en lo que llevará al cliente al
próximo nivel de optimización, satisfacción y felicidad.
Pero lo más importante
en todo proyecto, en todo proceso de innovación o mejoramiento, en todo plan
que tenga como propósito el diseño y la construcción de productos (de
software), son las personas: la comunicación cara a cara entre ellas, la
motivación de todos los individuos que intervienen en el proyecto, la atención
continua a la excelencia técnica, la autogestión del equipo y la confianza que
la organización deposite en ellas se constituyen en las bases del éxito de
cualquier iniciativa que requiera generar nuevos productos o servicios.
Las cosas así, podríamos
entonces encontrarnos con esta nueva versión del triángulo ágil:
Referencias:
