Espiral de conocimiento: Difference between revisions

Latest revision as of 15:10, 18 December 2023

La Espiral de conocimiento es un concepto que se utiliza para describir el ciclo de aprendizaje continuo y la mejora iterativa que ocurren en los equipos y organizaciones ágiles.

Esta idea se basa en la teoría de la "Espiral de conocimiento" desarrollada por Nonaka y Takeuchi en el ámbito de la gestión del conocimiento y la innovación organizacional.

Conocimiento en continua evolución

Los marcos de prácticas ágiles no llegan a los proyectos TIC como “tesis” de conocimiento, sino como “antítesis” al que la Ingeniería del Software venía desarrollando.

Comenzaremos viendo qué significa esto, y así tomar la distancia necesaria para ver con perspectiva las razones por las que los proyectos TIC abrazaron la agilidad a finales del siglo pasado, 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.

Alcanzar una visión de las razones y los principios de cada metodología, más allá de la concreción de un modelo es clave para dar el salto de gestión técnica a gestión experta. Esto es, de gestión basada en la aplicación de prácticas a gestión basada en la aplicación del propio conocimiento.

Gestión técnica: gestión basada en la aplicación de modelos de prácticas y procesos.
Gestión experta: gestión basada en el conocimiento tácito del gestor.

El patrón dialéctico

Al cuestionar el conocimiento, se inicia su evolución que sigue un patrón dialéctico de: tesis, antítesis y síntesis.

De manera esquemática el patrón dialéctico puede definirse como el ritmo de avance que contrapone una antítesis a una concepción previa, entendida como tesis. La antítesis muestra los problemas y contradicciones de la tesis, y 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 abordar con ingeniería de procesos los retos de los proyectos de software, supuso la primera la tesis para dar respuesta a la “crisis del software”, y sus problemas y contradicciones han sido puestos de manifiesto por su antítesis: la agilidad. En 1968, en la primera conferencia sobre desarrollo de software celebrada por la organización OTAN, se analizaron los problemas de la programación del software, y en ella se acuñó el término “crisis del software” para referirse a ellos.

