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.

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

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
Miembro de Ágiles Colombia

5. 5
Miembro PMI Capítulo Antioquia
 pmiantioquia.org
 @pmiantioquia
 facebook.com/PMIAntioquia
 meetup.com/es-ES/Proximo-Capitulo-PMI-Antioquia/

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
Indaguemos

8. 8
¿Quién conoce
el concepto de
deuda técnica

9. 9
La deuda técnica son
las consecuencias de un
desarrollo apresurado
de software o un
despliegue descuidado
de hardware.
Wikipedia

10. 10

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
Fuente: Javier Garzas - @jgarzas

13. 13
Fuente: Javier Garzas - @jgarzas

14. 14
Fuente: Javier Garzas - @jgarzas

15. 15
Ejemplo

16. 16
Fuente: Javier Garzas - @jgarzas

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
Fuente: Javier Garzas - @jgarzas

19. 19
Fuente: Javier Garzas - @jgarzas

20. 20
Fuente: Javier Garzas - @jgarzas

21. 21
Fuente: Javier Garzas - @jgarzas

22. 22
Fuente: Javier Garzas - @jgarzas

23. 23Fuente: Javier Garzas - @jgarzas

24. 24
¿Y CÓMO LUCE?

25. 25

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
O aun peor…

28. 28
Ejemplos

29. 29
Ejemplos

30. 30

31. 31

32. 32

33. 33

34. 34
Fuente: Javier Garzas - @jgarzas

35. 35
Fuente: Javier Garzas - @jgarzas

36. 36Fuente: Javier Garzas - @jgarzas

37. 37
Algo tan inexplicable como esto

38. 38

39. 39

40. 40

41. 41
¿Algún ejemplo más?

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

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
Fuente: Ángel Nuñez - @snahider

46. 46
Efectos
Fuente: Henrik Kniberg - @henrikknigberg

47. 47
Fuente: Javier Garzas - @jgarzas

48. 48

49. 49
Fuente: Ángel Nuñez - @snahider

50. 50
Fuente: Ángel Nuñez - @snahider

51. 51
Deuda técnica a ser pagada

52. 52
Fuente: Javier Garzas - @jgarzas

53. 53
Fuente: Javier Garzas - @jgarzas

54. 54
Fuente: Ángel Nuñez - @snahider

55. 55
Fuente: Ángel Nuñez - @snahider

56. 56
Fuente: Ángel Nuñez - @snahider

57. 57
Process Debt
Methodology Debt
Fuente: Ángel Nuñez - @snahider

58. 58
Fuente: Ángel Nuñez - @snahider

59. 59
Fuente: Javier Garzas - @jgarzas

60. 60
Fuente: Javier Garzas - @jgarzas

61. 61
Fuente: Javier Garzas - @jgarzas

62. 62
Fuente: Javier Garzas - @jgarzas

63. 63Fuente: Javier Garzas - @jgarzas

64. 64
Fuente: Javier Garzas - @jgarzas

65. 65
Fuente: Javier Garzas - @jgarzas

66. 66
Fuente: Ángel Nuñez - @snahider

67. 67
Fuente: Ángel Nuñez - @snahider

68. 68
Fuente: Ángel Nuñez - @snahider

69. 69
Fuente: Ángel Nuñez - @snahider

70. 70
Fuente: Ángel Nuñez - @snahider

71. 71
Fuente: Ángel Nuñez - @snahider

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
Fuente: Ángel Nuñez - @snahider

74. 74
Fuente: Ángel Nuñez - @snahider

75. 75
Como resolverla

76. 76
Como resolverla

77. 77
Fuente: Ángel Nuñez - @snahider

78. 78

79. 79
Y… ¿Testing?

80. 80

81. 81

82. 82

83. 83

84. 84
¡Todo esto cambió!

85. 85

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
Cambios de paradigmas

88. 88
Y los otros roles de Scrum
¿Qué?

89. 89
El/la Product Owner
• Priorizará dentro
del backlog la
remoción de la
deuda técnica cada
Sprint

90. 90
El/la Scrum Master
• Monitoreará la Deuda
Técnica
• Y seguirá velando por su
excelencia técnica

91. 91
Fuente: Ángel Nuñez - @snahider

92. 92
Principios Ágiles
http://agilemanifesto.org/iso/es/prin
ciples.html

93. 93

94. 94
Por último…
No trates de remover la deuda
técnica de la siguiente forma

95. 95

96. 96
No esperes a que la deuda de
tu software no pueda ser
pagada, comienza a
gestionarla

97. 97

98. 98
¿Logré mi
propósito?
Espero que si…

99. 99
PREGUNTAS

100. 100

101. 101
¡GRACIAS!
Jorge H. Abad L.
jorge.abad@gmail.com
@jorge_abad
Blog http://www.lecciones-aprendidas.info/

102. 102Conferencia auspiciada por el PMI Antioquia Colombia Potential Chapter – La propiedad intelectual de esta pertenece al facilitador
Anexos

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
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
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
Información de contacto
 Jorge Hernán Abad Londoño
–jorge.abad@gmail.com
–@jorge_abad

107. 107
Bonus track

108. 108