Espiral de conocimiento

Conocimiento en continua evolución

Los marcos de prácticas ágiles no surgen en los proyectos TIC como “tesis” sino como “antítesis” del conocimiento de Ingeniería del Software que se venía empleando.

Comenzaremos viendo qué significa esto para tomar la distancia y conseguir la perspectiva que revela las razones de la agilidad y sus diferencias con la ingeniería de procesos, no desde las prácticas concretas sino desde los principios en los que se basan, y con ello comprender las fortalezas y debilidades de la agilidad. Esta visión desde las razones y los principios de los diferentes marcos y metodologías, más allá de la visión enfocada en las diferencias entre metodologías y prácticas concretas es clave para dar el salto de gestión técnica a gestión experta.

El patrón dialéctico

La evolución y mejora del conocimiento se produce al cuestionar el conocimiento actual, siguiendo de este modo un patrón dialéctico de tesis, antítesis y síntesis. De manera esquemática el patrón dialéctico puede definirse como la evolución que contrapone una antítesis a una determinada concepción, entendida como tesis. Esta antítesis muestra los problemas y contradicciones de la tesis. De la confrontación surge un tercer momento llamado síntesis, una resolución o una nueva comprensión del problema.

De esta forma la estrategia de aplicar ingeniería de procesos para atajar los retos de los proyectos de software es la tesis a cuyos problemas y contradicciones se contrapone la agilidad. El reto de los proyectos TIC se identificó por primera vez en 1968 en la primera conferencia sobre desarrollo de software celebrada por la organización OTAN, en la que se acuñó el término “crisis del software” para definir los problemas comunes y recurrentes de los proyectos de software que siempre desbordaban las agendas y los presupuestos de sus planes iniciales, además de no conseguir resultados con la calidad esperada. La conclusión de la conferencia de la OTAN de 1968 Dijkstra 1969 fue la necesidad de crear una disciplina científica que como ocurría en otras áreas, permitiera aplicar un enfoque sistemático disciplinado y cuantificable al desarrollo, operación y mantenimiento de los sistemas del software, es decir, la aplicación de la ingeniería de procesos al software. Fue el nacimiento de la Ingeniería del Software. La primera estrategia de la Ingeniería del software (tesis) se ha basado en dos pilares:

• Ingeniería de procesos
• Gestión predictiva (rel.)

El primero para aplicar el principio básico de calidad contrastado con éxito en los entornos de producción industrial: “la calidad del resultado depende de la calidad de los procesos empleados”.

El segundo para garantizar el cumplimiento de agendas y presupuestos.

Mientras este conocimiento iba evolucionando y perfeccionándose a través de diferentes modelos de procesos y cuerpos de conocimiento de gestión de proyectos (MIL-Q9858, ISO9000, ISO9000-3, ISO 12207, SPICE, CMM-SW, ISO 15504, CMMI, etc.) en la industria del software surgían dudas y se cuestionaba esta estrategia. ¿La planificación predictiva es apropiada para cualquier proyecto? ¿Los criterios de éxito son siempre el cumplimiento fechas, costes y funcionalidades preestablecidas?

Empiezan a surgir proyectos que no tienen como finalidad construir un sistema que previamente se ha definido y planificado en su totalidad, y para los que no es realista trazar un plan cerrado desde su inicio. Proyectos en los que no interesa saber si el sistema final tendrá 20 o 200 funcionalidades y conocer cómo serán éstas en detalle: Su interés es poner un nuevo sistema en el mercado lo antes posible y desde ese momento evolucionar la visión y mejora el valor de forma continua.

Por otra parte se le cuestiona también a la tesis el considerar al desarrollo de software como un proceso industrial. Se empieza a aceptar que puede ser más importante para la calidad del resultado, el conocimiento tácito de la persona que lo realiza que la calidad del proceso que emplea.

Desde los orígenes de la agilidad, mediados de los 90, hasta 2005-2010 han sido habituales las posturas radicales entre los defensores de los modelos de procesos y de los marcos ágiles, posiblemente más enfocados en descalificar al otro que en revisar y depurar los propios métodos.

Algunos ejemplos de esta tensión:

"La diferencia entre un atracador de bancos y un teórico de CMM es que con el atracador se puede negociar"… "La evaluación en CMM depende más de una buena presentación en papel que da la calidad real del producto de software. Tiene que ver más con el seguimiento a ciegas de una metodología que con el desarrollo y puesta en producción de un sistema en el panorama tecnológico". Orr. 2003

"Si uno pregunta a un ingeniero de software típico si cree que CMM se puede aplicar a los métodos ágiles, responderá o con una mirada de sorpresa o con una carcajada histérica". Turner & Jain, 2002

Espiral dialéctica del conocimiento

El conocimiento profesional evoluciona de forma continua porque la realidad en la que se aplica está en permanente movimiento, y también porque siempre es posible mejorar los métodos actuales. La aplicación de nuevas técnicas, procesos o modelos genera sus propias antítesis que revelan las debilidades, contradicciones y puntos de mejora que conducen el avance hacia una síntesis, que pasará a ser una nueva tesis que con su uso generará su antítesis, desarrollando a través de este patrón dialéctico una espiral de evolución continua del conocimiento Takeuchi & Nonaka 2004

En disciplinas no técnicas y en generaciones anteriores el ritmo de avance sobre esta espiral dialéctica permitía a los profesionales desempeñarse con los conocimientos adquiridos en su licenciatura durante toda su carrera profesional. Sin embargo hoy esto no es posible, especialmente en el sector TIC No hay métodos, prácticas o modelos de trabajo que nos ayuden con solvencia durante mucho tiempo, sino conocimiento en evolución. Esta es una consideración clave en el marco de Scrum Manager y la razón por la que no define un modelo fijo, sino un conocimiento actualizado como base para una gestión más experta que técnica. Más basada en el criterio documentado y experto del gestor que en la aplicación de prácticas o procesos.