Hablemos de Deuda Técnica

1.522 visualizaciones

Publicado el

Se cubren en estas diapositivas aspectos básicos de la deuda técnica y como afecta a los equipos de desarrollo, tester, product owners, scrum masters, al negocio en general.

Publicado en: Software

Hablemos de Deuda Técnica

  1. 1. 1 Hablemos de Deuda Técnica (y un poco de su relación con testing) JORGE HERNÁN ABAD LONDOÑO @jorge_abad Blog http://www.lecciones-aprendidas.info/ Agile Coach, Project Leader, Scrum Master and Always a Learner
  2. 2. 2
  3. 3. 3 Esta presentación contiene una compilación de diapositivas de: • Javier Garzas - @jgarzas • Ángel Nuñez - @snahider • Y algunas mías
  4. 4. 4 Miembro de Ágiles Colombia
  5. 5. 5 Miembro PMI Capítulo Antioquia  pmiantioquia.org  @pmiantioquia  facebook.com/PMIAntioquia  meetup.com/es-ES/Proximo-Capitulo-PMI-Antioquia/
  6. 6. 6 Mis objetivos con esta sesión: - Elevar nuestro nivel de conciencia sobre la deuda técnica - Inquietarlos - Ser disparador de un cambio para testers y team members
  7. 7. 7 Indaguemos
  8. 8. 8 ¿Quién conoce el concepto de deuda técnica
  9. 9. 9 La deuda técnica son las consecuencias de un desarrollo apresurado de software o un despliegue descuidado de hardware. Wikipedia
  10. 10. 10
  11. 11. 11 La deuda técnica son las consecuencias de: • un desarrollo apresurado • un desarrollo inconsciente de software • o un despliegue descuidado de hardware Que se terminará pagando ya sea con: • baja velocidad de desarrollo • inversión de tiempo removiéndola o • bajo rendimiento del sistema @jorge_abad
  12. 12. 12 Fuente: Javier Garzas - @jgarzas
  13. 13. 13 Fuente: Javier Garzas - @jgarzas
  14. 14. 14 Fuente: Javier Garzas - @jgarzas
  15. 15. 15 Ejemplo
  16. 16. 16 Fuente: Javier Garzas - @jgarzas
  17. 17. 17 ¿Quienes han estado en un proyecto que fue cancelado debido a que era más práctico iniciar de cero que continuar trabajando en el?
  18. 18. 18 Fuente: Javier Garzas - @jgarzas
  19. 19. 19 Fuente: Javier Garzas - @jgarzas
  20. 20. 20 Fuente: Javier Garzas - @jgarzas
  21. 21. 21 Fuente: Javier Garzas - @jgarzas
  22. 22. 22 Fuente: Javier Garzas - @jgarzas
  23. 23. 23Fuente: Javier Garzas - @jgarzas
  24. 24. 24 ¿Y CÓMO LUCE?
  25. 25. 25
  26. 26. 26 Nuestro servidor agotado por : • La carga • Necesita continuos reinicios • Carecemos de • buen hardware • Software liviano adecuado para el hardware • Software bien construido (por lo general las últimas dos)
  27. 27. 27 O aun peor…
  28. 28. 28 Ejemplos
  29. 29. 29 Ejemplos
  30. 30. 30
  31. 31. 31
  32. 32. 32
  33. 33. 33
  34. 34. 34 Fuente: Javier Garzas - @jgarzas
  35. 35. 35 Fuente: Javier Garzas - @jgarzas
  36. 36. 36Fuente: Javier Garzas - @jgarzas
  37. 37. 37 Algo tan inexplicable como esto
  38. 38. 38
  39. 39. 39
  40. 40. 40
  41. 41. 41 ¿Algún ejemplo más?
  42. 42. 42 Causas  Presiones de Negocio  Poco entendimiento del proceso  Software no modular, clases muy acopladas  Falta de una buena suite de pruebas  Falta de documentación  Falta de colaboración entre equipos  Falta de acompañamiento a desarrolladores jóvenes  Desarrollo paralelo (en dos o más branches)  Postergar la refactorización  Inexistencia de estándares o no alineación con ellos  Poco conocimiento por parte del desarrollador de buenas prácticas  Poca apropiación del código  Pobre liderazgo técnico  Subutilización del software base  Sobreutilización del software base  Presiones por cambios de último minuto  Entre otros
  43. 43. 43
  44. 44. 44 Síntomas  Despliegue lentos  Constantes reinicios del servidor por consumo de memoria  Código inmantenible  Código inestable o con el síndrome de castillo de naipes  Costo alto de cambios  Costo alto de corrección de código  Disminución de la velocidad de los sprints  Entre otros
  45. 45. 45 Fuente: Ángel Nuñez - @snahider
  46. 46. 46 Efectos Fuente: Henrik Kniberg - @henrikknigberg
  47. 47. 47 Fuente: Javier Garzas - @jgarzas
  48. 48. 48
  49. 49. 49 Fuente: Ángel Nuñez - @snahider
  50. 50. 50 Fuente: Ángel Nuñez - @snahider
  51. 51. 51 Deuda técnica a ser pagada
  52. 52. 52 Fuente: Javier Garzas - @jgarzas
  53. 53. 53 Fuente: Javier Garzas - @jgarzas
  54. 54. 54 Fuente: Ángel Nuñez - @snahider
  55. 55. 55 Fuente: Ángel Nuñez - @snahider
  56. 56. 56 Fuente: Ángel Nuñez - @snahider
  57. 57. 57 Process Debt Methodology Debt Fuente: Ángel Nuñez - @snahider
  58. 58. 58 Fuente: Ángel Nuñez - @snahider
  59. 59. 59 Fuente: Javier Garzas - @jgarzas
  60. 60. 60 Fuente: Javier Garzas - @jgarzas
  61. 61. 61 Fuente: Javier Garzas - @jgarzas
  62. 62. 62 Fuente: Javier Garzas - @jgarzas
  63. 63. 63Fuente: Javier Garzas - @jgarzas
  64. 64. 64 Fuente: Javier Garzas - @jgarzas
  65. 65. 65 Fuente: Javier Garzas - @jgarzas
  66. 66. 66 Fuente: Ángel Nuñez - @snahider
  67. 67. 67 Fuente: Ángel Nuñez - @snahider
  68. 68. 68 Fuente: Ángel Nuñez - @snahider
  69. 69. 69 Fuente: Ángel Nuñez - @snahider
  70. 70. 70 Fuente: Ángel Nuñez - @snahider
  71. 71. 71 Fuente: Ángel Nuñez - @snahider
  72. 72. 72 Prácticas Técnicas compartidas por todo el equipo • Revisiones de código • Buenas practicas de desarrollo (Principios SOLID, ACID, etc) • Pruebas de Aceptación • Pruebas Unitarias • Propiedad Colectiva de Código • Clean Code • Test Driven Development • Integración Continua • Entrega Continua (Continuous Delivery) • Diseño Simple • Programación por Pares • Mob Programming • Mob Testing • Estándares de Codificación • Refactoring • Monitoreo de la deuda técnica
  73. 73. 73 Fuente: Ángel Nuñez - @snahider
  74. 74. 74 Fuente: Ángel Nuñez - @snahider
  75. 75. 75 Como resolverla
  76. 76. 76 Como resolverla
  77. 77. 77 Fuente: Ángel Nuñez - @snahider
  78. 78. 78
  79. 79. 79 Y… ¿Testing?
  80. 80. 80
  81. 81. 81
  82. 82. 82
  83. 83. 83
  84. 84. 84 ¡Todo esto cambió!
  85. 85. 85
  86. 86. 86 ¿Qué podemos hacer desde pruebas?  Ser preventivos  Estar atentos a los síntomas  Realizar inspecciones de código, buscar smells – Clases gigantes – Webservices gigantes – Tablas gigantes, etc  Hacer consciente al equipo de la deuda técnica  Trabajar de la mano del SM en la mejora continua y ser el vigilante de la deuda técnica (usar Sonar u otra herramienta), para gestionarla en el presente y en el tiempo dentro del backlog  Realizar pruebas no funcionales  Automatice las pruebas  Estar alerta a funcionalidades «lentas»  Velar por los estándares  No caer en presiones que impliquen reducción de la calidad y se decide asumir la deuda, asegurarse que sea gestionada  Asegurarse de que se pague  Ser un verdadero QA ágil
  87. 87. 87 Cambios de paradigmas
  88. 88. 88 Y los otros roles de Scrum ¿Qué?
  89. 89. 89 El/la Product Owner • Priorizará dentro del backlog la remoción de la deuda técnica cada Sprint
  90. 90. 90 El/la Scrum Master • Monitoreará la Deuda Técnica • Y seguirá velando por su excelencia técnica
  91. 91. 91 Fuente: Ángel Nuñez - @snahider
  92. 92. 92 Principios Ágiles http://agilemanifesto.org/iso/es/prin ciples.html
  93. 93. 93
  94. 94. 94 Por último… No trates de remover la deuda técnica de la siguiente forma
  95. 95. 95
  96. 96. 96 No esperes a que la deuda de tu software no pueda ser pagada, comienza a gestionarla
  97. 97. 97
  98. 98. 98 ¿Logré mi propósito? Espero que si…
  99. 99. 99 PREGUNTAS
  100. 100. 100
  101. 101. 101 ¡GRACIAS! Jorge H. Abad L. jorge.abad@gmail.com @jorge_abad Blog http://www.lecciones-aprendidas.info/
  102. 102. 102Conferencia auspiciada por el PMI Antioquia Colombia Potential Chapter – La propiedad intelectual de esta pertenece al facilitador Anexos
  103. 103. 103 Fuentes y referencias  http://es.slideshare.net/JavierGarzas/deuda-tecnica-slideshare  http://es.slideshare.net/snahider/software-debt-que-es-y-como-gestionarlo  https://es.wikipedia.org/wiki/Deuda_t%C3%A9cnica  https://en.wikipedia.org/wiki/Technical_debt  http://es.slideshare.net/JavierGarzas/qa-gil-o-te-quedaste-en-el-qa-de-los- 80-nov-2014-ii-jornadas-calidad-software-qa-open-space
  104. 104. 104 Estas presentación contiene algunas diapositivas de  Javier Garzas @jgarzas  Ángel Nuñez @snahider  Henrik Kniberg @henrikkniberg  Nota: Trate de dar crédito a todos, pero consideras que faltaste por que no te referencié o debo modificar algo de tu propiedad por favor no dudes en hacérmelo saber, contactándome al email: jorge.abad@gmail.com
  105. 105. 105 Aviso de Copyright  Usted es libre de: – Compartir- copiar, distribuir y trasmitir el trabajo – Modificar- adaptar el trabajo  Bajo las siguientes condiciones – Atribución. Ud. debe atribuir el trabajo en la manera especificada por el autor o licenciante (pero de ninguna manera que sugiera que ellos aprueban su uso del trabajo).  Nada de lo dispuesto en esta licencia menoscaba o restringe los derechos morales del autor.  Para más información ver http://creativecommons.org/licenses/by/3.0/
  106. 106. 106 Información de contacto  Jorge Hernán Abad Londoño –jorge.abad@gmail.com –@jorge_abad
  107. 107. 107 Bonus track
  108. 108. 108

×