Deuda técnica<br />Rodrigo Corral<br />rcorral@plainconcepts.com<br />http://geeks.ms/blogs/rcorral<br />Twitter: r_corral...
Primera ley de la programaciónn de Ward Cunningham:<br />“Reducir la calidadalarga el tiempo de desarrollo”<br />La deuda ...
¿Qué hacer?<br />Identifica áreas de deuda.<br />Usa métricas.<br />Apóyate en herramientas.<br />Pregunta al equipo.<br /...
¿Cómo lo vendo?<br />La tiranía de la curva J<br />
¿Cómo lo vendo?<br />Necesitas un plan.<br />La gente de negocio no entiende de tecnología sino de dinero.<br />Evidence D...
¿Cómo la pago?<br />Aprende, aprende, aprende.<br />Usa la diplomacia.<br />Ten una arquitectura inidentificable.<br />Ase...
¿Qué hago?<br />Ten principios.<br />Nunca renuncies a ellos, bajo ningún concepto, y menos bajo presión.<br />Construye u...
Principios: The art of Unix programming<br />Modularidad: Partes simples conectadas por interfaces claras.<br />Claridad: ...
Principios: Arquitectura ágil<br />DRY: Don’t repeat yourself.<br />SPOT: Single point of truth.<br />KISS: Keep it simple...
Principios: SOLID<br />SRP (The Single ResponsibilityPrinciple): una clase debe tener una, y solamente una, razón para cam...
Principios: Otros<br />Los nombres importan mucho.<br />NO tenemos scroll.<br />
Upcoming SlideShare
Loading in …5
×

Deuda técnica

1,497 views
1,349 views

Published 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.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,497
On SlideShare
0
From Embeds
0
Number of Embeds
511
Actions
Shares
0
Downloads
18
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Deuda técnica

  1. 1. Deuda técnica<br />Rodrigo Corral<br />rcorral@plainconcepts.com<br />http://geeks.ms/blogs/rcorral<br />Twitter: r_corral<br />
  2. 2. Primera ley de la programaciónn de Ward Cunningham:<br />“Reducir la calidadalarga el tiempo de desarrollo”<br />La deuda cuesta dinero<br />
  3. 3. ¿Qué hacer?<br />Identifica áreas de deuda.<br />Usa métricas.<br />Apóyate en herramientas.<br />Pregunta al equipo.<br />Asegura el ROI.<br />Prioriza.<br />Analiza el impacto.<br />Elige el momento.<br />Paga la deuda.<br />GOTO inicio.<br />
  4. 4. ¿Cómo lo vendo?<br />La tiranía de la curva J<br />
  5. 5. ¿Cómo lo vendo?<br />Necesitas un plan.<br />La gente de negocio no entiende de tecnología sino de dinero.<br />Evidence DEFEATS doubt:<br />Ejemplos<br />Enseña código, muestra historias no cerradas<br />Hechos<br />Retrasos, velocidad, problemas de calidad…<br />Analogías<br />La gente de negocio no entiende el software, busca analogías<br />Testimonios<br />El mismo mensaje a veces es más fuerte si viene ‘de fuera’<br />Estadísticas<br />Velocidad, tasa de bugs<br />
  6. 6. ¿Cómo la pago?<br />Aprende, aprende, aprende.<br />Usa la diplomacia.<br />Ten una arquitectura inidentificable.<br />Asegúrate de no romper nada.<br />Asegúrate de que hay efectos visibles.<br />Persevera.<br />Hasta cierto punto (stop lost).<br />No la pagues, evítala.<br />
  7. 7. ¿Qué hago?<br />Ten principios.<br />Nunca renuncies a ellos, bajo ningún concepto, y menos bajo presión.<br />Construye una ética profesional.<br />Tardarás una vida.<br />
  8. 8. Principios: The art of Unix programming<br />Modularidad: Partes simples conectadas por interfaces claras.<br />Claridad: Claridad es mejor que inteligencia.<br />Composición: Diseña sistemas para se conectados con otros sistemas.<br />Separación: Separa política de implementación.<br />Simplicidad:: Diseña para la simplicidad, la complejidad debe ser obligatoria.<br />Parsimonia: Escribe un programa si sabes que nada más puede funcionar.<br />Trasparencia: Diseña para la visibilidad, hace la inspección y depuración facil.<br />Robustez: La robustez emerge de la trasparencia y la simplicidad.<br />Representación: Pon el conocimiento en los datos, para que el programa pueda se simple.<br />Mínima sorpresa: Diseña para evitar sorpresas.<br />Silencio: Si el programa no tiene nada sorprendente que decir no digas nada.<br />Reparación: Si fallas hazlo tan pronto y tan ruidosamente como puedas.<br />Economía: El programador es más caro que la máquina.<br />Generación: Siempre que puedas escribe programas que generen programas.<br />Optimización: Prototipa antes de pulir. Primero que funcione, luego optimiza.<br />Diversidad: No te creas ninguna verdad absoluta.<br />Extensibilidad: Diseña para el futuro, llega antes de lo que esperas.<br />
  9. 9. Principios: Arquitectura ágil<br />DRY: Don’t repeat yourself.<br />SPOT: Single point of truth.<br />KISS: Keep it simple, stupid.<br />YAGNI: You are not going to need it.<br />
  10. 10. Principios: SOLID<br />SRP (The Single ResponsibilityPrinciple): una clase debe tener una, y solamente una, razón para cambiar.<br />OCP(The Open/ClosedPrinciple): una clase debe permitir ser extendida, sin necesitar ser modificada.<br />LSP(TheLiskovSubstitutionPrinciple): las clases derivadas deben poder ser sustituibles por sus clases base.<br />ISP(Interface SegregationPrinciple): hacer interfaces de grano fino que son específicos de clientes.<br />DIP(TheDependencyInversionPrinciple): las abstracciones no deben depender de los detalles, los detalles deben depender de las abstracciones.<br />
  11. 11. Principios: Otros<br />Los nombres importan mucho.<br />NO tenemos scroll.<br />

×