Presentación – diapositiva “Deuda técnica”

2.1 Cuáles son los síntomas que determinan que un software está pasando por un proceso de deuda técnica.
2.2 Tipos de deuda técnica, explicar cada uno indicando un ejemplo de qué escenario es el que da apertura a
cada tipo.
2.3 Ejemplos de refactorización que abordan una solución a diferentes escenarios de deuda técnica.
De esta discusión Definición de lo que tomaremos en cuenta para darle un valor agregado al
proyecto No.1 de análisis II.

• Desde un principio se definió que se trabajara el proyecto en basa a Scrum, entonces bajo esta metodología se tiene
definido las funciones a desarrollar y por medio a las reuniones diarias definimos los avances y problemas que se tienen
para poder darles solución y avanzar con el proyecto de forma adecuada y con éxito.

• Implementar de algún modo una herramienta de análisis de Código que nos puede ayudar a categorizar las incidencias
que pueda detectar según el criterio.

• En algunas ocasiones no se garantiza tener un código al 100% de capacidad, sin embargo, buscar y aplicar con base a
metodologías y buenas prácticas de programación un desarrollo funcional.

• Documentar en caso haya un código mal escrito, sin intentar solucionarlo al instante, así se hace visible la deuda
técnica y no se altera el compromiso de nuestros sprints.

• Entender y comprender con exactitud qué es lo que requiere la funcionalidad, para así darle solución, con lo que se
evita a gran escala errores en el código y deudas técnicas en el desarrollo del software.