Deuda Técnica.
El concepto de deuda técnica en Scrum es complejo de explicar, puesto que es algo que no se ve, pero se siente, se sabe que está ahí, acumulándose y, desde las sombras, convirtiéndose en un problema que puede acarrear sobreestimación, sobrecostes y muchos problemas en el equipo de desarrollo.
Un poco de historia.
El término surge de una analogía utilizada por Ward Cunningham, en 1992, en la que realiza una comparación entre un desarrollo de software que presenta carencias a nivel técnico por entregarlo de manera temprana, con la petición de un crédito financiero.
Así como el crédito permite obtener liquidez a corto plazo, a costa de generar unos intereses a liquidar en un período de tiempo prolongado, las carencias en el desarrollo de software nos dan un entregable a corto plazo, pero tarde o temprano requerirán gastar el tiempo inicialmente ahorrado, sumando un esfuerzo extra (los intereses).
En resumen, las carencias en el desarrollo de software generan una deuda técnica igual a los intereses que genera un crédito bancario.
Principales causas de la deuda técnica en Scrum.
La principal causa de la deuda técnica son las presiones en fecha y planes. En muchos casos, el equipo de desarrollo toma “atajos” para poder llegar en plazos dentro del Sprint.
Las siguientes son otras causas comunes de deuda técnica:
- Falta de colaboración, no compartir conocimientos hace que el software desarrollado no sea de calidad.
- Falta de documentación, por no disponer de tiempo se puede perder una forma común de desarrollar.
- Falta de comprensión, si la organización no conoce el concepto de deuda técnica, no podrá conocer las consecuencias de desarrollar un software de mala calidad.
Soluciones ágiles.
Scrum se basa en tres pilares: Transparencia, inspección y adaptabilidad. Estos pilares están presentes en todos los Sprints, y por este motivo tendremos el control sobre la deuda técnica y sus consecuencias si seguimos algunas de estas pautas:
- Aprovechar al máximo el Daily meeting, cada día el equipo de desarrollo puede detectar de manera rápida los posibles errores y decidir de manera ágil para evitar cualquier carencia en el software.
- Incluir dentro de las estimaciones tareas relevantes como testeo, documentación y refactorización.
- En caso de sospechas de deuda técnica, utilizar futuros Sprints para refactorizar y no seguir heredando problemas en el desarrollo.
- Involucrar a la organización, la mejor manera de hacer entender a directivos es con números.
- Estimar las horas extras que se harían en caso de duda técnica, multiplicado por su precio en horas funciona mucho mejor que simplemente queriendo convencer con palabras a alguien que, de normal, solo entiende de beneficios o pérdidas económicas.
- Involucrar al Scrum Master, es la persona que se encargará de evitar la deuda técnica, y defenderá al equipo de eventos o fechas que puedan dañar la calidad de los entregables.
- Cuidar el definition of done, cualquier factor que elimine la deuda técnica debe estar incluído, y nunca olvidar que el DOD debe estar siempre actualizado.
