El equipo acaba la primera parte de sprint planning desgranando os PBIs en tareas, estimándolas y cada miembro del equipo empieza a trabajar en un ítem distinto. Esto lleva a problemas de integración y silos de implementaciones en los cuales no tenemos ni de lo que está sucediendo. Las tareas quedan a mitad de desarrollo al final del sprint y no da tiempo a integrar (ofreciendo algo de calidad). Sin embargo, el product owner aprieta los tiempos y el esfuerzo estimado para el sprint review. “Cuanto más, mejor”. Los desarrolladores (si se lo permiten) añaden la “deuda técnica” al backlog para seguramente no volver a verla.

Ward Cunningham presentó el concepto de “Technical Debt” en 1992. Es una metáfora para explicar cómo la ausencia de calidad en nuestro código terminará por generar sobrecostos en el matenimiento de la aplicación en dinero como esfuerzo del equipo (usualmente este último, lo que termina causando más deuda).

En mi opinión, el costo que nos genera la deuda técnica aumenta de manera geométrica respecto al tiempo. Así como no tenemos una manera de calcular la calidad del código, tampoco tenemos una para averiguar las consecuencias de la mala calidad. El problema radica en la definición de calidad. La ignorancia respecto a la necesidad de negocio que tratamos cubrir nos lleva a adquirir la deuda. Una manera de tener una idea acerca de la deuda técnica es clasificarla en dos factores, la prudencia y la conciencia de las decisiones de diseño que tomamos.

cuadrantes

La deuda prudente y deliberada es a la que nos vemos obligados a incurrir por factores externos siendo conscientes de ello. La prudente e inadvertida es la que tenemos que explicar a los stakeholders porque aparece en todo proyecto mientras vamos conociendo más el problema que tratamos de resolver e incluso analizamos si vale la pena pagar este tipo de deuda. La imprudente y deliberada es la peor de todas pues damos por sentado que estamos desarrollando algo que acabará con mala calidad y puede ser producida por una mala gestión, despropósitos técnicos y falta de compromiso. La imprudente e inadvertida se debe a una mala formación profesional que nos hace tomar una serie de decisiones equivocadas.

Es importante que los stakeholdders comprendan que siempre habrá deuda técnica en un proyecto. Por otro lado, los desarrolladores cuentan con principios básicos de programación como SOLID, YAGNI, KISS y DRY.

tiempo

También, tenemos algunos indicadores que debemos procurar detectar pronto:

  • Cuando es complejo adaptar el código es porque este es rígido resultando difícil de mantener y extender.

  • El código empieza a fallar en lugares donde no hemos tocado nada al cambiar un pequeño detalle del mantenimiento en el que estemos trabajando. Luego, solemos tratar con miedo el código, procuramos modificarlo lo menos posible generando más código repetitivo y hard-codeando haciéndolo incluso más frágil.

  • Aunque la aplicación tiene componentes útiles en otras, hay un gran riesgo de desacoplarlas del resto del código y el esfuerzo es tanto que preferimos estas soluciones inamovibles volviendo a escribir las implementaciones.

  • El proceso de desarrollo se vuelve lento e ineficiente, el código es difícil de utilizar y hay una ausencia de diseño. Ambos son viscosos porque tenemos que recurrir a trucos, genialidades, chiches para programar como el “diseño” fue pensando.

  • Los componentes son innecesariamente complejos con centenares de líneas de código, difíciles de identificar y entender su utilidad o manera de usar, con funciones y clases no usadas, y, en absoluto, código inútil.

  • Recurrimos al truco más recurrido: copiar y pegar. Las repeticiones de código nos llevan a un diseño pobre donde no hemos podido identificar los contextos comunes.

  • El código se vuelve opaco, complicado de leer, haciendo que queramos leerlos menos inclusive.

Un equipo maduro no empieza algo nuevo hasta no haber acabado el actual —manteniendo una o dos tareas simultáneamente. Mantener un ritmo de desarrollo ayuda a tratar la deuda técnica. También, podemos recurrir a algunas prácticas de XP como son TDD, y pair programming. Reescribir parte de la aplicación, o peor, toda la aplicación, no es una solución y es poco profesional así como permitir que la deuda técnica se acumule. Desde el punto de vista del desarrollador, estimar considerando el impacto, componentes invlucrados, refactoring, unit tests, entre otros, es lo deseable; no se necesita consultarlo con nadie de la misma manera que un médico no consulta con nosotros si debe o prescribir un medicamento. Simplemente lo hace y queda a responsabilidad del paciente tomarlo. Por otro lado, están los gestores que “tienen” que entregar más. Pero esto se maneja más con habilidades comunicativas y cuya responsabilidad escapa del equipo como un todo.

Anuncios