Deuda técnica, con que se come.
19 may.¿Tiene un sistema complejo al que es difícil dar mantenimiento con poca documentación? Lo sentimos, pero usted tiene un problema de deuda técnica.
La deuda técnica es un déficit que se gana al tomar atajos en alguna de las fases del desarrollo de un producto (Documentación, Pruebas, Diseño, Análisis) lo que compromete la calidad final. La documentación poco descriptiva, el código que no se utiliza o el código redundante, son algunos ejemplos de deuda en un proyecto.
Todos los miembros del equipo deberán entender la diferencia entre algo que puede ser deuda técnica y mejoras estructurales que se deseen hacer al código, así como la nueva funcionalidad, ya que según el rol que una persona desempeñe puede clasificarse algo como deuda o no.
Pero ¿Qué causa que un proyecto tenga una deuda técnica desmedida?
- Cambios en el dominio de negocio.
- Presión para concluir el proyecto antes del plazo.
- Falta de conocimiento y escasez de buenas prácticas.
Los puntos anteriores son riesgos que se deben de tener presentes para evitar que se materialicen en forma de deuda técnica, trayendo consigo algunos de los siguientes problemas:
- Prolongación en el tiempo dado para desarrollar el producto.
- Falta de calidad en las funcionalidades existentes.
- Dificultad para dar mantenimiento.
La interrogante más grande es, cómo aminoramos o evitamos que estos riesgos no se materialicen o en caso de materializarse afecten lo menos posible al proceso.
¿Cómo atacamos la deuda?
Para mantener la deuda técnica a raya es importante realizar una gestión constante para mantenerla en niveles bajos, ya que al intentar suprimirse del todo terminaremos aplicando sobre ingeniería. Algunas técnicas para mantener la deuda son:
Implementación de metodologías ágiles
Al integrar metodologías como Scrum al desarrollo del producto, se incorpora el enfoque iterativo que ayuda a mantener la calidad versión tras versión, ya que cualquier problema que se presente se resolverá de manera inmediata para poder dar como terminada la funcionalidad.
Gracias a las reuniones diarias, la comunicación del equipo y la constante interacción con el cliente, promueven que se pueda validar cada detalle.
Pruebas automáticas
No hay mejor forma de controlar la calidad del producto que mediante pruebas automáticas, si queremos controlar un escenario escribimos una prueba automática y en caso de que pase algo de manera inmediata se resolverá.
Integración continua
Mediante esto podemos detectar errores por cambios de ambientes, generando confianza al hacer publicaciones, evitando que este tipo de detalles lleguen al cliente y al mismo tiempo ayuda a tener mayor visibilidad de lo que se está desarrollando.
Code review
Al revisarse el código fuente se evitan los errores y se aumenta la coherencia del mismo, se motiva a los programadores a documentar cada funcionalidad nueva que escriben, por lo que se comprometen con el proyecto.
Las prácticas mencionadas anteriormente son parte importante del proceso que lleva a cabo Consulting Group para el desarrollo de productos de calidad, relacionados en gran medida con las metodologías ágiles, la comunicación constante con las partes y la pronta respuesta como mecanismos base para ganar la batalla contra la deuda técnica.
Kevin Sandoval Loaiza | Web Designer | Ingeniero en Informática
