diff --git a/index_ES.html b/index_ES.html new file mode 100644 index 0000000..770d79a --- /dev/null +++ b/index_ES.html @@ -0,0 +1,447 @@ + + + + + + + + + + + Deuda Técnica - Luis García Castro + + + + + + +
+

Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.

+

For the best experience please use the latest Chrome, Safari or Firefox browser.

+
+ +
+ + + +
+
+

Deuda Técnica

+
+
+

Para desarrolladores... ¡y managers!

+
+
+

Octubre 2014
Luis García Castro

+
+
+ +
+
+

Comentarios recurrentes

+
+ +
+
    +
  • ¿No teníamos documentados estos servicios?
    • +
  • Pensé que habíamos probado este módulo...
    • +
  • Si arreglo esto se romperá eso otro... creo
    • +
  • No toques eso, la última vez que alguien tocó se rompió XXX
    • +
  • Pon un comentario y ya lo miraremos después
    • +
  • Pon un TODO y ya lo miraremos después
    • +
  • Pon un comentario, ahí justo encima del TODO
    • +
  • ¡Yo sólo toqué una línea!
    • +
+
+
+ +
+
+

La deuda técnica...
¿es buena o mala?

+
+
+ +
+
Motivos para dar esta charla
+
+
    +
  • Orientar al personal técnico sobre la toma de decisiones de negocio
    • +
  • Orientar al personal de negocio sobre la toma de decisiones técnicas
    • +
  • Ayudar a que la deuda técnica pueda ser gestionada de forma más explícita y transparente
    • +
  • Aumentar la conciencia sobre este asunto
    • +
+
+
+ + + +
+
+

Contenido

+
+
+
    +
  1. Introducción a la deuda técnica
    2. +
      +
    • Analogías con la deuda financiera
      • +
    • Tipos de deuda financiera
      • +
    • Síntomas
      • +
    +
  2. Cómo, cuándo y por qué endeudarse
    3. +
  3. Deuda técnica vs código de mala calidad
    4. +
  4. Pagando la deuda técnica
    5. +
+
+
+ +
+
Introducción
+
+

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. [...] The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation.

+

Ward Cunningham, Marzo de 1992

+
+
+
    +
  • "Ward" Cunningham is an American computer programmer who developed the first wiki.
    • +
  • You start writing an application. In the beginning there is no need for user roles. Everyone can do anything. At some point you start having two different permissions for a specific action. The tech team considers whether to create a full fledged permission system, but at this point it really looks like over engineering. Some time later another thing requires the differentiation of users, and then another and another. The solution is refactoring it to have a decent permission system. To make this refactoring will take way more time than just adding another method, but will simplify the code and make future permissions to be added with one line of code, or even by just adding a row in the database. +
      +
    • * 4 now (the permission), 22 later (the refactoring, that now is a bit more complicated)
      • +
    • * 21 now (the refactoring), 0 later (the permission)
      • +
    • * 4 now (the permission), no refactoring at all, and then 5 for the next permissions, and then 6, 7… until the point a new refactoring is suggested, now costing 50-something
      • +
    +
    • +
+
+
+ +
+
Analogías con la deuda financiera
+
+
    +

  • Interés

    • +

  • Amortizar capital

    • +

  • Ampliar un préstamo

    • +

  • Bancarrota

    • +

  • Inflación técnica

    • +

  • Amnistía fiscal

    • +
+
+
+
    +
  1. Interés - Cada minuto que pasas con código poco limpio
    2. +
  2. Amortizar - Refactorizar
    3. +
  3. Ampliar un préstamo - Las negligencias de diseño
    4. +
  4. Bancarrota - Situación con un interés sobre la deuda tan grande que es imposible avanzar y es necesario una reescritura completa
    5. +
  5. Inflación Técnica - Cuando el actual nivel de nuestra tecnología es suficientemente viejo como para perder compatibilidad con el resto de la industria
    6. +
  6. Aminstía Fiscal - Desechar prototipos, productos o componentes y renunciar a usarlos
    7. +
+
+
+ +
+
Tipos de deuda técnica
+
+
    +
  • Intencionada vs NO intencionada
    • +
  • Deuda de diseño o arquitectura
    • +
  • Deuda de calidad
    • +
  • Deuda en los tests
    • +
  • Deuda en el conocimiento y la documentación
    • +
  • Deuda en el entorno
    • +
