Con relativa frecuencia, normalmente al dar alguna charla sobre agilidad, o de buenas prácticas software en general, en algún curso, a veces en algún comentario del blog, etc., suele haber alguien, normalmente veterano en esta profesión, que me dice algo así como…
“- La mayoría de las cosas que recomienda la agilidad, o en general las buenas prácticas para desarrollo software, gestión de proyectos, equipos, etc., que tanto se comentan ahora, como si fuesen nuevas, son muy antiguas, da la sensación de que estamos reinventando la rueda o inventando de nuevo la ingeniería del software-“.
Y, ciertamente, no se pueden negar razones para que alguien piense lo anterior.
No en vano, prácticas que algunos hoy ven como novedosas (y que, porque no decirlo, otros venden como novedosas) son realmente antiguas. Por poner sólo algunos ejemplos y evitar alargar mucho este post, por mucho que el ciclo de vida iterativo-incremental típico de la agilidad se “venda” como novedoso… sus comienzos se remontan a los 50 (como ya comentamos aquí), utilizar unidades basadas en la complejidad – riesgo para estimar y medir velocidades, en lo que se basan los puntos historia… es una idea de los 70 (aunque en agilidad la idea está mucho más refinada), etc.
Así que, si conocías dichas prácticas de antes, y ves que ahora toman popularidad, es razonable pensar… “-¿estamos reinventando la rueda o inventando de nuevo la ingeniería del software?-“
Más allá de motivos puramente, llamemos… comerciales, es decir, de que haya gente a la que le interese vender buenas prácticas ya con años… como algo nuevo y revolucionario, y más allá del desconocimiento que, en ciertos entornos, reina en el área de la gestión e ingeniería software, y que favorece que esto pase, más allá de los anteriores, yo tengo, y quería compartir contigo, una tercera razón de por qué creo que vivimos en la época de inventarnos de nuevo la ingeniería del software: la comunidad, quizá inconscientemente, está rescatando del probable olvido las mejores buenas prácticas de gestión e ingeniería del software.
Si nos remontamos a hace unos 15 años, no mucho más, la gestión e ingeniería del software estaba descrita, principal y mayoritariamente, en un único soporte: los libros. Lo que se recomendaba, lo que se difundía, lo que se estudiaba, lo que se ponía de moda, etc., estaba en soporte libro en papel (mayoritariamente).
Si volvemos al día de hoy, lo que se recomienda, lo que se difunde, lo que se estudia, lo que se pone de moda, etc., está en la web (mayoritariamente).
Ya muy poca gente va a una biblioteca a encontrar el último libro en papel para estar actualizado, la gente va a la web.
Los libros en papel siguen, y seguirán vigentes, pero entendiéndolos de otra manera. Ahora no son los que generan el conocimiento, ahora es la web, pero los libros si que son los que muchas veces ordenan y sintetizan ese conocimiento que ahora genera y lidera la web. Primero va la web y segundo va el libro. La gente llega al libro desde la web. Como, por ejemplo, pasa con mis propios libros, de todo el conocimiento, muchas veces disperso, que he ido generado en esta web, en este blog, un día veo que es necesario ordenarlo y sintetizarlo… y así hago con él, creando un libro, y aparece, por ejemplo, gestión ágil de proyectos software.
Y en los últimos años lo que hemos estado haciendo como comunidad es pasar el conocimiento que había sólo en los libros en papel… a la web, y de paso, actualizándolo un poco.
Lo que ahora está sólo en libros y no haya sido escrito en la web, que a estas alturas será poco, podríamos decir que está muerto, ha desaparecido.
Así que, si conocías un motón de libros de gestión e ingeniería software, y un montón de prácticas escritas en los mismos, el empezar a ver webs que re-escriben dicho conocimiento, ya de paso con algún cambio, produce, razonablemente, el efecto de pensar que nos hemos inventando de nuevo la gestión e ingeniería software. El cambio de soporte (de papel a web) se daba a ello, y lo propiciaba.
Claro que, por otro lado, dejando a un lado la sensación de “me están vendiendo algo que ya sabía”, puedes ver la parte positiva de esto: como comunidad, al migrar conocimiento de papel a web, en ese paso, hemos filtrado lo mejor, lo hemos refinado y lo hemos salvado de desaparecer en el olvido.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
En 1968 se habló de la «crisis del software». Yo me pregunto, ¿La crisis del software, es inherente al proceso de desarrollo del software? Porque han pasado 46 años y muchas cosas han cambiado, esto parece estar igual.
La ingeniería del software ha muerto, ca. 1970. Se intentó aplicar lo que sabíamos sobre construir rascacielos, máquinas, ordenadores, etc. al desarrollo de software. No funcionó.
Y lo siento por los ingenieros y los estudiantes; La carrera de ingeniería es completamente obsoleta, especialmente en España. El programa siempre estará 10 años (mínimo) detrás de tecnologías que caducan en menos de la mitad de ese tiempo. Un ingeniero informático sale hoy de la universidad con un cuerpo de conocimiento teórico válido, en muchos casos incompleto, pero muy lejos de poder aplicarlo a un problema real, algo que se supone corresponde a los ingenieros e ingenieras.
El agilismo no propone ninguna metodología (yo no se porque seguimos repitiendo eso) El agilismo propone 4 cosas:
1. Individuos e interacciones por sobre procesos y herramientas.
2. Software que funciona por sobre documentación exhaustiva.
3. Colaboración con el cliente por sobre negociación del contrato.
4. Respuesta al cambio por sobre seguir un plan.
El 2do y el 4to punto en particular colisionan con la mayoría de los amarillentos cadáveres de árbol juntando polillas en las bibliotecas.
Reinventar no es malo porque 20 años atrás, a nadie se le hubiera ocurrido que una versión diferente de software se podía entregar al cliente cada semana… ¡O con cada pequeño cambio!
DELETE FROM [books] WHERE [title] LIKE '%GESTIÓN%SOFTWARE%';
Un saludo!
Coincido con los criterios expresados en el post, en mi opinión esa impresión novedosa surge de la amplia difución que han obtenido estas prácticas a partir del interés que despierta el manifiesto ágil en donde se sintetisa y compendia el conjunto de elementos lógicos que estructuran estas ténicas previamente existentes y empleadas, sólo que no desde una perspectiva integral. De igual forma, siguiendo el razonamiento del post, el gran soporte informativo en que se ha transformado la web engendra este tipo de fenómeno de reinvención de la rueda, por el infortunado hecho de ignorar la previa existencia de la misma.
Muy buena tu teoría sobre la difusión actual del conocimiento. Estoy muy de acuerdo con ella pero no hay que olvidar los riesgos que trae fiarse de lo que puedes leer en un artículo de internet del que desconoces los méritos del autor. Además de que estos artículos suelen quedar algo incompletos en comparación con un libro. Lo típico de la rama y el bosque.
Pero ni reinventar ni rescatar, yo lo dejaría en evolucionar. Con todo lo bueno que ello conlleva.
Por ejemplo, si nos centramos en la llamada buena práctica Integración Continua. Algo que ni mucho menos es novedoso. El artículo de Martin Fowler es del 2006 pero ya se estaba haciendo mucho antes. Pues bien, me acuerdo que en mi primer trabajo, me tocó revisar una buena parte de las librerias del proyecto para ver si estabamos en la última versión porque… oh… teniamos un bug pero a lo mejor era de alguna libreria y no nuestro… ja!
Bueno pues cuando me metía en los proyectos de Apache me encontraba con unas versiones en la página de descargas que no entendí hasta mucho después: las nighty builds.
En aquel entonces eran simples empaquetados de la librería. Pero hoy en día estas builds ejecutan tests, analizadores de código, realizan despliegues, etc.
El concepto es el mismo hoy que entonces, sólo que mucho más evolucionado.