- Concepto de deuda técnica
- El costo implícito de retrabajo futuro que se genera al elegir una solución fácil pero limitada, en lugar de optar por un enfoque mejor que podría tomar más tiempo
- El costo de trabajo adicional generado al elegir la solución más rápida en vez de la más efectiva
- Tipos de deuda técnica distinguidos por el ingeniero de software Martin Fowler
- Deuda técnica prudente e intencional (Prudent & Deliberate)
- El equipo sabe que está asumiendo deuda, pero considera si “la recompensa de lanzar más rápido es mayor que el costo de pagar esa deuda”
- Deuda técnica imprudente e intencional (Reckless & Deliberate)
- Es el resultado de saber cuáles son las buenas prácticas de diseño y poder aplicarlas, pero decidir avanzar “rápido y sucio” porque no hay tiempo para escribir código limpio
- Deuda técnica prudente pero no intencional (Prudent & Inadvertent)
- Es el resultado de haber desarrollado buen software y con código limpio, pero darse cuenta solo con el tiempo de “cómo debió haber sido el diseño”
- Deuda técnica imprudente y no intencional (Reckless & Inadvertent)
- Es el resultado de no saber lo suficiente
- Cómo resolver la deuda técnica
- Gestionar una lista de deudas técnicas
- Hacer retrospectiva del proyecto para organizar y compartir una lista de deudas técnicas
- Cada vez que surja una deuda técnica, registrar el trabajo necesario para resolverla junto con el esfuerzo y el calendario estimados
- Discutir en el equipo si se resolverá, cuándo se resolverá y establecer un plan de solución
- Distinguir entre deuda técnica buena y mala
- Clasificar la deuda técnica de esta forma ayuda a definir la prioridad de los problemas más grandes
- Refactorización
- Mientras se trabaja, ordenar las partes necesarias y refactorizar poco a poco
- Al hacer una refactorización a gran escala, compartir la situación con el equipo e informar los riesgos y costos de la deuda técnica
- Escribir código de pruebas
- Cuanto más complejo sea el código y más grande sea la refactorización, más difícil será corregirlo de una sola vez sin errores
- Para evitar efectos secundarios, hay que escribir pruebas
- Establecer y cumplir estándares de calidad
- Definir estándares de calidad para evitar que los desarrolladores desplieguen código descuidado
- Evitar cambios repentinos de normativas o cronogramas
- Si cambian constantemente las reglas relacionadas con los desarrolladores o se modifican las fechas límite, será difícil evitar la deuda técnica
- Proporcionar cronogramas, metodologías y cargas de trabajo realistas para poder gestionar la deuda técnica
- ¿La deuda técnica siempre es algo malo?
- En el libro de Chris Riccomini y Dmitriy Ryaboy, 『¡Lectura obligatoria! Guía de onboarding para desarrolladores: el nacimiento de un desarrollador profesional que comprende el software sostenible y una cultura de colaboración fluida』, se afirma: “Si es una deuda preparada para que el equipo pueda resolverla incluso más adelante, puede considerarse una ‘buena deuda’”
- Pero la deuda técnica puede tener un impacto negativo en el negocio, por lo que debe resolverse
- Puede manifestarse en forma de errores y degradar la experiencia de usuario
- Si la deuda técnica empeora, a los desarrolladores les resulta más difícil trabajar dentro del codebase existente
- Al tener que dividir el tiempo entre desarrollar nuevas funciones y corregir las existentes, el ciclo de vida del desarrollo de software se ralentiza y se retrasa la salida al mercado
Aún no hay comentarios.