+
+
+
    +
  • Intencionada: “No hay tiempo para hacerlo multi-idioma, ya se hará en el futuro”
    • +
  • Intencionada: “No hay tiempo para completar los test, ya lo haremos cuando subamos a PRO”
    • +
  • No intencionada: Dejar que alguien escriba código que no sigue cierto estándar
    • +
  • No intencionada: Una decisión importante de diseño que finalmente fracasa
    • +
  • No intencionada: Dejar sin supervisión al programador junior
    • +
  • Diseño: soluciones no óptimas, atajos
    • +
  • Tests: Pocos test automáticos y demasiadas pruebas de regresión
    • +
  • Documentación: Sólo unos pocos conocen el sistema
    • +
  • Hardware, entornos,... demasiadas acciones manuales
    • +
+ +
+
+ +
+
Síntomas
+
+
    +

  • Pérdida de productividad, motivación, ...

    • +

  • Incremento en los test manuales

    • +

  • Retrasos en entregas

    • +

  • Código duplicado

    • +

  • Código ilegible

    • +

  • Incremento imparable de defectos

    • +

  • Excesivo estrés en cada entrega

    • +

  • Miedo a tocar el código

    • +

  • Librerías anticuadas

    • +
+
+
+
    +
  1. Siempre que podamos medir la productividad (Scrum)
    2. +
  2. Dedicamos demasiado tiempo a pruebas de regresión
    3. +
  3. Cada vez es más difícil cumplir los deadlines
    4. +
  4. Conduce a anomalías y problemas en el soporte
    5. +
  5. Falta de calidad y control
    6. +
  6. El equipo sufre demasiada presión
    7. +
  7. El 80% del tiempo se pasa leyendo código, si no se entiende no se puede construir
    8. +
  8. Es todo tan delicado que no hay forma de tocar sin romper nada
    9. +
  9. Y no somos capaces de actualizar las versiones
    10. +
+
+
+ +
+
Ventajas e incovenientes
+
+
    +
  • +

    Algunas ventajas:

    +
      +
    • Se acorta el Time To Market
      • +
    • Se preserva el capital de la compañía (esencial en startups)
      • +
    • Se aplazan decisiones y ciertos costes de desarrollo
      • +
    +
    • +
  • +

    Y algunos inconvenientes:

    +
      +
    • Reduce la velocidad y la productividad
      • +
    • Aumenta el riesgo
      • +
    • Limita los nuevos desarrollos
      • +
    • Conduce a un círculo vicioso
      • +
    +
    • +
+
+
+
    +
  • The mantra created by LinkedIn’s founder Reid Hoffman “if you are not embarrassed by the first version of your product, you’ve launched too late” quickly became an excuse for an anything goes approach. Thousands of startups have launched and failed precisely for the lack of quality.
    • +
  • MVP vs MLP
    • +
  • Exercise: Draw your technical curve http://blog.crisp.se/2013/10/11/henrikkniberg/good-and-bad-technical-debt
    • +
+
+
+ + +
+
Cómo evitar deuda no intencionada
+
+
    +

  • Automatiza (IC) los test todo lo posible (¡unitarios y funcionales!)

    • +

  • Comparte el conocimiento (técnico y funcional)

    • +

  • Deja siempre el código tan limpio como lo encontraste, o si es posible mejor

    • +

  • Concreta (si no lo hiciste ya) una buena DoD

    • +

  • Kaizen: TDD, BDD, Fail Fast, Peer Reviews, Code Reviews, ...

    • +

  • Limita el WIP, siempre

    • +

  • Monitoriza en cada momento la deuda

    • +

  • Y en definitiva: Nunca pidas permiso para hacer tu trabajo correctamente

    • +
+
+
+ +
+
Cómo endeudarse intencionadamente
+
+
    +
  • Toda la deuda intencionada puede y debe ser trazada (por definición)
    • +
  • Con la misma consideración que un defecto
    • +
  • Incluye tu deuda en el Product Backlog
    • +
  • Monitoriza la velocidad del proyecto
    • +
  • Monitoriza la cantidad de retrabajo
    • +
  • Adapta tus presupuestos
    • +
  • Mide la deuda en dinero
    • +
