Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
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.l...
2
3
Esta presentación contiene una compilación
de diapositivas de:
• Javier Garzas - @jgarzas
• Ángel Nuñez - @snahider
• Y ...
4
Miembro de Ágiles Colombia
5
Miembro PMI Capítulo Antioquia
 pmiantioquia.org
 @pmiantioquia
 facebook.com/PMIAntioquia
 meetup.com/es-ES/Proximo...
6
Mis objetivos con esta sesión:
- Elevar nuestro nivel de conciencia
sobre la deuda técnica
- Inquietarlos
- Ser disparad...
7
Indaguemos
8
¿Quién conoce
el concepto de
deuda técnica
9
La deuda técnica son
las consecuencias de un
desarrollo apresurado
de software o un
despliegue descuidado
de hardware.
W...
10
11
La deuda técnica son las consecuencias de:
• un desarrollo apresurado
• un desarrollo inconsciente de software
• o un d...
12
Fuente: Javier Garzas - @jgarzas
13
Fuente: Javier Garzas - @jgarzas
14
Fuente: Javier Garzas - @jgarzas
15
Ejemplo
16
Fuente: Javier Garzas - @jgarzas
17
¿Quienes han estado en
un proyecto que fue
cancelado debido a que
era más práctico iniciar
de cero que continuar
trabaj...
18
Fuente: Javier Garzas - @jgarzas
19
Fuente: Javier Garzas - @jgarzas
20
Fuente: Javier Garzas - @jgarzas
21
Fuente: Javier Garzas - @jgarzas
22
Fuente: Javier Garzas - @jgarzas
23Fuente: Javier Garzas - @jgarzas
24
¿Y CÓMO LUCE?
25
26
Nuestro servidor agotado por :
• La carga
• Necesita continuos reinicios
• Carecemos de
• buen hardware
• Software livi...
27
O aun peor…
28
Ejemplos
29
Ejemplos
30
31
32
33
34
Fuente: Javier Garzas - @jgarzas
35
Fuente: Javier Garzas - @jgarzas
36Fuente: Javier Garzas - @jgarzas
37
Algo tan inexplicable como esto
38
39
40
41
¿Algún ejemplo más?
42
Causas
 Presiones de Negocio
 Poco entendimiento del proceso
 Software no modular, clases muy acopladas
 Falta de u...
43
44
Síntomas
 Despliegue lentos
 Constantes reinicios del servidor por consumo de
memoria
 Código inmantenible
 Código ...
45
Fuente: Ángel Nuñez - @snahider
46
Efectos
Fuente: Henrik Kniberg - @henrikknigberg
47
Fuente: Javier Garzas - @jgarzas
48
49
Fuente: Ángel Nuñez - @snahider
50
Fuente: Ángel Nuñez - @snahider
51
Deuda técnica a ser pagada
52
Fuente: Javier Garzas - @jgarzas
53
Fuente: Javier Garzas - @jgarzas
54
Fuente: Ángel Nuñez - @snahider
55
Fuente: Ángel Nuñez - @snahider
56
Fuente: Ángel Nuñez - @snahider
57
Process Debt
Methodology Debt
Fuente: Ángel Nuñez - @snahider
58
Fuente: Ángel Nuñez - @snahider
59
Fuente: Javier Garzas - @jgarzas
60
Fuente: Javier Garzas - @jgarzas
61
Fuente: Javier Garzas - @jgarzas
62
Fuente: Javier Garzas - @jgarzas
63Fuente: Javier Garzas - @jgarzas
64
Fuente: Javier Garzas - @jgarzas
65
Fuente: Javier Garzas - @jgarzas
66
Fuente: Ángel Nuñez - @snahider
67
Fuente: Ángel Nuñez - @snahider
68
Fuente: Ángel Nuñez - @snahider
69
Fuente: Ángel Nuñez - @snahider
70
Fuente: Ángel Nuñez - @snahider
71
Fuente: Ángel Nuñez - @snahider
72
Prácticas Técnicas compartidas por todo el
equipo
• Revisiones de código
• Buenas practicas de desarrollo (Principios S...
73
Fuente: Ángel Nuñez - @snahider
74
Fuente: Ángel Nuñez - @snahider
75
Como resolverla
76
Como resolverla
77
Fuente: Ángel Nuñez - @snahider
78
79
Y… ¿Testing?
80
81
82
83
84
¡Todo esto cambió!
85
86
¿Qué podemos hacer desde pruebas?
 Ser preventivos
 Estar atentos a los síntomas
 Realizar inspecciones de código, b...
87
Cambios de paradigmas
88
Y los otros roles de Scrum
¿Qué?
89
El/la Product Owner
• Priorizará dentro
del backlog la
remoción de la
deuda técnica cada
Sprint
90
El/la Scrum Master
• Monitoreará la Deuda
Técnica
• Y seguirá velando por su
excelencia técnica
91
Fuente: Ángel Nuñez - @snahider
92
Principios Ágiles
http://agilemanifesto.org/iso/es/prin
ciples.html
93
94
Por último…
No trates de remover la deuda
técnica de la siguiente forma
95
96
No esperes a que la deuda de
tu software no pueda ser
pagada, comienza a
gestionarla
97
98
¿Logré mi
propósito?
Espero que si…
99
PREGUNTAS
100
101
¡GRACIAS!
Jorge H. Abad L.
jorge.abad@gmail.com
@jorge_abad
Blog http://www.lecciones-aprendidas.info/
102Conferencia auspiciada por el PMI Antioquia Colombia Potential Chapter – La propiedad intelectual de esta pertenece al ...
103
Fuentes y referencias
 http://es.slideshare.net/JavierGarzas/deuda-tecnica-slideshare
 http://es.slideshare.net/snah...
104
Estas presentación contiene algunas diapositivas de
 Javier Garzas @jgarzas
 Ángel Nuñez @snahider
 Henrik Kniberg ...
105
Aviso de Copyright
 Usted es libre de:
– Compartir- copiar, distribuir y trasmitir el trabajo
– Modificar- adaptar el...
106
Información de contacto
 Jorge Hernán Abad Londoño
–jorge.abad@gmail.com
–@jorge_abad
107
Bonus track
108
Próxima SlideShare
Cargando en…5
×

Hablemos de Deuda Técnica

1.961 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

×