La deuda técnica es una metáfora ampliamente conocida que nos ayuda a pensar en cómo los problemas técnicos perjudican nuestra capacidad de ofrecer valor comercial a través de los sistemas de software.pero conocer el concepto es diferente de gestionar realmente la deuda técnica.lamentablemente, muchos equipos de software saben que tienen una deuda técnica, pero no saben qué hacer al respecto.
Si no se controla, el «interés» de la deuda de un equipo puede superar su capacidad de pago. Las cuestiones técnicas se interponen en el camino de la entrega de valor; el desarrollo se ralentiza mientras que los costos aumentan. Para empeorar las cosas, los equipos tienen tendencia a endeudarse mucho más de lo que se dan cuenta debido a lo difícil que es cuantificar los costos de la deuda técnica.

El aspecto más crítico de la gestión de la deuda técnica es abordar regularmente los problemas como parte de su flujo de trabajo normal de desarrollo. Como una factura mensual de una tarjeta de crédito o el pago de una hipoteca, no se puede sobrevivir con sólo pagar los intereses. Tienes que reducir la deuda pagando el «principal».
Capacidad de dedicación
Nunca hay tiempo para trabajar en la deuda técnica a menos que usted haga el tiempo.Siempre hay otro trabajo por hacer.A pesar de las promesas en contrario, nunca habrá tiempo dedicado para que su equipo «compense» la deuda técnica que usted genera – siempre surgirán nuevas preocupaciones comerciales y su deseado «mañana» nunca llegará.
¡Siempre hay otro trabajo por hacer!
Esto significa que necesitas establecer una cadencia para que el equipo dedique tiempo a tratar los temas. Haz que esto sea parte del flujo de trabajo normal del equipo, no algo que guardes hasta una fase de «endurecimiento» en el camino. Postergar el trabajo sólo lo empeora.
Esos porcentajes son críticos. Ten en cuenta que el 20% es el mínimo . Al igual que en la carrera de la Reina Roja, tienes que pagar muchas deudas sólo para permanecer en el mismo lugar porque el desarrollo de nuevas características siempre incurrirá en nuevas deudas.
Esto significa dedicar suficiente capacidad para abordar la deuda técnica. A continuación se presentan algunos ejemplos de cómo podría hacerlo. Elija una estrategia que funcione bien en el contexto de su equipo.
1 de cada 4 artículos de trabajo
La mayoría de los equipos rastrean sus elementos de trabajo de alguna manera, como historias de usuarios o tareas de kanban. En esta estrategia, rastreas tus elementos de deuda técnica junto con tus otros elementos de trabajo y te aseguras de que de cada 4 cosas que haces, una de ellas es deuda técnica. Esta tasa te pondrá justo en medio de la orientación del 20-30%.
Para que esto funcione de manera efectiva, necesitas tener un tamaño similar de tus artículos de trabajo. Si tu historia de deuda técnica sólo toma una hora, pero tus otras 3 historias toman una semana, entonces no estás alcanzando esa marca del 25%. Idealmente, la mayoría de los artículos de trabajo deben ser pequeños (menos de un día de trabajo) para mantener un flujo consistente. Los tamaños más grandes también pueden funcionar, pero tienes que compensarlo – tal vez usando algo como puntos de historia en lugar de artículos de trabajo para asegurarte de que estás obteniendo el porcentaje deseado.
1 día a la semana
En esta estrategia, el equipo reserva un día a la semana sólo para la deuda técnica. Suponiendo una semana de trabajo de 5 días, esto te pone en ese mínimo del 20%. Algunos equipos encuentran esto un gran estímulo moral. Esperan con interés su oportunidad cada semana para hacer frente a los problemas que les han perseguido.
Si utiliza esta estrategia, tenga cuidado de que otras preocupaciones (como las reuniones) no erosionen el tiempo para abordar la deuda técnica. Los días festivos de la empresa, las vacaciones y otros conflictos de programación pueden alterar su ritmo. También tenga en cuenta que dejar el trabajo sin terminar al cambiar entre el trabajo de características y el trabajo de la deuda técnica puede dificultar la integración de los cambios.
Papel rotativo
Otra estrategia consiste en tener un papel rotativo en el que los promotores asignados trabajen exclusivamente en el tratamiento de la deuda técnica. El número de promotores asignados en un momento dado dependerá del tamaño de su equipo. Para un equipo de 4 ó 5 ingenieros, siempre podría tener 1 asignado y alcanzar el objetivo del 20-25% de la capacidad. Los equipos más grandes pueden necesitar que se les asigne más gente; los más pequeños sólo pueden asignar el papel durante unos pocos días a la semana.
Para que esto funcione bien, los desarrolladores del rol asignado deben seguir las mismas prácticas para el trabajo técnico de deuda que harían para el trabajo de producto.¿Realiza revisiones de código? El trabajo técnico de deuda también debe ser revisado.¿Realiza regularmente pares en el código de producción? Es posible que necesite averiguar cómo aplicar esa práctica para el trabajo técnico de deuda.Evite hacer que su trabajo técnico de deuda sea diferente de su trabajo normal para no crear más problemas de los que resuelve.
También es importante que esta tarea cambie regularmente. Ninguna persona debe ser la única responsable de limpiar los desórdenes del equipo, eso es desmoralizador. Los desarrolladores deben ser parte de ambos lados de las ramificaciones de codificación de las decisiones técnicas sobre la deuda.
La refactorización como parte de la obra de arte
Además de reservar capacidad para abordar la deuda técnica, los equipos también deben evitar incurrir en nuevas deudas siempre que puedan.la deuda técnica crea una complejidad compuesta, lo que hace más difícil abordar una sola cuestión.por lo que será necesario mantener limpia la base de código sobre la marcha.la refactorización debe ser una parte natural del proceso de codificación (por ejemplo, como parte del ciclo de desarrollo impulsado por pruebas).
Cuando se trabaja en una nueva funcionalidad, no es raro encontrar que los cambios en la base de código facilitarían la adición de la nueva característica. Si los cambios en el código son relativamente menores, hacerlos en el acto suele ser la mejor jugada. Cambiar ese código problemático facilita la adición de la característica, por lo que se aborda la deuda técnica y se hace el trabajo rápidamente, a menudo más rápidamente que si se hubiera intentado contorsionar en el código existente.
Pero si los cambios requeridos son más extensos, entonces tendrá que discutir la contrapartida con su equipo (y tal vez también con las partes interesadas) para determinar si debe abordar la deuda técnica antes de terminar el trabajo del reportaje. Recuerde que será más complicado (y por lo tanto más costoso) pagar esa deuda si la aplaza. Por lo tanto, si puede afrontar el costo del retraso en el reportaje, debe abordar primero la deuda técnica y gastar menos en general.
Cuando se asuman estas deudas como parte del trabajo de la característica, recomiendo contar el tiempo que toma contra el 70-80% de capacidad que se dedica a tu trabajo normal, no el 20-30% que has dedicado a abordar la deuda técnica. (Sin mencionar que el empuje para el desarrollo de la nueva característica es una de las causas más comunes de incurrir en nuevas deudas).
Los beneficios de la gestión de la deuda técnica
En los últimos diez años he podido trabajar u observar muchos proyectos de software. Invariablemente, los que no dedicaban tiempo regular a pagar la deuda técnica acababan por ralentizarse y eran un dolor de cabeza. Las promesas de dedicar tiempo después para pagar la deuda técnica se rompían o eran demasiado infrecuentes como para importar. Se incumplían los plazos. Los nuevos proyectos se hilaban para sustituir a los antiguos… sólo para acabar con el mismo problema de deuda abrumadora.
Por el contrario, también he trabajado en proyectos en los que abordamos la deuda técnica de forma continuada.Trabajé durante unos años en un equipo que utilizó la estrategia de trabajar en 1 tarjeta de deuda técnica de cada 4 en nuestra junta de kanban.En ese equipo ofrecimos más valor de forma más consistente que cualquier otro equipo en el que había estado anteriormente.Se nos permitió abordar cualquier pieza de la deuda técnica que nos estaba causando dolor.Y como nuestras tarjetas rara vez tardaban más de un día en funcionar, trabajábamos en la deuda técnica varias veces al día.
Ahora bien, también había otras razones por las que el equipo tuvo éxito. Empleamos metodologías Lean con prácticas como pequeños atrasos, TDD, código limpio, programación mob, CI y despliegues frecuentes de producción. Pero cuando se trataba de sentarse realmente a escribir código, muy rara vez nos retrasábamos por nuestra deuda técnica. El desarrollo de nuevas características se mantuvo rápido, aunque estuvimos en la misma base de código durante años.
¿Significaba eso que nunca tuvimos una deuda técnica? Para nada. Teníamos bastante de deuda técnica, al igual que la mayoría de los equipos. Pero la estábamos manejando.
Resumen
A veces la gente se pregunta por qué siempre parece que tenemos una deuda técnica. «¿Por qué no podemos pagar todo y estar libres de deudas?» La respuesta es una terrible verdad:
Nunca puedes estar libre de la deuda técnica.
En términos de la metáfora financiera, se podría decir que hemos «invertido» en software. Esa inversión causa naturalmente deuda de varias maneras, incluyendo cambios en el mundo que te rodea que pueden incluso hundirte repentinamente en una profunda deuda. Incluso los desarrolladores experimentados con prácticas impecables generarán deuda técnica.
Aunque los detalles de cualquier deuda técnica son (por supuesto) de naturaleza técnica, la acumulación de la misma es realmente un problema de personas. Usar tecnologías apropiadas ayuda. Escribir un código limpio ayuda aún más. Pero no se puede eludir el hecho de que lleva tiempo abordar las cuestiones técnicas.
No puedes evitarlo. Sólo puedes manejarlo. La única forma que he encontrado para manejar eficazmente la deuda técnica es dedicando tiempo regular.
Categorías: prácticasEtiquetas: código limpio, magro