+
+
+ +
+
+

Deuda técnica
vs
Código de mala calidad

+
+
+
    +
  • It’s a responsibility of the tech team to make business understand the consequences of this kind of action
    • +
  • Technical debt can be paid by refactoring. It takes time but it’s doable. But when code is just bad, refactoring is way, way harder.
    • +
  • Michael Feathers, have defined legacy code as code without tests: +
    “Code without tests is bad code. + It doesn’t matter how well written it is; it doesn’t matter + how pretty or object-oriented or well-encapsulated it is. + With tests, we can change the behavior of our code quickly and verifiably. + Without them, we really don’t know if our code is getting better or worse.”
    • +
+
+
+ +
+
+

Pagando
la deuda técnica

+
+
+
    +
  • When developers propose a big rewrite, and for whatever crazy reasons, business agrees, the stage is set for a new kind of failure: +
      +
    • It turns out that it’s virtually impossible to track all functionality in a legacy code base, and few rewrite projects take the huge necessary time to document everything.
      • +
    • Business will ask is about deadlines. Estimating a big rewrite is probably one of the most unrealistic things one can try to do.
      • +
    • Business will not accept all new features to be halted. Therefore there will be the need to keep track of them, and to reimplement them as well. And all relevant data should be migrated
      • +
    • In the rush to convince business, developers will promise all kinds of things, like that the refactoring will make the system faster, more robust or scalable…
      • +
    • Given part of the problem was developer’s inexperience in coding itself, how can they guarantee that now they know better?
      • +
    • Generally, planning is not a particular strength of the kind of project that ends up needing a rewrite. Will the rewrite be properly planned?
      • +
    +
+
+
+ +
+
Antes de pagar la deuda técnica
+
+
    +
  • ¿Hemos estimado cuánto cuesta pagar y cuánto no pagar?
    • +
  • ¿Nos creemos esas estimaciones?
    • +
  • ¿Cuánto reduciremos el esfuerzo actual para dedicarlo a deuda?
    • +
  • ¿Cuánto cuesta una solución sucia?
    • +
  • ¿Cuánto cuesta una solución limpia?
    • +
  • ¿Cuánto costaría hacer la solución limpia si haremos ahora la sucia?
    • +
+
+
+ +
+
Cómo se paga la deuda técnica
+
+
    +
  1. Comenta con los responsables técnicos tu propuesta y el alcance de la misma
    2. +
  2. Mide con ellos la deuda que queréis pagar
    3. +
  3. Comunica claramente las implicaciones a los responsables de negocio
    4. +
  4. Logra decisiones explícitas sobre si se debe amortizar más o menos deuda
    5. +
  5. Diseña estrategias para evitar que al pagar se genere nueva deuda
    6. +
  6. Toma decisiones explícitas sobre cuándo y cómo se va a pagar
    7. +
+
+
+ +
+
+

¿Preguntas?

+
+
+ +
+
Bibliografía
+
+ +

+ + Link to article + Ward Cunningham    The WyCash Portfolio Management System + +

+

+ + Link to article + Joao Milho    Technical Debt 101 + +

+

+ + Link to article + Steve McConnell    How to Categorize & Communicate Technical Debt + +

+

+ + Link to article + Chad Fowler    The Big Rewrite + +

+

+ + Link to article + Henrik Kniberg    Good and Bad Technical Debt + +

+

+ + Link to article + Olivier Gaudin    Technical Debt plugin para Sonar + +

+

+ + Link to article + NYTimes    Billion-Dollar Flop: Air Force Stumbles on Software Plan + +

+

+ + Link to article + Lemi Orhan Ergin    Technical Debt: Do Not Underestimate The Danger + +

+ +
+
+ +
+

¡ Gracias !

+
+
+

+ Luis García Castro +

+

+ luis.garcia@sopra.com +

+

+ + Google Plus + luisgc@gmail.com + +

+

+ + LinkedIn + http://www.linkedin.com/in/LuisGC + +

+

+ + GitHub + https://github.com/LuisGC + +

+
+

+ + Creative Commons + Licencia Creative Commons CC-BY-SA + +

+

+ + Impress.js + Presentación realizada con la herramienta Open Source Impress.js + +

+ +
+
+ +
+ +
+ + + + + +