Deuda técnica

  • 1,132 views
Uploaded on

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.

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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,132
On Slideshare
0
From Embeds
0
Number of Embeds
7

Actions

Shares
Downloads
16
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Deuda técnica
    Rodrigo Corral
    rcorral@plainconcepts.com
    http://geeks.ms/blogs/rcorral
    Twitter: r_corral
  • 2. Primera ley de la programaciónn de Ward Cunningham:
    “Reducir la calidadalarga el tiempo de desarrollo”
    La deuda cuesta dinero
  • 3. ¿Qué hacer?
    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.
  • 4. ¿Cómo lo vendo?
    La tiranía de la curva J
  • 5. ¿Cómo lo vendo?
    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
  • 6. ¿Cómo la pago?
    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.
  • 7. ¿Qué hago?
    Ten principios.
    Nunca renuncies a ellos, bajo ningún concepto, y menos bajo presión.
    Construye una ética profesional.
    Tardarás una vida.
  • 8. Principios: The art of Unix programming
    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.
  • 9. Principios: Arquitectura ágil
    DRY: Don’t repeat yourself.
    SPOT: Single point of truth.
    KISS: Keep it simple, stupid.
    YAGNI: You are not going to need it.
  • 10. Principios: SOLID
    SRP (The Single ResponsibilityPrinciple): una clase debe tener una, y solamente una, razón para cambiar.
    OCP(The Open/ClosedPrinciple): una clase debe permitir ser extendida, sin necesitar ser modificada.
    LSP(TheLiskovSubstitutionPrinciple): las clases derivadas deben poder ser sustituibles por sus clases base.
    ISP(Interface SegregationPrinciple): hacer interfaces de grano fino que son específicos de clientes.
    DIP(TheDependencyInversionPrinciple): las abstracciones no deben depender de los detalles, los detalles deben depender de las abstracciones.
  • 11. Principios: Otros
    Los nombres importan mucho.
    NO tenemos scroll.