1,663
edits
No edit summary |
No edit summary |
||
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. | ||
*'''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=== | ===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 | |||
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 | 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 | 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 | *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 | 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 | 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 | 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 | 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 | |||
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 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]] |