Es importante entender la definición de deuda técnica y su impacto porque es un concepto que mucha gente menciona, pero muy pocas personas dominan.
Como coach, una vez que lo entiendas, puedes ayudar a cualquier equipo técnico. Y te diré: no hay muchos coaches capaces de ayudar a sus equipos en el frente técnico, así que esto te da una ventaja única.
La definición de deuda técnica
La deuda técnica es un concepto creado para ayudar a los empresarios y desarrolladores a comprender juntos el impacto de sus elecciones en cuanto a implementación y plazos.
Pensemos en la deuda desde el concepto económico: La deuda no es ni mala ni buena. Es algo que pagas una vez que lo tienes y quieres seguir siendo un ciudadano de buena reputación. A veces lo pagas rápido, a veces lento.
- A veces es una parte del código que se llena de basura, como una clase o algunos archivos con código muerto o código espagueti.
- A veces es una pieza de diseño completa que se vuelve horrible (como en la base de datos, en un motor de reglas, en una pieza arquitectónica del software).
Las grandes decisiones sobre cómo gestionar tu deuda económica tienen que ver con tu tasa de interés. Asegúrese de concentrarse en pagar lo que tiene una tasa de interés alta para que no siga acumulando más deudas y vaya a la quiebra.
Pague lo que tiene una tasa de interés alta para que no siga acumulando más deuda.
¿Qué es eso en el software?
Agregar una nueva característica de fragmento de código debería tomar tiempo y calidad estándar para su equipo. Si algo que normalmente tardaría 5 días en desarrollarse ahora toma 7, tenga cuidado. Esa área del código probablemente está acumulando deuda.
Tienes una parte del código que todos los que alguien toca causan más errores. O que cada vez que quieres agregar una nueva característica notas que el equipo se vuelve cada vez más lento. Esa deuda está aumentando. Esa es la deuda que desea comenzar a pagar lo antes posible. Como en la imagen de abajo.
No toda basura “aparente” es deuda técnica. Y no vale la pena pagar la deuda a la misma velocidad.
Eso nos lleva a la siguiente sección.
Si no es un problema, no es deuda técnica
La tecnología más antigua puede estar en buena forma. La nueva tecnología que entra en juego tampoco se adopta necesariamente para pagar la deuda técnica.
Porque algo se hace en COBOL no significa que sea una deuda técnica. Debido a que su software se ejecuta en mainframes, NO tiene una deuda técnica en sus manos. La evolución normal del software no es una deuda técnica en principio.
La deuda técnica se trata de dónde en el código se nos impide ir más rápido, donde cada vez que tocamos el código hay inseguridad e incapacidad para ir más allá.
¿Cómo sabes entonces si esto es sin duda un problema, una deuda que necesita ser pagada?
- Si un desarrollador tiene miedo de tocar el código porque las cosas pueden salir mal, es una deuda técnica que debe abordarse. También es lo mismo si solo Jared puede tocar esa parte del código. Este no debería ser el patio de recreo de Jared; La propiedad del código es compartida.
- Si afecta la velocidad de entrega porque nadie entiende esa parte del código o es difícil agregar nuevos componentes, es un problema y vale la pena abordarlo. Capacidad para aceptar el cambio.
- Si tiene un problema para agregar nuevas pruebas para asegurar la calidad de cualquier cosa en una parte del producto, tiene una deuda técnica que vale la pena abordar. ¡Recuerda la excelencia técnica!
- Si afecta a la moral de sus equipos técnicos, es un problema y vale la pena abordarlo.
¿Qué causa la deuda técnica?
La deuda técnica es siempre un tema de toma de decisiones. Puede provenir de muchos frentes. Puede provenir de:
- Mal juicio: especialmente cuando al equipo técnico no se le dan todas las piezas del rompecabezas (o cuando no están interesados en él). Conocer exactamente las intenciones de una funcionalidad, quién la usa, cómo puede evolucionar, etc. El software se produce sobre una arquitectura, y desea que su arquitectura admita la necesidad real. No dejes que tus desarrolladores creen ciegamente “solo ese pequeño algo” para la próxima versión. Trate cada evolución del producto con respeto y sea minucioso.
- Falta de conocimiento: ¿solo tiene desarrolladores junior o todos son nuevos en la tecnología en cuestión? Cuanto más personas no entiendan completamente cómo implementar la tecnología, mayor será el riesgo de crear soluciones mediocres. Es solo el nombre del juego. Especialmente cuando no tienes tiempo para dejar que la gente aprenda primero. Y eso lleva a
- Atajos: ya sea porque es medianoche y la gente quiere irse a casa, es semana de lanzamiento y algo debe salir por la puerta, la gerencia no quiere perderse una fecha importante este trimestre … Entonces las personas pueden hacer por defecto lo mínimo.
Estrategias para evitar la deuda técnica (y arreglarla si tiene alguna)
Encuentro que las estrategias para arreglar la deuda técnica son las mismas que usas cuando quieres evitar asumir alguna. No es magia. ¡Las buenas prácticas suelen tener ese tipo de efecto!
Estándares de código y revisiones
Diga lo que quiera, hacer que sus compañeros miren su trabajo es una excelente manera de lograr calidad. Crear la solución juntos en lugar de confiar en que Amy piense sola en su esquina siempre es lo mejor.
Consigues que todo el equipo o al menos más de una cabeza critique tu trabajo. Todo el mundo debería tener su trabajo revisado, incluidas las personas más altas técnicamente.
Revisión por pares, programación en pares, normas de codificación, idealmente algunas que se pueden incrustar en su herramienta de análisis de código estático. Una tonelada puede ser prevenida o atrapada de esta manera.
Refactorización
Refactorizar y mejorar el código a medida que avanza. ¿Llegaste a una sección que no tiene pruebas? Agregue pruebas. ¿Llegaste a una parte del código que parece dudosa? Aclara las dudas.
Cuando lo haces sobre la marcha, es solo parte de la velocidad de tu equipo. Cuando esperas más tarde, tienes que tener esas reuniones con todos, dar estimaciones sobre cuánto tiempo tomará, justificar por qué necesita hacerse, y hacer todo el bla-bla.
Recuerde: usted no quiere que su deuda acumule intereses.
Infraestructura técnica existente
No tenemos tiempo e inteligencia para revisar todo en todas partes todo el tiempo. Entonces, lo mejor que podemos hacer por la felicidad de todos es armarnos con lo que la tecnología puede hacer por nosotros.
Cualquier equipo de desarrollo de software debe tener en su lugar no sólo un entorno automatizado de CI / CD, sino que también en estos entornos tener todo lo necesario para ejecutar análisis de código, análisis de rendimiento. Estas cosas pueden ser tan buenas como para comprobar la complejidad del código.
Si no eres un coach técnico, aún puedes ayudar a tu equipo a enorgullecerse de construir su “código para el código” o de poner en marcha la infraestructura que protege la evolución de sus productos. Y no solo el equipo. También desea sensibilizar a los gerentes y a las personas de productos.
Evita el pensamiento a corto plazo
Puede tomar decisiones informadas de renunciar a ciertos cambios en el producto. Pero cuando ese es el enfoque predeterminado, creo que merece algunas conversaciones
Enfoque proactivo: Haga que el equipo haga una lluvia de ideas y defina explícitamente en las reglas del equipo cómo lidiará con la deuda técnica. Examínese con frecuencia y evolucione las reglas. Ayúdelos a hacerlos cumplir, especialmente si reciben presión de la gente de negocios.
Cada vez que surjan nuevas características, tenga la conversación sobre cuánto cambio introduce, incluido lo que puede romper, lo que debe deshacerse o rehacerse. No es raro que las partes de arquitectura del producto necesiten refactorización de vez en cuando y esas no son tan rápidas como refactorizar solo piezas de código. Hazlo parte del ritual en la planificación de reuniones.
Enfoque reactivo: Si tendrá que comprometerse en función de los plazos, trace ya allí el plan para ponerse al día. Eso es lo que lo hace diferente de los atajos y el pensamiento a corto plazo. Literalmente significa algo así como “después de este lanzamiento, usaremos los próximos 2 meses para volver a trabajar ese XYZ”.
En resumen
- La deuda técnica es un tema de toma de decisiones.
- Es mejor no asumir deudas técnicas y evolucionar constante y adecuadamente su software.
- Los equipos técnicos y negocio deben trabajar juntos para evitar o pagar la deuda técnica. No es simplemente un tema del equipo técnico.
Si deseas mejorar en tu transformación ágil, te invitamos a inscribirte en nuestros cursos.
En Zimpled, somos proveedores autorizados y oficiales para obtener las certificaciones de SAFe (Scaled Agile Framework), certificaciones de DevOps Institute y certificaciones de Kanban tanto a nivel empresarial e individual.
