La deuda técnica¿Satisfacemos los requerimientos de

costo/tiempo o entregamos lo solicitado?

La disputa en los proyectos

Satisfacer las restriccionesde tiempo/costo

Requerimientos de entregacon calidad

• Aspectos procedimentales• Aspectos estratégicos

Avance ideal del proyecto

Velocidadplanificada

Tiempo

Fecha predeterminadade entrega

Visión simplista e idealizadadel trabajo a realizar a través

del tiempo

Esfuerzo planificado

Avance real del proyecto

Velocidadplanificada

Tiempo

Fecha predeterminadade entrega

Visión simplista e idealizadadel trabajo a realizar a través

del tiempo

Tasa real a la que se estácompletando el trabajo

de calidad

Fecha de entregaproyectada

Esfuerzo subestimado

El costo del ajuste

Velocidadplanificada

Tiempo

Fecha predeterminadade entrega

Visión simplista e idealizadadel trabajo realizado a través

del tiempo

Tasa real a la que se estácompletando el trabajo

de calidad

Fecha de entregaproyectada

En este punto se ejerce presión a fin de cumplir con la fechapredeterminada...y la calidad

se ve afectada

Deuda técnica

• La metáfora de deuda técnica, desarrollada por Ward Cunnigham en 1992, explica cómo el proceso de desarrollar de forma “rápida y sucia” nos hace incurrir en una deuda, que al igual que una deuda financiera, nos obliga al pago de intereses, que se traducen en un esfuerzo extra a realizar en las siguientes iteraciones de desarrollo.

Deuda técnica• La deuda técnica es un eufemismo

tecnológico que hace referencia a las consecuencias de un desarrollo apresurado de software o un despliegue descuidado de hardware.

• La deuda puede verse como trabajo que necesita realizarse antes que el proyecto pueda considerarse como completo.

• La deuda técnica es el costo y los intereses a pagar por hacer mal las cosas.

• La deuda técnica impide progresar, obtener ganancias, cancelar las deudas.

¿Qué sucede con el software?

¿Qué sucede con el software?

ES UNA CUESTIÓN DE PÁGAME AHORA O PÁGAME DESPUÉS

Imposible de mantener

¿alguna semejanza?

¿les suena familiar?

“Déjate de probar (o de diseñar, documentar, refactorizar, etc.)

y ponte a programar, que no tenemos tiempo”.

Ante esta situación…

Mejoras al software

Un desarrollo de mala calidad, obtiene beneficios

a corto plazo. Pero puede generar DEUDA cuyos

intereses se disparen, se alarguen o incluso sean

imposibles de pagar.

Nuevas característicasFuncionalidad

adicional

Arquitectura,Características estructurales

DefectosDeudatécnica

Visible Invisible

Valorpositivo

Valornegativo

Cuadrante de deuda técnica

Fuente: Martin Fowler

Costos asociados

Tiempo

Costo

Código rápido sin probar

Simple, Test-Driven Desig

Código heredado

Código heredado

Bancarrota

Intereses

Prestamos

Pago de principal

Inflación

Opinión de los expertos

Los olores del código

Deuda técnica

Velocidadplanificada

Tiempo

Fecha predeterminadade entrega

Área de “Deuda Técnica”

Fecha de entregaproyectada

Tenemos un problema

Incremento en la deuda técnica

Velocidadplanificada

Tiempo

1ra. entrega

Incremento del Área de “Deuda Técnica”

2ª. entrega

Velocidad del proyecto original

La velocidad del equipo trabajando en la versión 2 es significativamente menor debido a la baja calidad en el código

¿qué pasa con scrum?

¿Tenemos las respuestas?Si este trabajo técnico no hecho es necesario para la salud del proyecto,

• ¿qué pasa cuando no se hace nada con él?• ¿qué pasa cuando se acumula y continúa

acumulando deuda técnica y no se atiende?

“diseño muerto”

síntomas

ejemplos

• Errores conocidos y no solucionados• Retraso en las actualizaciones críticas• Retraso en el refactoring del código complejo• En aplicaciones web, codificar toda la lógica de

negocios en la capa de presentación• No utilizar logs o manejo de errores robusto• No realizar pruebas o realizarlas de forma muy

superficial• Mejoras de código no implementadas• Documentación incompleta, inexistente o no

actualizada

Como se materializa

• Documentación escasa, incompleta o inservible.• Errores.• Ausencia o deficiente control de versiones.• Arquitectura no escalable.• Rigidez para actualizar a nuevas tecnologías o

plataformas.

No toda la deuda técnica es mala

¿Como manejar la deuda técnica?

“The time you take out of the schedule to make technical debt payments typically doesn’t result in anything the customers or users will see…” – Jeff Atwood

framework

Lista DT

Identificación DT

Estimación DT

Toma de decisiones

ITEM de Deuda técnica

Riesgo

¿debemos eliminar toda a deuda técnica?

Involucrar y educar

Involucrar al product owner

Evaluar decisiones

ejemplo

ejemplo

Riesgos de deuda técnica

¿Cómo se evitan los riesgos de deuda técnica?

Visualizar y medir

Métricas de código

Velocidad y bugs

backlog

Pull systems

Definition of done

Enfoques para pagar la deuda

Priorizar y el backlog

Priorizar y el backlog

Priorizar y el backlog

Priorizar y el backlog

Priorizar y el backlog

Distribuir cada sprint

Toyota kata

Incluir la calidad en la gestión del portafolio

Medida de éxito tradicional

Triángulo ágil

métrica

Cuantificar la deuda

MVP

Propósito del mvp

• Probar un producto con el mínimo de recursos.• Acelerar el aprendizaje sobre la utilidad del

producto.• Reducir el desperdicio de horas de ingeniería.• Liberar el producto a los usuarios lo más pronto

posible.

A Qué aspiramos

Cambio cultural

La META es la CALIDAD

La Ley fundamental de programación de Ward Cunningham indica:

“reducir la calidad, incrementa el tiempo de desarrollo.”

Conclusiones“Todo mundo debería saber que la malaCalidad en el software, al final se paga”

“No subestimemos el peligro”