Desde la misión Apollo al Ejército de Simios de Netflix, la construcción de productos software ha vivido una evolución vertiginosa.
La misión Apollo llevó al hombre a la luna en 1969. Fue necesario construir el software necesario para despegar, guiar y alunizar la cápsula espacial. Margaret Hamilton fue la jefa de desarrollo de un equipo formado por más de 400 matemáticos y científicos computacionales encargados de construir el software. Hamilton fue una pionera en una época en la cual la construcción de software no se consideraba una ingeniería. Quizás fue la primera persona en emplear el término “Ingeniería del Software”.
💬 Comencé a usar el término Ingeniería de Software para distinguirlo del hardware y otros tipos de ingeniería. Trate cada tipo de ingeniería como parte de un proceso de más amplio alcance que unía ingenierías de otros sistemas [..]
Margaret Hamilton
En 1968 la construcción de software era una actividad caótica. Hasta finales de los 60s, el software se desarrollaba de forma “doméstica” o artesanal. Era habitual que el único usuario del software fuese el propio programador. El programador (artesano) trabajaba individualmente construyendo el software estrechamente ligado al hardware. Tampoco disponía de las poderosas herramientas con las que hoy en día contamos para el desarrollo de software, sus únicas herramientas eran un manual de programación habitualmente ofrecido por el propio fabricante del hardware y su ingenio. Cuando el software comenzó a ser utilizado por muchos usuarios y a ser ejecutado en cientos de máquinas, el software pasó a ser considerado un “producto”. El software, debido a su creciente complejidad, ya no podía ser desarrollado por un único programador sino que eran requeridos equipos multidisciplinares. Los artesanos de finales de los 60 no estaban preparados para generar un “producto software” de calidad. Los sobrecostes, los incumplimientos de plazos, el software ineficiente y de baja calidad, requisitos no satisfechos, eran habituales en el sector. Todo ello terminó por desembocar en la ”crisis del software”. Era imprescindible establecer procesos de ingeniería para el desarrollo de software.
En octubre de 1968 tuvo lugar una conferencia sobre desarrollo de software en Múnich (Garbisch) financiada por la OTAN. Allí fue donde se adoptó el término, hasta entonces prácticamente desconocido, de “ingeniería de software”.
La conferencia estudió la aplicación de las técnicas de ingeniería al desarrollo de software. La ingeniería del software pretendía ofrecer a las empresas de desarrollo de software la ventaja de la “repetitividad”: El producto es consecuencia del proceso, no de las personas. Aplicar un mismo proceso logra un mismo producto. Además, la monitorización y permanente revisión de los procesos de construcción permite mejorarlos. Para todo ello se pautó el desarrollo en fases. Cada fase no debe iniciarse sin haber terminado la anterior. Además, cada fase es desarrollada por un equipo de especialistas.
A partir de la conferencia, la construcción de productos software pasó a sustentarse en la gestión de proyectos en base a planificaciones detalladas y en procesos de construcción estandarizados. Como consecuencia la industria propuso las “Fabricas de Software”. Los arquitectos diseñan los “planos” del software y los programadores, asumiendo el rol de operarios u obreros, se limitan a codificarlos.
Todo ello desembocó a mediados de los 90 en el Proceso Unificado. El Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. Prescribe una gran cantidad de roles, actividades y artefactos para la construcción de productos software.
Paralelamente surgen sistemas de evaluación, por ejemplo, CMMI, para medir la calidad del proceso usado en función de la cantidad de actividades, roles y artefactos generados.
Pronto afloraron inconvenientes en los modelos planteados. Esta visión basada en la “predictibilidad” del proceso de construcción de software tenia graves problemas intrínsecos. Algunos ingenieros críticos señalaron estos problemas.
Fred Brooks, en su libro “El Mítico Hombre-Mes”, introdujo en 1975 algunos anti patrones de la industria como la equivocada creencia de que al aumentar el número de personas trabajando en un proyecto se logrará acortar los plazos. También explicó conceptos fundamentales como la complejidad “esencial” y la complejidad “accidental” del código.
💬 La falacia básica del modelo en cascada es que asume que un proyecto pasa por el proceso una vez, que la arquitectura es excelente y fácil de usar, el diseño de implementación es sólido, y la realización es corregible en el proceso de pruebas. Otra manera de decirlo es que el modelo en cascada asume que todos los errores estarán en la realización y, por lo tanto, su reparación puede ser suavemente intercalada con las pruebas de componentes y del sistema
Fred Brooks
La industria del software observó con preocupación cómo la visión predictiva no parecía estar funcionando. Estos problemas se pusieron de manifiesto en la década de los 90. Debido a la alta percepción de fracaso en los proyectos software, la consultora especializada en gestión de proyectos software “Standish Group” realizó una investigación cuantitativa sobre el éxito de estos proyectos en el año 1994, el resultado fue el Informe CHAOS. Este informe cosechó gran repercusión. ¿Está la industria implementando mal el modelo o es el modelo el que está equivocado?
A finales de los 80, algunas de las industrias más afectadas por las nuevas tecnologías de la información y la comunicación abandonan sus viejos modelos predictivos y crean nuevas formas de construcción propias con los que obtienen mejores resultados que sus competidores. En 1986, Hirotaka Takeuchi e Ikujiro Nonaka recogen algunas de estas exitosas experiencias, en el paper The New New Product Development Game. El articulo propone un nuevo modelo de desarrollo que permite el solapamiento entre actividades. Durante la práctica totalidad del desarrollo concurren todas las actividades. De esta forma, más que fases que se realizan de forma secuencial, las actividades simplemente se ejecutan en el momento que se requieren. Requisitos, análisis, diseño técnico, codificación y pruebas se van realizando en cada momento según las necesidades en la evolución del proyecto.
El alto grado de fracaso en los proyectos software, lleva a algunos profesionales de la industria del software a dejar de lado los modelos predictivos y adoptar los principios de adaptabilidad identificados por Nonaka y Takeuchi. A finales de los 90, reputados profesionales comenzaron a cuestionar las metodologías formales basada en procesos predictivos. Los críticos comienzan a explorar procesos alternativos para la construcción de software: Scrum, propuesto por Jeff Sutherland y Ken Schwaber en 1993, y Extreme Programming (XP), propuesto por Kent Beck en 1999.
En marzo de 2001, diecisiete críticos de los modelos de desarrollo de software basados en procesos predictivos, se reunieron en Salt Lake City para discutir sobre el desarrollo de software. En aquella reunión nació el Manifiesto Ágil.
💬 Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:
A los individuos y su interacción, por encima de los procesos y las herramientas;
El software que funciona, por encima de la documentación exhaustiva;
La colaboración con el cliente, por encima de la negociación contractual;
La respuesta al cambio, por encima del seguimiento de un plan
Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
Tras los cuatro valores descritos, los firmantes redactaron los doce principios que de ellos se derivan. Estos doce principios subrayan la importancia de entregar con frecuencia software que funciona, aceptar los cambios, la excelencia técnica y el desarrollo sostenido.
El manifiesto propone una nueva forma de construir software, sustituyendo la visión predictiva, por otra visión adaptativa. La visión adaptativa “abraza el cambio”, elimina los silos de especialistas y busca la excelencia técnica.
🔎 En 2009 otro movimiento, liderado por Robert C Martin escribió una extensión sobre los principios del desarrollo de software, el “Software Craftsmanship Manifesto”. El fin de este manifiesto es guiar el desarrollo de software hacia la excelencia técnica. Es una respuesta a los males percibidos en las prácticas establecidas de la industria, entre otros la priorización de las preocupaciones financieras sobre la responsabilidad del desarrollador.
Desde la publicación del manifiesto ágil en 2001, las metodologías ágiles han vivido una rápida y exponencial implantación en la industria.
Los ingenieros de software han pasado a centrarse en la entrega iterativa y temprana de producto con valor funcional. Poco a poco se han eliminado los silos de conocimiento prescritos por las metodologías predictivas. Los equipos de analistas, de arquitectos, de codificadores, de testers, de operaciones han sido sustituidos por un único equipo de desarrollo plenamente autónomo y multidisciplinar cuyos integrantes suman todas las competencias necesarias para construir un producto con éxito.
Asimismo, la industria ha sido capaz de dotarse de cada vez más potentes herramientas capaces de automatizar muchas de las tareas definidas por los modelos de desarrollo. La automatización logra la sistematización y estandarización del proceso de desarrollo de software. La automatización era la principal meta de la visión predictiva. La visión predictiva llegó a definir y clasificar las herramientas de automatización, denominadas CASE. Sin embargo, los ingenieros de los 70 y 80 no fueron capaces de prever las tareas que en el siglo XXI serían automatizadas: Integración Continua, propuesta por Martin Fowler en el 2000; contenedores de dependencias, propuestos por Martin Fowler en el 2004; Git, propuesto por Linus Torvald en 2007; Contenedores de aplicaciones en 2013; etc.
La industria está cada vez más entregada a la búsqueda de la excelencia en el código, a las buenas prácticas, al testing automatizado y a la entrega continua y temprana de producto con valor. Por ejemplo: Microsoft utiliza metodologías adaptativas a la hora de construir sus productos, Spotify concibió una nueva forma de escalar scrum en las grandes organizaciones con el “Modelo Spotify”, Netflix revolucionó la industria al adoptar exitosamente una arquitectura orientada a microservicios e implantar novedosas estrategias para evitar la degradación del servicio como su “Ejército de Simios”
🔎 El ejército de simios es un conjunto de programas (“simios”) desarrollados por el equipo técnico de Netflix en 2009 para comprobar la salud y las medidas contra fallos de sus sistemas informáticos. Los “simios” son programas encargados de provocar fallos en producción. Por ejemplo, el “mono del caos” inhabilita, de forma aleatoria, servidores de producción. Los ingenieros de netflix deben diseñar sus sistemas con la certeza de que los fallos sucederán (ellos mismos los van a provocar al poner en funcionamiento su “ejército de simios”). De esta forma, un fallo en producción, por ejemplo, la caída de un servidor, es indistinguible del funcionamiento habitual.
El éxito de la visión adaptativa en el desarrollo de software no ha pasado desapercibido para otras industrias:
Marketing. El “Agile Marketing” adapta los valores y principios agilistas a la industria del marketing. Incluso cuentan con su propio manifiesto: Manifiesto Agile Marketing
Emprendimiento. En la creación de startups y negocios emergentes se hace uso de las ideas adaptativas. Lean Startup es un ejemplo.
Automoción. Incluso se ha experimentado el uso de dinámicas ágiles en la construcción de automóviles: Aplicando principios del desarrollo de software en la construcción de automóviles
Aviación. Para la construcción de los nuevos aviones de combate F35 la industria aeronáutica decidió experimentar con técnicas ágiles. Los resultados no fueron los esperados: 'Agile' F-35 fighter software dev techniques failed to speed up supersonic jet deliveries
Referencias:
• K.Beck; "Extreme Programming Explained", Addison-Wesley Professional, 1999
• F.Brooks; "The Mythical Man-Month: Essays on Software Engineering", Addison-Wesley, 1975
• R.C. Martin "Arquitectura Limpia", Anaya, 2018
• J. Palacio; "Flexibilidad con Scrum", 2008.
• H. Kniberg; "SCRUM y XP desde las trincheras", InfoQ, 2007
• R.Jeffries; "The Nature of Software Development", Pragmatic Bookshelf, 2015
• I. Sommerville; “Ingeniería del Software”, Addison Wesley, 2005
• R. Pressman; “Ingeniería del Software: Un enfoque práctico”; McGraw-Hill, 2005.
• B. W. Boehm, "Software Engineering Economics", Prentice Hall,1981
• L. Artola, “Software Economics”, LeanPub, 2020
• T. Winters y H. Wright, “Software Engineering at Google”, O’Reilly, 2020
• J.Garzas; https://www.javiergarzas.com/