api deuda técnica.pptx
TRANSCRIPT
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”