La conclusión de la conferencia (Bauer, Bolliet, & Helms, 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. 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”.
Gestión predictiva. Para garantizar el cumplimiento de agendas y presupuestos.

Mientras esta disciplina evolucionaba y se perfeccionaba a través de diferentes modelos de procesos y cuerpos de conocimiento para gestión de proyectos (MIL-Q9858, ISO9000, ISO9000-3, ISO 12207, SPICE, SW-CMM…) 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 cuya finalidad no es construir un sistema previamente definido y planificado en su totalidad, y para los que no es realista trazar un plan cerrado desde el inicio. Proyectos en los que no interesa saber si el sistema final tendrá 20 o 200 funcionalidades, ni conocer cómo serán éstas en detalle: Su interés es poner una novedad en el mercado lo antes posible, y desde ese momento evolucionar la visión y valor de forma continua.

Por otra parte también se cuestiona si el software se puede producir con patrones de procesos industriales, y se empieza a aceptar que en la calidad del resultado puede ser más importante el el conocimiento tácito de la persona que lo realiza que el know-how aportado a través del proceso y la tecnología empleada.

Desde los orígenes de la agilidad, a 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".¹

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

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 la mejora siempre es posible.

La puesta en funcionamiento de nuevas técnicas, procesos o modelos genera sus propias antítesis al revelarse las debilidades, contradicciones y puntos de mejora, y el enfrentamiento de ambos conduce hacia una síntesis, que pasará a ser una nueva tesis, cuyo posterior uso producirá 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, en especial, 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.

Referencias

¹Orr., Ken (2003) "CMM versus Agile Development: Religious wars and software development", Cutter Consortium, Executive Reports.
²Turner, R.; Jain, A. (2002) "Agile Meets CMMI: Culture Clash or Common Cause?", XP/Agile Universe, pp. 153-165.

@@ Line 1: / Line 1: @@
 __NOTOC__
+La '''Espiral de conocimiento''' es un concepto que se utiliza para describir el ciclo de aprendizaje continuo y la mejora iterativa que ocurren en los equipos y organizaciones ágiles.
+Esta idea se basa en la teoría de la "Espiral de conocimiento" desarrollada por Nonaka y Takeuchi en el ámbito de la gestión del conocimiento y la innovación organizacional.
 ==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.
+Los marcos de prácticas ágiles no llegan a los proyectos TIC como “tesis” de conocimiento, sino como “antítesis” al que la Ingeniería del Software venía desarrollando.
+Comenzaremos viendo qué significa esto, y así tomar la distancia necesaria para ver con perspectiva las razones por las que los proyectos TIC abrazaron la agilidad a finales del siglo pasado, 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.
-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.
+Alcanzar una visión de las razones y los principios de cada metodología, más allá de la concreción de un modelo es clave para dar el salto de gestión técnica a gestión experta.  Esto es, de gestión basada en la aplicación de prácticas a gestión basada en la aplicación del propio conocimiento.
-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.
+*'''Gestión técnica''': gestión basada en la aplicación de modelos de prácticas y procesos.
+*'''Gestión experta''': gestión basada en el conocimiento tácito del gestor.
+===El patrón dialéctico===
+Al cuestionar el conocimiento, se inicia su evolución que sigue un patrón dialéctico de: tesis, antítesis y síntesis.
-===El patrón dialéctico===
+De manera esquemática el patrón dialéctico puede definirse como el ritmo de avance que contrapone una antítesis a una concepción previa, entendida como tesis. La antítesis muestra los problemas y contradicciones de la tesis, y de la confrontación surge un tercer momento llamado síntesis, una resolución o una nueva comprensión del problema.
-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.
 [[File:Patron dialectico 1.png|350px|center]]
+De esta forma la estrategia de abordar con ingeniería de procesos los retos de los proyectos de software, supuso la primera la tesis para dar respuesta a la “crisis del software”, y sus problemas y contradicciones han sido puestos de manifiesto por su antítesis: la agilidad.
+En 1968, en la primera conferencia sobre desarrollo de software celebrada por la organización OTAN, se analizaron los problemas de la programación del software, y en ella se acuñó el término “crisis del software” para referirse a ellos.
+La conclusión de la conferencia (Bauer, Bolliet, & Helms, 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.
-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.''' 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”.
+*'''Gestión predictiva.''' Para garantizar el cumplimiento de agendas y presupuestos.
-*Ingeniería de procesos
+Mientras esta disciplina evolucionaba y se perfeccionaba a través de diferentes modelos de procesos y cuerpos de conocimiento para gestión de proyectos (MIL-Q9858, ISO9000, ISO9000-3, ISO 12207, SPICE, SW-CMM…) en la industria del software surgían dudas y se cuestionaba esta estrategia.
-*Gestión predictiva ([[Consideraciones sobre la gestión de proyectos 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 cuya finalidad no es construir un sistema previamente definido y planificado en su totalidad, y para los que no es realista trazar un plan cerrado desde el inicio. Proyectos en los que no interesa saber si el sistema final tendrá 20 o 200 funcionalidades, ni conocer cómo serán éstas en detalle: Su interés es poner una novedad en el mercado lo antes posible, y desde ese momento evolucionar la visión y valor de forma continua.
-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 también se cuestiona si el software se puede producir con patrones de procesos industriales, y se empieza a aceptar que en la calidad del resultado puede ser más importante el el conocimiento tácito de la persona que lo realiza que el know-how aportado a través del proceso y la tecnología empleada.
-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.
 [[File:Tesis y antitesis.png|550px|center]]
-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.
+Desde los orígenes de la agilidad, a 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:
+<blockquote>''La diferencia entre un atracador de bancos y un teórico de CMM es que con el atracador se puede negociar...''</blockquote>
+<blockquote>''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''".<sup>1</sup> </blockquote>
+<blockquote>''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''.<sup>2</sup></blockquote>
+==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 la mejora siempre es posible.
-"''La diferencia entre un atracador de bancos y un teórico de CMM es que con el atracador se puede negociar''"…
+La puesta en funcionamiento de nuevas técnicas, procesos o modelos genera sus propias antítesis al revelarse las debilidades, contradicciones y puntos de mejora, y el enfrentamiento de ambos conduce hacia una síntesis, que pasará a ser una nueva tesis, cuyo posterior uso producirá su antítesis, desarrollando a través de este patrón dialéctico una espiral de evolución continua del conocimiento [[Takeuchi & Nonaka 2004]].
-"''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]]
 [[File:Patron dialectico 2.png|550px|center]]
-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
+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, en especial, 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.
+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.
+==Referencias==
+*<sup>1</sup>Orr., Ken (2003) "CMM versus Agile Development: Religious wars and software development", ''Cutter Consortium'', Executive Reports.
+*<sup>2</sup>Turner, R.; Jain, A. (2002) "Agile Meets CMMI: Culture Clash or Common Cause?", ''XP/Agile Universe'', pp. 153-165.
-[[Category:Scrum II]]
+[[Category:Glosario de términos]]