Deuda técnica

11

Click here to load reader

description

Presentación sobre la deuda técnica y las maneras de atajarla y comunicarla que realice en la Agile Open Space 2011 de Agile Spain.

Transcript of Deuda técnica

Page 2: Deuda técnica

Primera ley de la

programaciónn de

Ward Cunningham:

“Reducir la calidad

alarga el tiempo de

desarrollo”

Page 3: Deuda técnica

• Identifica áreas de deuda.– Usa métricas.

– Apóyate en herramientas.

– Pregunta al equipo.

• Asegura el ROI.– Prioriza.

– Analiza el impacto.

– Elige el momento.

• Paga la deuda.

• GOTO inicio.

Page 4: Deuda técnica

• La tiranía de la curva J

Page 5: Deuda técnica

• Necesitas un plan.

• La gente de negocio no entiende de tecnología sino de dinero.

• Evidence DEFEATS doubt:

– Ejemplos

• Enseña código, muestra historias no cerradas

– Hechos

• Retrasos, velocidad, problemas de calidad…

– Analogías

• La gente de negocio no entiende el software, busca analogías

– Testimonios

• El mismo mensaje a veces es más fuerte si viene ‘de fuera’

– Estadísticas

• Velocidad, tasa de bugs

Page 6: Deuda técnica

• Aprende, aprende, aprende.

• Usa la diplomacia.

• Ten una arquitectura inidentificable.

• Asegúrate de no romper nada.

• Asegúrate de que hay efectos visibles.

• Persevera.

– Hasta cierto punto (stop lost).

• No la pagues, evítala.

Page 7: Deuda técnica

• Ten principios.

• Nunca renuncies a ellos, bajo ningún

concepto, y menos bajo presión.

• Construye una ética profesional.

– Tardarás una vida.

Page 8: Deuda técnica

• Modularidad: Partes simples conectadas por interfaces claras.

• Claridad: Claridad es mejor que inteligencia.

• Composición: Diseña sistemas para se conectados con otros sistemas.

• Separación: Separa política de implementación.

• Simplicidad:: Diseña para la simplicidad, la complejidad debe ser obligatoria.

• Parsimonia: Escribe un programa si sabes que nada más puede funcionar.

• Trasparencia: Diseña para la visibilidad, hace la inspección y depuración facil.

• Robustez: La robustez emerge de la trasparencia y la simplicidad.

• Representación: Pon el conocimiento en los datos, para que el programa pueda se

simple.

• Mínima sorpresa: Diseña para evitar sorpresas.

• Silencio: Si el programa no tiene nada sorprendente que decir no digas nada.

• Reparación: Si fallas hazlo tan pronto y tan ruidosamente como puedas.

• Economía: El programador es más caro que la máquina.

• Generación: Siempre que puedas escribe programas que generen programas.

• Optimización: Prototipa antes de pulir. Primero que funcione, luego optimiza.

• Diversidad: No te creas ninguna verdad absoluta.

• Extensibilidad: Diseña para el futuro, llega antes de lo que esperas.

Page 9: Deuda técnica

• DRY: Don’t repeat yourself.

• SPOT: Single point of truth.

• KISS: Keep it simple, stupid.

• YAGNI: You are not going to need it.

Page 10: Deuda técnica

• SRP (The Single Responsibility Principle): una clase debe tener una, y solamente una, razón para cambiar.

• OCP (The Open/Closed Principle): una clase debe permitir ser extendida, sin necesitar ser modificada.

• LSP (The Liskov Substitution Principle): las clases derivadas deben poder ser sustituibles por sus clases base.

• ISP (Interface Segregation Principle): hacer interfaces de grano fino que son específicos de clientes.

• DIP (The Dependency Inversion Principle): las abstracciones no deben depender de los detalles, los detalles deben depender de las abstracciones.

Page 11: Deuda técnica

• Los nombres importan mucho.

• NO tenemos scroll.