Hace unos años, estaba trabajando con un equipo, de consultor, cuando un compañero me hizo la siguiente reflexión: “Para el cliente, lo importante es la fecha y el alcance; para el comercial, lo importante es el coste (su margen) y, para nosotros, la calidad”. No es la primera vez que veo a developers preocuparse por la calidad de su producto y esto tiene sentido. Seamos sinceros, un buen profesional quiere hacer bien las cosas, eso es innegable, sin embargo, ¿es ese el verdadero espíritu de la agilidad?
Agile no funciona
Aunque parezca extraño, hay una corriente en el mundo de los developers en contra de la agilidad. El problema no es la idea que propone sino su verdadera implantación y realidad. En muchas empresas, lo máximo que se consigue es implantar un sistema de “cambios gratis y a última hora” que impacta muy negativamente en los equipos.
Recordemos que Agile busca encontrar mejores maneras de desarrollar software. Está claro que, en 2021, Agile ha trascendido la tecnología para abarcar todos los aspectos de una empresa, sin embargo, nace para buscar mejores maneras de desarrollar software. Solo con esta idea, podemos entender que Scrum, Kanban u otros métodos y prácticas relacionadas con la agilidad no están habilitando mejores maneras de hacer software.
De todas ellas, la única que se libra es Extreme Programming (XP) que sí se centra en esa calidad y la importancia de la misma en los equipos. Por desgracia, XP está aún poco extendido en el mundo del software, especialmente en los países latinos.
El estado de la calidad en las empresas
Otra de las realidades reconocidas en las empresas es la falta de calidad en el software que construímos. En mi carrera profesional, he visto pocos lugares que apreciaran y mimaran la calidad de su software. Posiblemente, haya varios motivos:
- Falta de conocimiento, por parte de los equipos, sobre técnicas y prácticas que fomenten la calidad, como Clean Code, TDD o Pair Programming.
- Ausencia de inversión por enfocarse en la reducción de costes, asumiendo que la calidad es secundaria.
- Aumento de las funcionalidades de tu producto, dejando test y demás prácticas para el “final”.
- Poca atención a los resultados finales, el éxito de muchos equipos no se basa en la satisfacción de los usuarios.
Si lo pensamos fríamente, estos motivos están estrechamente relacionados con el concepto de “proyecto software”, donde prima la entrega en fecha. Por eso, en Agile, hablar de proyectos quizás no sea lo más adecuado, porque en ellos, ¡la calidad no importa! Es más, hemos visto casos de empresas que prefieren bajar la calidad para ganar un contrato posterior de mantenimiento y asegurarse mayor recurrencia con el cliente.
Agile y sus prioridades
Si estudiamos los principios Agile, estos definen muy claramente la prioridad:
“Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software”. Primer Principio Agile
Es decir, nuestra prioridad es entregarle a un cliente software con valor, de manera contínua y temprana, que le permita satisfacerle. Es decir, la clave del mejor software es que sea útil para alguien. Hacer un software de calidad pero que no es útil a nadie es desperdicio.
Por ello, calidad no debe ser nunca la prioridad de un desarrollador, ya que no garantiza el éxito de nuestro desarrollo. Ahora bien, ¿cómo conseguimos aportar valor de manera contínua?
Recordemos que, en el concepto de proyecto, buscamos el “terminar”, por eso tenemos métricas como “porcentaje de avance”, que nos indican cuánto queda para finalizar. Bajo esa mentalidad, la calidad pasa a un segundo plano. Sin embargo, con la mentalidad de producto, aparece el concepto de entrega contínua de valor. Aquí, la calidad adquiere un papel relevante porque sin calidad es complicado que el valor perdure ¿Un cliente percibe valor algo que recibe temprano pero falla repetidamente? Cuidado, este principio no habla de entregar “rápido y mal”, sino de ser capaz de entregar de manera constante.
Agilidad y Calidad
Cuando se trata de ser ágiles, no es solo para responder rápido la primera vez, sino de ser capaz de mantenerlo en el tiempo. De ahí, el principio siguiente:
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely. – Principio número 8 Agile
Es decir, para poder desarrollar buen software tenemos que ser constantes. Bajo este paradigma, la calidad tiene mucho sentido no solo por los costes de mantenimiento sino por la calidad del servicio que prestamos. Un producto que llega temprano y mal es complicado que mantenga a sus customers, las personas no suelen perdonar. Además, existe un problema secundario que debemos tener en cuenta. Para poder mantener a nuestros usuarios “enganchados”, debemos ser capaces de ofrecer nuevas funcionalidades que aportar a sus nuevas necesidades. Cuando un producto está construído con baja calidad, nuestra capacidad de entrega disminuye lo que reduce nuestra agilidad:
Continuous attention to technical excellence
and good design enhances agility. – Principio número 9 Agile
Es decir, prestar atención a la calidad mejora la agilidad. Cuidado, mejorar no es lo único y no es la máxima prioridad de un equipo que desarrolla agilmente.
El ego del programador
He visto, en los últimos años, programadores que anteponían sus necesidades y su ego a las necesidades y prioridades de un cliente. Tenemos que entender que, cuando hacemos buen software, tenemos que prestar mucha atención a nuestros clientes y a sus necesidades. Se trata de dar el mejor servicio posible a través del producto que construímos. Por eso, me choca cuando un programador me dice “Agile significa hacer calidad”. Esto es incierto, Agile es entregar software con valor de manera contínua y, para eso, la calidad ayuda pero no es el único foco.
Dicho esto, tampoco podemos plegarnos a lo que ocurre en muchas empresas: equipos corriendo para entregar software en fecha y, así, mejorar los márgenes de su empresa. ¡Esto tampoco es calidad! Un equipo de desarrollo necesita un propósito de negocio, un problema a resolver y métricas que le informen del estado por el que avanzan.
Y tú, ¿cúal crees que es la prioridad en tu equipo?
