Espiral de conocimiento - Revision history

Mberne: /* Referencias */

2026-05-19T12:42:23Z

Referencias

← Older revision		Revision as of 14:42, 19 May 2026
Line 49:		Line 49:
	</div>		</div>
	== Referencias ==		== Referencias ==
	Orr, Ken. (2003). "CMM versus Agile Development: Religious wars and software development". ''Cutter Consortium'', Executive Reports.		* Orr, Ken. (2003). "CMM versus Agile Development: Religious wars and software development". ''Cutter Consortium'', Executive Reports.
			* Takeuchi, Hirotaka; Nonaka, Ikujiro. (2004). ''Hitotsubashi on Knowledge Management''. Wiley.
			* Turner, R.; Jain, A. (2002). "Agile Meets CMMI: Culture Clash or Common Cause?". ''XP/Agile Universe'', pp. 153-165.

	~~Takeuchi, Hirotaka; Nonaka, Ikujiro. (2004). ''Hitotsubashi on Knowledge Management''. Wiley.~~

	~~Turner, R.; Jain, A. (2002). "Agile Meets CMMI: Culture Clash or Common Cause?". ''XP/Agile Universe'', pp. 153-165.~~
	== Véase también ==		== Véase también ==
	<div class="bok-tags">		<div class="bok-tags">

Mberne at 13:23, 14 May 2026

2026-05-14T13:23:39Z

Show changes

Mberne at 14:01, 11 May 2026

2026-05-11T14:01:34Z

← Older revision		Revision as of 16:01, 11 May 2026
Line 60:		Line 60:

	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]
			[[Category:Marcos_y_modelos]]

Mberne at 14:10, 18 December 2023

2023-12-18T14:10:44Z

← Older revision		Revision as of 16:10, 18 December 2023
Line 42:		Line 42:
	Algunos ejemplos de esta tensión:		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 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>''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>		<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==		==Espiral dialéctica del conocimiento==
Line 55:		Line 55:

	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:Glosario de términos]]		[[Category:Glosario de términos]]

Mberne: /* El patrón dialéctico */

2023-12-18T14:09:10Z

El patrón dialéctico

← Older revision		Revision as of 16:09, 18 December 2023
Line 42:		Line 42:
	Algunos ejemplos de esta tensión:		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 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''". ~~([[Orr. 2003]])~~ </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''. ~~([[Turner & Jain, 2002]])~~</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==		==Espiral dialéctica del conocimiento==

Mberne: /* El patrón dialéctico */

2023-12-18T14:08:12Z

El patrón dialéctico

← Older revision		Revision as of 16:08, 18 December 2023
Line 25:		Line 25:

	La primera estrategia de la Ingeniería del software (tesis) se ha basado en dos pilares:		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”.		*'''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.		*'''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.		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.
Line 42:		Line 42:
	Algunos ejemplos de esta tensión:		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 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''". [[Orr. 2003]] </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''". ([[Orr. 2003]]) </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". [[Turner & Jain, 2002]]</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''. ([[Turner & Jain, 2002]])</blockquote>

	==Espiral dialéctica del conocimiento==		==Espiral dialéctica del conocimiento==

Mberne at 14:07, 18 December 2023

2023-12-18T14:07:00Z

← Older revision		Revision as of 16:07, 18 December 2023
Line 1:		Line 1:
	__NOTOC__		__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==		==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.		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, 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.		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 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.
	*'''Gestión experta''':~~Gestión~~ basada en el conocimiento tácito del gestor.


	===El patrón dialéctico===		===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.		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 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.


	[[File:Patron dialectico 1.png\|350px\|center]]		[[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.		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.		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 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:		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”.
	*Ingeniería de procesos:		*Gestión predictiva: para garantizar el cumplimiento de agendas y presupuestos.
	*Gestión predictiva:

	~~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 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.		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?		¿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 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.		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.



	[[File:Tesis y antitesis.png\|550px\|center]]		[[File:Tesis y antitesis.png\|550px\|center]]

	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.		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:		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''". [[Orr. 2003]] </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". [[Turner & Jain, 2002]]</blockquote>

			==Espiral dialéctica del conocimiento==
	~~"''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 la mejora siempre es posible.		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]]		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]].

	[[File:Patron dialectico 2.png\|550px\|center]]		[[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, en especial, 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.



	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]

Smanager at 08:14, 26 April 2021

2021-04-26T08:14:33Z

← Older revision		Revision as of 10:14, 26 April 2021
Line 82:		Line 82:


	[[Category:~~Scrum II~~]]		[[Category:Glosario de términos]]

Smanager at 13:36, 2 May 2014

2014-05-02T13:36:14Z

← Older revision		Revision as of 15:36, 2 May 2014
Line 11:		Line 11:
	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.		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.

	~~{{Párrafo_enmarcado\|texto=~~Gestión técnica: Gestión basada en la aplicación de modelos de prácticas y procesos.}}		*'''Gestión técnica''': Gestión basada en la aplicación de modelos de prácticas y procesos.
	~~{{Párrafo_enmarcado\|texto=~~Gestión experta:Gestión basada en el conocimiento tácito del gestor}}		*'''Gestión experta''':Gestión basada en el conocimiento tácito del gestor.


	===El patrón dialéctico===		===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.		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 ~~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 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.


	[[File:Patron dialectico 1.png\|350px\|center]]		[[File:Patron dialectico 1.png\|350px\|center]]


	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.		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.
	~~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.		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 ~~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 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:		La primera estrategia de la Ingeniería del software (tesis) se ha basado en dos pilares:

	*Ingeniería de procesos		*Ingeniería de procesos:
	*Gestión predictiva ~~([[Consideraciones sobre la gestión de proyectos predictiva\|rel.]])~~		*Gestión predictiva:

	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 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”.
Line 35:		Line 39:


	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.		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?		¿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.		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 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~~.		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.



	[[File:Tesis y antitesis.png\|550px\|center]]		[[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.


Line 62:		Line 69:

	===Espiral dialéctica del conocimiento===		===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~~.		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 ~~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]]
			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]]

	[[File:Patron dialectico 2.png\|550px\|center]]		[[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.



	[[Category:Scrum II]]		[[Category:Scrum II]]

Smanager at 12:34, 2 May 2014

2014-05-02T12:34:12Z

← Older revision		Revision as of 14:34, 2 May 2014
Line 2:		Line 2:

	==Conocimiento en continua evolución==		==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 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.

			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.

			{{Párrafo_enmarcado\|texto=Gestión técnica: Gestión basada en la aplicación de modelos de prácticas y procesos.}}
			{{Párrafo_enmarcado\|texto=Gestión experta:Gestión basada en el conocimiento tácito del gestor}}

	===El patrón dialéctico===		===El patrón dialéctico===