Embed Size (px)
Citation preview
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
3
Esta presentación contiene una compilación de diapositivas de:• Javier Garzas - @jgarzas• Ángel Nuñez - @snahider• Y algunas mías
4
Miembro de Ágiles Colombia
5
Miembro PMI Capítulo Antioquia
pmiantioquia.org @pmiantioquia facebook.com/PMIAntioquia meetup.com/es-ES/Proximo-Capitulo-PMI-Antioquia/
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
Indaguemos
8
¿Quién conoceel 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.
Wikipedia
10
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
15
Ejemplo
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?
CANCELADO
24
¿Y CÓMO LUCE?
25
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
O aun peor…
28
Ejemplos
29
Ejemplos
30
31
32
33
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 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
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
46
Efectos
Fuente: Henrik Kniberg - @henrikknigberg
48
51
Deuda técnica a ser pagada
57
Process DebtMethodology Debt
Fuente: Ángel Nuñez - @snahider
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
75
Como resolverla
76
Como resolverla
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, 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
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
92
Principios Ágileshttp://agilemanifesto.org/iso/es/principles.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.
[email protected]@jorge_abad
Blog http://www.lecciones-aprendidas.info/
102 Conferencia auspiciada por el PMI Antioquia Colombia Potential Chapter – La propiedad intelectual de esta pertenece al facilitador
Anexos
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
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: [email protected]
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
Información de contacto
Jorge Hernán Abad Londoño– [email protected] – @jorge_abad
Puede eliminar esta (o cualquier diapositiva), pero debe dar crédito de la fuente en algún lugar de su presentación. Utilizar el logotipo y el nombre de la empresa (como en la parte inferior izquierda, por ejemplo) o incluir una diapositiva en algún lugar diciendo que parte (o todo) de su presentación son de esta fuente. Gracias.
107
Bonus track
108
