¿Qué pagos ha visto al cuidar la deuda técnica?

Question

Este Artículo sobre deuda técnica tiene algunos buenos puntos, incluyendo:

Trabajar en los "asuntos técnicos" funciona mejor cuando está impulsado por historias. La base del código probablemente necesite trabajo en todas partes, pero la recompensa se recibirá solo donde se trabajará el código por razones orientadas al usuario. Si no hay historias pasar por un área crugal, trabajar en ella se desperdicia en gran medida.

Por lo tanto, prefiero el enfoque de tomar historias como de costumbre (pero probablemente menos de ellas), y seguir la "regla de Boy Scout" de dejar el campamento mejor de lo que lo encontró. En otras palabras, donde sea que las historias nos guíen, escribamos más pruebas, refactoremos de manera más agresiva.

Este enfoque tiene al menos estas ventajas:

• mantiene un flujo de historias "mejor sensato";
• proporciona ayuda de todos los talentos del equipo;
• Proporciona todo el equipo para aprender cómo mantener el código limpio;
• enfoca la mejora exactamente donde se necesita;
• no desperdicia mejora para que se necesite "puede ser";

He visto que la calidad del código tiene un gran efecto en la productividad a largo plazo, por lo que creo que la deuda técnica debe ser atendida. Creo que la publicación anterior tiene sentido, pero no estoy tan seguro de los dos últimos puntos. Estoy interesado en encontrar experiencias reales de beneficios de la limpieza de la deuda técnica, incluso si no estaba relacionada con las historias de los usuarios.

¿Qué beneficios positivos ha visto al limpiar su base de código y deshacerse de la deuda técnica? ¿Qué métodos usaste para hacer el trabajo?