Hoy en día, el mundo del desarrollo de software está dominado por el agilismo, siendo su máximo exponente Scrum. Sin embargo, Scrum no es un método que diga nada sobre cómo hacer software, sino uno que brilla como férreo supervisor del tiempo empleado por el equipo de desarrollo. Este artículo expone la pérdida de rumbo del movimiento ágil, la degradación de los profesionales y de la calidad de los productos, y cómo Scrum contribuye a ello.
El origen de Scrum
El origen de Scrum data de un artículo [11] publicado en 1986 en la revista Harvard Business Review cuyos autores, Hirotaka Takeuchi e Ikujiro Nonaka, describen un nuevo método de desarrollo de productos puesto en práctica por diversas empresas japonesas y estadounidenses a finales de la década de los setenta.
Estas empresas rompieron con el proceso tradicional de desarrollo de sus productos, consistente en una serie de fases perfectamente delimitadas, en cada una de las cuales un grupo de especialistas acometía su trabajo y, una vez terminado, daba el relevo a otro grupo para que se ocupara de la siguiente fase.
Compañías como Fuji-Xerox, Honda, NEC y Canon apostaron por un proceso que naciera de la colaboración de todos los miembros del equipo de forma que, por ejemplo, los ingenieros a cargo del diseño no se desentendieran del producto una vez entraba en la fase de creación de los prototipos, sino que colaborasen con sus compañeros supervisando que los diseños se materializaran de forma correcta. Por otra parte, el personal de fabricación –al trabajar con los ingenieros– podía asegurar que los diseños estaban en consonancia con la economía de escala. Las fases altamente delimitadas dejaron paso a un solapamiento de las mismas.
Este nuevo método, donde las fases de desarrollo de un producto se superponían y todo el mundo colaboraba, arrojó –según el estudio– excelentes resultados en forma de una reducción considerable del tiempo de desarrollo (de hasta un 50%) y, en cualquier caso, de un abaratamiento de los costes de producción. Sin embargo, todos los miembros de los equipos tuvieron que realizar un esfuerzo extraordinario a lo largo del proceso que se tradujo en jornadas de cincuenta y cinco horas semanales con picos de sesenta y cinco durante los dos años que, de media, tardaron en crear los nuevos productos. Con semejantes datos, las cifras dadas sobre la reducción del tiempo de desarrollo deberían corregirse pues están adulteradas por la monumental cantidad de horas extras invertidas.
Ken Schwaben expuso el Proceso de desarrollo SCRUM [9], inspirado por el trabajo de Takeuchi y Nonaka, en la conferencia Sistemas, lenguajes y aplicaciones basados en la programación orientada a objetos de 1995.
Aquel Scrum –entonces escrito en mayúsculas– se presentó como una mejora del enfoque iterativo e incremental de Pittman [8] para el desarrollo de software orientado a objetos. Ofrecía una solución a la necesidad que tienen los equipos de desarrollo de adaptarse a los cambios que siempre surgen dentro de un entorno complejo –como es el software– y que, además, emplea procesos empíricos o de caja negra, procesos carentes de una serie de pasos bien definidos y detallados, al contrario que los procesos teóricos empleados en la producción industrial.
Schwaben dividió el proceso en tres grandes fases:
- Planificación y arquitectura del sistema.
- Desarrollo.
- Cierre, que incluía –entre otras actividades– las pruebas del sistema.
La primera y la tercera fase se basaban en procesos teóricos, mientras que la segunda –dividida en iteraciones ya llamadas sprints– lo hacía en procesos empíricos.
La involución
El Scrum de hoy se parece bastante poco al de los noventa. Scrum se ha convertido en un método de gestión, ya nada dice sobre el software, que somete al equipo de desarrollo a un control férreo que a menudo termina derivando en presiones constantes y lo hace, no por una mala aplicación del método, sino porque así está pensado. La reunión de planificación busca el compromiso del equipo de acometer las tareas pactadas; las reuniones diarias, de revisión y la retrospectiva ejercen el control y se apela al compromiso adquirido para cumplir –sea como sea– con los plazos. Ese «sea como sea» puede leerse, sin demasiado temor a la equivocación, como «trabajando cincuenta horas semanales o más».
Scrum tiene vínculos evidentes con el taylorismo, realmente con el toyotismo pues está basado en el pensamiento Lean [10], y pienso que es terrible. Estoy seguro de que cualquier directivo o empresario pensará totalmente lo contrario: sería excelente si fuera posible hacer software tal y como se fabrican los productos en las cadenas de montaje. Lo sería pero es imposible.
Una de las etapas del proceso industrial es el diseño del producto que llevan a cabo los ingenieros electrónicos, mecánicos o de otra índole. ¿Alguien ha pensado en aplicar el taylorismo a esta etapa? ¿Alguien se imagina a un grupo de ingenieros de una empresa automovilística, a cargo del diseño de un motor, trabajando de la misma forma que lo hacen sus compañeros en la cadena de montaje? ¿No parece un poco absurdo? Siendo así, todo el mundo debería tener claro a estas alturas que todas las actividades que nos permite crear software de calidad son similares a esa etapa de la producción industrial. Aplicar el taylorismo a la creación de software es una aberración. Sin embargo, conozco colegas que trabajan en «factorías de software». Posiblemente, este término sea el mejor ejemplo de oxímoron del mundo de la informática; además denota una falta de entendimiento de lo qué es el software y de cómo se hace.
Los roles de Scrum
Scrum establece tres roles dentro del equipo:
- El propietario del producto que, idealmente, debe ser parte del cliente pero que, normalmente, es un intermediario entre éste y el equipo de desarrollo, además de un experto en el dominio. Un gestor.
- El Scrum Master es el responsable de implantar Scrum, fomentar las prácticas ágiles, asegurarse de que todos los eventos (reuniones) se lleven a cabo y aislar al equipo de desarrollo de interferencias externas, entre otras funciones. Otro gestor.
- El equipo de desarrollo.
Esta división es otra consecuencia de la aplicación del taylorismo. Se iguala a un grupo de personas, los creadores directos de riqueza, con dos gestores. No hay que discurrir mucho para darse cuenta de que la verdadera importancia la cobra la gestión dejando la creación de software como algo secundario. Es ridículo discutir la importancia de una buena gestión, pero no garantiza la creación de software de calidad.
El equipo de desarrollo debe ser multidisciplinar y carecer de jerarquía [3].
Multidisciplinar implica que todo el equipo debe ser capaz de realizar cualquier tarea, dicho de otra forma, no debería haber especialistas. Se busca que un reducido grupo de personas sea capaz de hacer de todo a costa, entiendo, de aceptar la mediocridad. Por favor, léase mediocridad como de calidad media, no como tendiendo a lo malo. La especialización extrema es mala pero también lo es el «hombre orquesta». Una persona especializada en diseño de bases de datos, por citar un ejemplo, seguramente realizará su labor excelentemente, pero puede resultar difícil asignarle trabajo en una organización donde haya cinco proyectos en curso. Por otra parte, el «hombre orquesta» es un individuo que sabe hacer un poco de todo pero que jamás alcanzará la excelencia en nada. Si alguien piensa que son preferibles profesionales mediocres pero versátiles, me permito advertir que hay relación de grado entre las actividades básicas del desarrollo de software. El programador mediocre es un mal diseñador o, peor aún, ignora qué es el diseño de software, y no suele ser un buen analista. Por tanto, no espere encontrar una persona de calidad media programando, analizado y diseñando. No existe.
Un equipo sin jerarquía se iguala siempre por abajo, es decir, por las personas menos competentes y con menos conocimientos. El maestro puede hacer el trabajo del aprendiz, pero el aprendiz no puede hacer el trabajo del maestro. Si se pretende igualar al arquitecto con un programador recién graduado, no se sorprenda si el primero sale huyendo. Se esgrime que la ausencia de jerarquía fomenta la responsabilidad compartida, pero ¿puede exigirse el mismo grado de responsabilidad al programador diez que al programador novel? En tal caso, sería el segundo quien saliera huyendo. ¡Adiós al equipo!
Estas dos características del equipo de desarrollo encierran –y esto no es culpa de Schwaber ni de Sutherland– un desprecio monumental por los profesionales. Una vez más el taylorismo hace acto de presencia. Se buscan trabajadores que sean fácilmente reemplazables y que no necesiten de una alta capacitación. ¿Conoce a alguien sin formación en informática o telemática que trabaje «haciendo» software tras haber realizado un curso de programación? Se busca que el equipo de desarrollo sea como el conjunto de operarios de una cadena de montaje; si hay alguna baja, se puede suplir rápidamente con un periodo de formación muy corto. Eso sí, nadie le podrá garantizar una jornada de cuarenta horas semanales.
Con un equipo Scrum así, ¿qué puede esperarse de la calidad del software? Ni está ni se le espera.
Una de las funciones del Scrum Master [3] es velar por la calidad así como por la productividad del equipo. Me pregunto cómo una figura como ésta puede hacerlo. ¿De verdad un gestor puede dar consejos para mejorar la calidad del software cuando no está inmerso en el desarrollo del proyecto? Un profesional productivo es aquel capaz de hacer software de calidad pues hay una relación estrechı́sima entre ambas. Dado que se ha apostado por la versatilidad y la calidad media, se puede esperar que la productividad no sea alta. Siendo así, ¿cómo garantiza el Scrum Master que se cumplan los plazos de los sprints? La única manera que tiene de hacerlo es presionando al equipo. Con la ayuda de su fiel aliada, esa herramienta amiga del mal llamada JIRA, recordará en la insoportable, y para muchos muy estresante, reunión diaria que usted tiene que acabar la tarea asignada para hoy «sí o sí».
La perenne crisis del software
El informe CHAOS, elaborado por The Standish Group, evalúa cada uno o dos años los resultados de más de diez mil proyectos y lo lleva haciendo desde los años noventa.
El siguiente gráfico recoge los resultados del informe desde 1994 hasta 2019. Los números representan el porcentaje de proyectos exitosos (a la izquierda), problemáticos (en el centro) y desastrosos (a la derecha). Siendo más precisos:
- Un proyecto exitoso es aquel terminado a tiempo, dentro del presupuesto y con la funcionalidad y características especificadas.
- Un proyecto problemático es un proyecto terminado y operativo, pero por encima del presupuesto, violando los plazos y/o con menos funcionalidad y características de las especificadas.
- Un proyecto desastroso es el cancelado antes de llevarse a cabo o aquel que nunca se completó.
Durante los noventa la situación era un desastre absoluto: solo en torno a un 23% de los proyectos acababan bien y casi el 33% se cancelaban, suponiendo la pérdida de millones de dólares a empresas y organismos públicos.
En 1995 se presenta Scrum y en 1998 el Proceso unificado de desarrollo de software. Ambos procesos se basan en el desarrollo iterativo e incremental en contraposición al modelo en cascada que era el predominante por aquel entonces. Resulta curioso ver por la red cómo se suele asociar el agilismo con el desarrollo iterativo e incremental en exclusiva, cuando el Proceso Unificado –que no suele ser considerado ágil– también lo usa. Pero es más, el primer desarrollo evolutivo, iterativo e incremental se aplicó en el proyecto Mercury iniciado en 1958 [4].
Por fortuna, en el siglo XXI se abandona paulatinamente el modelo en cascada –un modelo que, sin embargo, puede ser perfectamente válido para proyectos diminutos– y los datos mejoran. Sin embargo, la mejoría es discreta. En la última década el 30% de proyectos son exitosos, lo que implica un incremento de siete puntos respecto a los noventa, y se han reducido el porcentaje de proyectos desastrosos hasta el 19%, una bajada de trece puntos. El caso es que en 2019, solo tres de cada diez proyectos terminaron cumpliendo con lo acordado en términos de coste, plazo y funcionalidad.
Todos aquellos que venden Scrum y el agilismo como el bálsamo de Fierabrás –un remedio mágico– contra los problemas que tiene el software deberían hacer una seria reflexión sobre los datos expuestos.
La crisis continúa, pero hay una gran diferencia con los años noventa y principios de siglo. Entonces había personas, auténticos genios y maestros, que trabajaban para encontrar una solución a la crisis o, al menos, paliarla. Booch, Jacobson, Rumbaugh, Kruchten, Gamma, Martin, Fowler o Beck son solo algunos de ellos. Hoy la sensación que me embarga es que el mundo del software, tomado por el agilismo, está invadido por un grupo de charlatanes de feria, con escasa formación científica y técnica, que repiten los principios ágiles como si fueran mantras. Auténticos vendedores de humo, muchos de los cuales hace años que no escriben una línea de código –si es que alguna vez lo hicieron– y que no han vuelto a leer un libro desde que terminaron sus estudios. La Guía Scrum no es un libro. El puesto de Scrum Coach y el de Scrum Master son el lugar idóneo para encontrárselos.
Siento tener que ser tan vehemente porque sé que toda generalización es siempre injusta, pero hemos alcanzado unos límites insoportables de frivolización del desarrollo de software. Por ejemplo, es sorprendente la cantidad de artículos que aconsejan sobre qué lenguaje de programación aprender en 2022. Saber sobre tres lenguajes de programación y cuatro frameworks es un concepto mal entendido de sabiduría que, además, no capacita para hacer software de calidad.
La pérdida de rumbo del agilismo
El Manifiesto Ágil [6], y especialmente sus principios, supuso un punto de inflexión en el desarrollo del software. El agilismo ha enriquecido nuestra profesión con técnicas extraordinarias como el desarrollo dirigido por pruebas, la refactorización o la integración continua, pero se ha volcado casi en exclusiva en la programación y en las pruebas.
7.º principio: El software funcionando es la medida principal de progreso.
Manifiesto ágil
Tener el software funcionando como sea y tratar como algo secundario el análisis y el diseño orientado a objetos y la definición de la arquitectura, dificulta la creación de un software de calidad. En mi opinión, este enfoque ha perjudicado a la industria, además de devaluar nuestra profesión.
Hace muchos años, un compañero en la empresa donde trabajo, un brillante ingeniero electrónico dedicado a hacer hardware, me definió la ingeniería como «el arte del diseño». Un ingeniero electrónico, como uno mecánico tiene muy claro que su profesión gira en torno al diseño. Aprender a diseñar fue aquello que convirtió a los analistas-programadores de los noventa en ingenieros de software. El software se puede y debe diseñar. El agilismo mal entendido ha destrozado el concepto haciendo creer que se puede pasar del análisis de requisitos a la programación sin mayores problemas.
Tras veinte años pueden volverse a ver ofertas de empleo ofreciendo puestos de analista-programador. Puedo entender que se busquen analistas o programadores, pero no la combinación de ambos. Al hacerlo se manda un mensaje muy claro: aquí no se diseña.
El taylorismo aplicado al software –cuyo máximo exponente es Scrum– está transmitiendo que cualquier persona con nociones de programación puede hacer software. La devaluación de nuestra profesión es terrible. Si no tomamos conciencia de que hacer software de calidad exige muchos más que conocimientos de programación y los adquirimos, difícilmente podremos aspirar a mejores salarios. Si no aportamos conocimiento que marque la diferencia y aporte valor, cualquiera vendrá a ocupar nuestro puesto y hará el trabajo igual de bien (o mal).
Recuerdo, por si alguien está pensando que a lo mejor es cierto que cualquiera puede hacer software, que hoy día solo tres de cada diez proyectos acaban bien.
Programar es fácil, pero hacer software es muy difícil. Entre los requisitos del sistema y un producto listo para entregar al cliente, o desplegarlo en sus instalaciones, hay mucho más que mera programación. Para definir cómo enfocar la ejecución de un proyecto, saber qué hay que programar y cómo hacerlo empleando formas sencillas y accesibles de comunicación, que también sirvan de base para la revisión del trabajo y la posterior evolución del proyecto, es para lo que se usa el análisis y el diseño.
El diseño no es una actividad esotérica donde se apliquen oscuras técnicas proporcionadas por la intuición, tampoco es una tarea documental sin ninguna utilidad que nadie va a necesitar. El diseño es transversal al desarrollo del software y está vinculado a muchas otras actividades de entre la que sobresale una: la programación. El diseño es código pero el código no es necesariamente diseño, de forma similar a cómo el conocimiento de un lenguaje orientado a objetos no capacita –es condición necesaria pero insuficiente– para crear software orientado a objetos.
No soy, mi admirado Robert C. Martin un artesano [7], soy ingeniero y lo soy porque sé diseñar.
Hay quien puede argumentar que el agilismo no renunció al diseño sino que lo enfocó de una manera diferente a como lo hace el Proceso Unificado: lo llamaron diseño incremental y, ciertamente, es uno de los pilares del agilismo junto con las pruebas de aceptación, la refactorización, el desarrollo dirigido por pruebas (TDD) y la integración continua.
Todos ellos se aplican en la Programación Extrema (XP) creada por Kent Beck, un método ágil de desarrollo de software, al contrario que Scrum que no es más que un método de gestión. Aunque no comparto ciertos enfoques de XP, pienso que es el único método ágil serio, el diseño es una práctica central y tiene como objetivo la creación de software de alta calidad.
Siendo Scrum un método de gestión, con sus virtudes y defectos, al combinarlo con XP, un buen método de desarrollo de software, se crearía el tándem perfecto para el agilismo. Los datos demuestran que ni se combinan ni se diseña casi nada.
Digital.ai Software publica anualmente un informe sobre el estado del agilismo [1] a partir de una encuesta realizada a más de cuarenta mil profesionales.
Destaca, como método, Scrum por encima de todos usado por el 75% de las empresas. Sin embargo, solo el 8 % de ellas lo combina con XP. ¡Solo el 8%! Este dato lleva a uno a preguntarse: entonces ¿cómo se está haciendo el software? Los porcentajes de las técnicas ágiles empleadas son:
- Diseño incremental: 13%
- Pruebas de aceptación: 36%
- Refactorización: 43%
- Desarrollo dirigido por pruebas: 30%
- Integración continua: 55%
Solo tres de cada diez emplean TDD y apenas una de cada diez se ocupa del diseño. No me sorprende que muchos de mis colegas bajo la tiranía de Scrum, al cabo de unos pocas iteraciones tengan que empezar a convivir con ríos de lava, bolas de barro [2] y aguantar el mal olor procedente del código. Todo el mundo tiene clarísimo como funciona Scrum, lo cual no sorprende porque se aprende en dos tardes, pero a la hora de aplicar el agilismo al software y no a la gestión, el barco hace aguas por todas partes.
En mi opinión, el agilismo hoy está podrido hasta el tuétano y dudo de que tenga salvación.
¿Alguna solución?
Si el Proceso Unificado es maravilloso para las actividades relacionadas con el análisis de requisitos, análisis y diseño orientado a objetos y la definición de arquitecturas; y XP es extraordinario desde el punto de vista de la programación, las pruebas, la integración y el despliegue, ¿por qué no combinar lo mejor de los dos mundos?
Desde hace unos años, allí donde trabajo, puse en marcha un método que combina ambos. Aprendí de Larman [5] cómo hacerlo. Aunque la base es el Proceso Unificado (adaptado a nuestras necesidades, lo cual debe hacerse siempre) incorporamos TDD como forma de programar y la refactorización como forma de mejorar la calidad del código. No siempre damos a la primera con buenos diseños, pero el 80% suele estar bien porque antes de ponernos a programar pensamos cómo hacer las cosas. La refactorización también nos ayuda a adaptarnos a los inevitables cambios de los requisitos tras examinar el vínculo que hay entre ellos y el código mediante la trazabilidad. La trazabilidad no es una actividad separada, se crea automáticamente porque el proceso está dirigido por los casos de uso.
Todo el proceso está «aderezado» por los principios de la artesanía del software haciendo hincapié en la transmisión de conocimiento. En los equipos, los «maestros» transmiten su saber a los «oficiales» y estos a los «aprendices». Dado el escaso conocimiento sobre análisis y diseño orientado a objetos que no pocos profesionales tienen, hay que llevar a cabo la instrucción y el aprendizaje de manera continua. Por supuesto, la comunicación diaria cara a cara es esencial. Las reuniones cortas y cuando sean necesarias. Los jefes de proyectos son expertos en el dominio y hacen de enlace con el cliente. Además, nos aíslan de la inevitable burocracia que toda empresa tiene. La gestión de las actividades la realiza el arquitecto al que le dedica el 5% de su tiempo. No hace falta más.
Somos capaces de hacer software de calidad y, por tanto, somos muy productivos. No todo es un camino de rosas, hay días que muchos se mesan los cabellos (suerte tienen por tenerlos, yo estoy calvo) y resoplan. También hay ocasiones donde las jornadas se alargan, pero esto es una excepción y no la norma. El equipo formado por ingenieros informáticos, de telecomunicaciones, aeronáuticos e industriales, pero todos ingenieros de software, tienen la directriz de cumplir con el trabajo asignado sin usar tiempo extra porque considero que es contraproducente tanto para la persona como para la calidad del producto. Aprender a ser productivo es complicado, pero este debe ser el camino. La ingeniería del software y el Proceso Unificado son nuestra base y me importa un bledo si el mundo dice que no somos ágiles.
Referencias
[1] Anual State of Agile Report. Digital.ai Software, Inc. 2020. url: https://stateofagile.com.
[2] Brown y col. AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. John Wiley & Sons, 1998.
[3] Carmen Lasa Gómez, Alonso Álvarez Garcı́a y Rafael de las Heras del Dedo. Métodos ágiles. Scrum, Kanban, Lean. Anaya Multimedia, 2017.
[4] Larman y Basili. «Iterative and Incremental Development: A Brief History». IEEE Software (2003).
[5] Craig Larman. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. Prentice Hall, 2004.
[6] Manifiesto por el desarrollo ágil de software. 2001. url: https://agilemanifesto.org/iso/es/manifesto.html
[7] Manifiesto por la artesanı́a del software. 2009. url: https://manifesto.softwarecraftsmanship.org/#/es
[8] Matthew Pittman. «Object Solutions: Lessons Learned in Managing Object–Oriented Developement». IEEE Software (1993).
[9] Ken Schwaben. «SCRUM Developement Process». Object–Oriented Programming, Systems, Languages & Applications (1995).
[10] Ken Schwaben y Jeff Sutherland. Scrum Guide. 2020. url: https://scrumguides.org.
[11] Hirotaka Takeuchi e Ikujiro Nonaka. «The New New Product Developement Game». Harvard Business Review (1986).
