En el último post, introduje el concepto de Deuda de Calidad como una forma alternativa de pensar en la Deuda Técnica desde la perspectiva de la disciplina de Aseguramiento de Calidad de Software. A través de la aplicación de tres métricas de calidad simples pero poderosas, propuse el uso de cuatro objetos tangibles y procesables como entregables, en relación con los procesos desde donde se recopilan esas métricas: el registro de defectos, los nuevos requisitos o nuevos elementos de backlog, el software de prueba (testware) aumentado y el informe de brecha de esfuerzo de calidad.
Como la creación de software es hoy todavía (pero tal vez no por mucho tiempo, ver Chat GPT y Copilot de Github) un proceso dependiente del ser humano, las deudas técnicas y de calidad pueden no poder evitarse por completo. Sinembargo, hay cosas que los equipos pueden hacer para ayudar a reducir la adquisición de dicha deuda.
En su post de 2020 Luca Rossi reflexionó sobre la cuestión de reducir la deuda técnica desde la perspectiva de un desarrollador de software. En esta publicación, voy a abordar el tema desde la perspectiva de todos los roles que interactúan con un equipo.
Haz tu balance de cuentas
Al igual que con cualquier tipo de deuda, esta primero debe ser reconocida y contabilizada; para hacerlo, quizás el primer y más crucial paso sea definir e implementar formalmente dentro de su equipo los cuatro elementos procesables descritos en la última publicación: El registro de defectos, los nuevos requisitos o elementos de backlog, el testware y el informe de brecha del esfuerzo de calidad. Como estos conceptos están muy bien definidos en la disciplina de Ingeniería de Software para cualquier tipo de SDLC en el que se encuentre, no debería tener ningún problema.
El siguiente paso es usar esos elementos para estimar su deuda real, ya sea en esfuerzo de equipo (horas hombre) o costo (recursos financieros). Por ejemplo, puede calcular el “delta” (o diferencia) entre su trabajo pendiente original y los últimos elementos agregados más el número de defectos críticos (del registro de defectos) que necesitan reparación inmediata y calcular cuánto tiempo y personal necesitará para terminarlos. También puede contabilizar la ejecución de cualquier prueba adicional, su conversión en scripts automatizados (testware aumentado) e incluso el tiempo necesario para ejecutar (total o parcialmente) las pruebas omitidas en el reporte la brecha de esfuerzo de calidad.
Haz tu plan de pago
Una vez estimado, puede incorporar su deuda de calidad en su plan de proyecto actual como una forma de “refinanciarlo” y, por lo tanto, volver a estimar su proyecto. También podría decidir “aplazar su pago” y, en consecuencia, pagar un interés compuesto a través del tiempo. Este método es el más cuantitativo, pero hay otras formas de reducir la incursión en la Deuda de Calidad, a continuación, mencionaré tres de las más comunes:
- Involucre a todo su equipo: Cambiar a un enfoque holístico y centrado en la calidad es una forma efectiva de involucrar a todos los roles (Devs, QA, Scrum Masters, Product Owners, Business Analysts, DevOps, DataOps, etc.) para adoptar la calidad de software como parte intrínseca de la cultura del proyecto. Por ejemplo, Shift Left Testing (prueba temprana y frecuente) refuerza la noción de que todo el equipo es responsable de la calidad de cualquier resultado del proyecto (no solo el código, sino también la documentación, experiencia del usuario, rendimiento, etc.) y les hace conscientes de sus implicaciones desde el inicio, el diseño de la arquitectura hasta su despliegue en producción (independientemente del que el ciclo de desarrollo de software sea en cascada, ágil o híbrido).
- Potencie sus QA: Dé a sus ingenieros de calidad la confianza para expresar sus opiniones, cuestionar todo y comunicarse horizontalmente. Respete su estimación de esfuerzo para las pruebas (tanto como respeta otras etapas como el diseño de arquitectura, el desarrollo y el diseño de la experiencia de usuario) y permítales elaborar sus trucos mágicos (como técnicas de prueba basadas en el riesgo, la creación de artefactos y métricas relacionados con el software de prueba, realizar sesiones de pruebas exploratorias, así como automatizar la gestión de datos de prueba o aumentar la cobertura de automatización). Cuando este esfuerzo se aplica correctamente, valdrá la pena la incomodidad y la naturaleza aparentemente “improductiva” de tales tareas.
- Formalice y evangelice su enfoque de calidad: Si no tiene un proceso de calidad bien definido y que su equipo asuma intrínsecamente, puede ser difícil o incluso absurdo pedir a otros que lo adopten. Una vez que un equipo está montando una “ola” holística centrada en la calidad, abogarán por ella, y otros verán lo “genial” (como en útil, transparente, beneficioso e increíble) que es y la seguirán. Algunos procesos de calidad que pueden servir como temas clave de comunicación para atraer la conversación sobre el tema son el presupuesto de defectos en el sprint, priorizar el incremento de la cobertura de automatización de pruebas y reuniones periódicas para volver a priorizar los problemas.
Pensar en la deuda técnica del software desde la perspectiva de la calidad ofrece a los equipos una forma más tangible de entenderla, medirla y comprender sus implicaciones sobre varios aspectos del proyecto y ayuda a todos los involucrados (no solo a los desarrolladores o QAs) a actuar como un equipo sobre un terreno común y encontrar formas creativas de superarla.
En la siguiente publicación profundizaré un poco más en el registro de defectos, introduciendo algunas métricas relacionadas con defectos y mostrando algunas formas de administrarlo e incluso tratarlo de manera proactiva.
