Cuestionar lo conocido genera la contradicción, la tensión entre contrarios que actúa de motor en la evolución del conocimiento. No es nuevo. Lo afirmó Platón. En filosofía ha creado la escuela dialéctica , y Nonaka y Takeuchi, en su último líbro Hitotsubashi on Knowledge Management afirman también estár convencidos de que este patrón dialéctico de tesis, antítesis y síntesis dirige la evolución del conocimiento: antítesis que se oponen y cuestionan las tesis anteriores, y dan como resultado nuevas posturas de síntesis que a su vez harán el papel de tesis en el siguiente ciclo evolutivo; formando así una espiral de evolución y perfeccionamiento continuo. Estoy convencido de que los modelos basados en procesos han sido la "tesis" que inicia el conocimiento para desarrollar sistemas de software. Que la agilidad es su antítesis, y que estamos generando en estos años la síntesis; un resultado enriquecido de ambos, depurado y con mayor valor de conocimiento.
En 1968 la NATO organizó un congreso para ver qué pasaba con eso del software, porque en todos los proyectos siempre eran los subsistemas de software los que llegaban tarde, mal y nunca. Allí se etiquetó al fenómeno como "crisis del software" y se habló por primera vez de la necesidad de crear un conocimiento, una "Ingeniería del Software" para darle solución. Los ordenadores comenzaban a no ser excesivamente extraños, y la demanda de programas y programadores empezó a crecer, pero los héroes que se ponían a ello contaban con una base de conocimiento inexistente para ayudarles. Tan sólo disponían de los manuales de usuario de los sistemas operativos y de los lenguajes de programación. Unas referencias que ayudan a comprender la situación del conocimiento de aquellos años:
- En 1968 Edsger Dijkstra escribió su famosa carta "GoTo Statement Considered Harmful".
- La primera publicación sobre programación estructurada no vio la luz hasta 1974, publicada por Larry Constantine, Glenford Myers y Wayne Stevens.
- El primer libro sobre métrica de software fue publicado en 1977 por Tom Gilb
- El primero sobre análisis de requisitos apareció en 1979
El nacimiento de la Ingeniería del Software como respuesta a la crisis bautizada en el congreso de la NATO ha sido la primera tesis, el inicio del conocimiento para el desarrollo de sistemas de software. Esta "tesis" se construyó sobre las prácticas coetáneas, más o menos veteranas y más o menos contrastadas en otras ingenierías y en otros ámbitos:
- Desarrollo basado en procesos como garantes de calidad repetible y escalable.
- Principios de calidad de Juran (la calidad resultante depende de la calidad de los procesos empleados)
- Pautas de gestión de proyectos predictivas para garantizar la eficiencia y el cumplimiento de plazos y presupuestos.
En los 80 y 90 comienza a cristalizar su base de conocimiento: Modelos de procesos específicos para software: ISO9000-3 CMM's SPICE-ISO 15504 , Bootstrap, etc. Aplicación al software del patrón de gestión de proyectos predictivo aplicado en otras ingenierías: PMI , IPMA . Primer borrador de consenso sobre el cuerpo de conocimiento de la Ingeniería del Software: SWEBOK .
En los 90 comienza la difusión y aplicación de este conocimiento. En algunos ámbitos da buenos resultados, y en otros genera una réplica "dialéctica"; la antítesis de la conferencia de la OTAN: El Manifiesto Ágil, que cuestiona la validez de los modelos basados en procesos y la gestión predictiva para el desarrollo de software. Se radicalizan las posturas entre ambas líneas y se genera (y se está generando) la tensión entre contrarios que es el motor para el avance dialéctico del conocimiento.
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".
Ken Orr , CMM versus Agile Development: Religious wars and software development .
"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".
Richard Turner y Apurva Jain, Agile meets CMMI: Culture Clash or Common Cause .
Sin duda estamos en la resolución dialéctica de los extemos hacia una síntesis:
- En estos momentos autoridades de la Ingeniería del Software como Barry Boehm y Richard Turner hablan de balancear la agilidad y la disciplina y proponen un patrón de 5 factores discriminadores .
- ISO comprueba y anuncia que los modelos desarrollados funcionan en unos entornos, pero no en otros, y ha creado ya comités para desarrollar versiones más ligeras.
- Surgen iniciativas de normalización como MoProSoft que buscan puntos intermedios entre ambos extremos.
- Muchos profesionales plantean dudas sobre ambos extremos, y prueban con mayor o menor tiento y acierto soluciones híbridas .
Estamos determinando la primera oposición en la espiral dialéctica del conocimiento de la Ingeniería del software. Es un momento más confuso, durante el que ya no está tan claro el norte y es mas difícil orientarse. Resultaba mucho más cómodo 1995 por ejemplo. Con la tesis desarrollada, y sin haber despertado aún su antítesis ágil, sentíamos que habíamos alcanzado la verdad. Que ya sabíamos cómo desarrollar software. Que todo era cuestión aplicar pautas de ingeniería en fases secuenciales, con gestión predictiva... Ahora estamos a mitad de resolución entre esa tesis y la antítesis ágil.
La contradicción es el motror del avance, pero produce confusión, y además la velocidad de difusión que ha imprimido la generalización de internet en la segunda mitad de los 90 y el apresuramiento general del entorno, hace que se solapen las tres tendencias del ciclo.
ISO 15504, CMMI, Scrum, DSDM, Extreme Programming, etc. son grandes aportaciones y es mucho lo que se puede aprender de ellos, pero es iluso pensar de cualquiera que es la solución. El conocimiento va a estar evolucionando siempre y no tardarán mucho en quedar superados o mejorados por su propia evolución. Los libros sobre CMMI o Scrum de hoy, cuando los leamos dentro de pocos años serán ya libros de conocimiento desfasado. La evolución la movemos todos, cuestionando y sugiriendo mejoras.
|