¿Qué entendemos por calidad en un proyecto software? ¿Es posible que el exceso de calidad esté perjudicando al proyecto? ¿Somos demasiado extremistas con la calidad? Este es un tema recurrente que, de tanto en tanto, sale a discusión entre agilistas y no agilistas, a veces con críticas poco constructivas al movimiento de la artesanía del software.
Lo cierto es que en toda mi carrera profesional, jamás vi un proyecto que sufriera retrasos o pérdidas económicas por haber invertido en lo que yo considero calidad. Por ejemplo:
Todos estos elementos y muchos más, son para mí componentes de la calidad. Son característicos de nuestra forma de trabajar y forman parte del proyecto desde su inicio. Como decía William Edward Deming, la calidad no puede añadirse a posteriori, sino que debe formar parte del proceso desde el inicio. No solo es que la calidad no va a penalizarnos, sino que será la que aumente nuestra productividad. Nos permite conseguir resultados homogéneos, predecibles, acorde a estándares de la industria y a los nuestros propios. La calidad es parte de lo que nos define como profesionales y nos permite sentirnos orgullosos del trabajo bien hecho, pero, además, es la única forma que hemos encontrado de que el software que construimos sea sostenible en el tiempo.
Seguro que muchas personas se sienten cómodas con esta visión de la calidad, entonces ¿por qué surge la discusión en torno a la calidad? En mi experiencia, es porque llamamos calidad a cosas que no lo son, como, por ejemplo, el dogmatismo y la falta de conocimiento técnico y de pragmatismo. A continuación, se nombrarán algunos ejemplos concretos de decisiones que sí impiden el desarrollo de un proyecto y que supuestamente son en nombre de la calidad:
Desarrollar un MVP de un producto que va a ser pequeño y con pocos usuarios concurrentes, con siete microservicios, siete repositorios de código separados, kubernetes y otras herramientas, que ni son necesarias para el MVP, ni probablemente lo sean nunca para este producto.
Dedicar tres semanas a construir el pipeline de integración continua de los sueños.
Rehacer la “arquitectura” de la solución tres veces antes de la primera salida a producción.
Querer meter con calzador la última tecnología de moda, aunque no la sepamos utilizar.
Querer hacer todo con TDD, cuando nadie del equipo tiene soltura con esta técnica.
Provocar cuellos de botella con la revisión de código asíncrono (Pull Request/Merge Request), en vez de sentarnos juntos a trabajar y de confiar en los integrantes del equipo, para que cualquiera pueda desbloquear atasques y sumar valor a negocio cuando se necesite. No estoy diciendo que los PR sean negativos, hay muchos contextos en los que son muy útiles, son una herramienta de calidad muy positiva cuando los equipos trabajan en asíncrono, en diferentes zonas horarias, cuando el proyecto es open source, cuando no se practica pair programming… a lo que me refiero es al dogma que he visto en proyectos donde se frenaba el avance del proyecto, la puesta en producción de trabajo realizado de manera recurrente en supuesta defensa de la calidad.
Intentar copiar las prácticas de desarrollo del equipo de Netflix, de Facebook o Github, aun cuando el contexto de nuestro equipo seguramente no tiene nada que ver con estos. Los procesos de calidad son diferentes para cada equipo, porque el contexto es fundamental para entender la calidad.
Over-engineering:
Podríamos enumerar muchos más ejemplos en donde se confunden prácticas fuera de contexto con procesos de calidad.
A menudo, lo que hay detrás de estas decisiones son buenas intenciones, ganas de aportar y de hacer un buen trabajo. Se hacen en nombre de la calidad, pero luego se convierten en decisiones que dañan al proyecto, por varios factores. Uno es la falta de alineamiento en la visión de negocio; si el equipo técnico no entiende bien el plan de negocio, las fases, dónde está el valor, qué es lo importante, entonces no podrá tomar decisiones técnicas adecuadas. Por desgracia, es muy habitual que el equipo técnico esté lejos de los stakeholders, con varias personas en medio que se comportan como actores del teléfono escacharrado.
Otro factor es la falta de conocimiento técnico en los equipos, por ejemplo, cuando todo el equipo está compuesto por juniors que no tienen el apoyo/guía de otra persona técnica con experiencia creando soluciones pragmáticas adaptadas al negocio. Un clásico es cuando quieren escribir test automáticos, pero nunca lo han hecho antes y en lugar de contratar ayuda externa especializada, deciden aprender a golpes, gastando tiempo y dinero del proyecto.
Los egos nos la juegan con frecuencia, todo el mundo quiere demostrar que es profesional y que tiene mucho que aportar a los proyectos, pero a veces el ímpetu nos lleva a introducir problemas, en vez de ayudar. Los egos nos engañan cuando llamamos calidad al dogmatismo o al heroísmo y también cuando criticamos de forma destructiva metiendo en el mismo saco a todo el mundo.
El movimiento de la artesanía de software (software craftsmanship), tal como yo lo entiendo, reivindica que hagamos el software con calidad, con profesionalidad y, por supuesto, con pragmatismo, no con dogmatismo. El dogmatismo se puede detectar cuando la persona que propone una práctica o proceso no sabe explicar de forma clara la ventaja de dicha práctica o proceso, sino que se limita a decir que es una buena práctica de calidad, porque lo dice Bob Martin o cualquier otro autor. Sabernos explicar con claridad es fundamental para reducir esa brecha que hay entre negocio y developers, objetivo que perseguía el manifiesto ágil y que nos vuelve a recordar el manifiesto de la artesanía del software.
Aprovecho para dar las gracias a Javier Martín de Agar, Juan Banda y Ana Carmona, por recordarme que quería escribir sobre este tema desde hace tiempo. Probablemente, este tema sea también motivo para hacer un episodio de podcast.
¿Quieres más? te invitamos a suscribirte a nuestro boletín para avisarte cada vez que recopilemos contenido de calidad que compartir.
Si disfrutas leyendo nuestro blog, ¿imaginas lo divertido que sería trabajar con nosotros? ¿te gustaría?
Pero espera 🖐 que tenemos un conflicto interno. A nosotros las newsletter nos parecen 💩👎👹 Por eso hemos creado la LEAN LISTA, la primera lista zen, disfrutona y que suena a rock y reggaeton del sector de la programación. Todos hemos recibido newsletters por encima de nuestras posibilidades 😅 por eso este es el compromiso de la Lean Lista
