¿Administra activamente la deuda técnica?

Question

¿Gestiona activamente la deuda technical debt en sus proyectos de desarrollo de software y, de ser así, cómo lo hace?

Answer 1

En nuestros equipos administramos activamente la deuda técnica. Hacemos Scrum, por lo que generamos una tarjeta de deuda técnica, ya sea para la iteración actual o la siguiente iteración, dependiendo de la estimación y de nuestra capacidad de sprint restante, y obtienen prioridad al igual que las características y las tarjetas de error. También administramos elementos de deuda más grandes entre equipos al tener una cartera de deudas técnica cruzada entre equipos que priorizamos e inyectamos en cada equipo de Scrum durante su planificación de sprints.

Answer 2

Un aspecto de la gestión de la deuda técnica es convencer a los gerentes no técnicos de que necesita tiempo para refactorizar y corregir errores.

Here's an article with specific suggestions sobre cómo hacerlo.

Answer 3

Creo que es importante programar el tiempo para pagar la deuda técnica si está tratando de compensar los pecados antiguos, pero también creo que no debe hacer de esto un hábito. Una vez que hayas limpiado el desastre, deberías evitar que tu proyecto se endeude más, a menos que tengas buenas razones para hacerlo.

Activamente manejarlo como Mike sugiere parece ser el enfoque más razonable, pero creo que es muy importante dejar en claro (a su equipo) que no debe programar tiempo o planificar la refacturación a largo plazo.

refactorización debe ser una parte natural de la escritura de código, y por lo tanto se debe incluir en sus otras estimaciones y planes, y no deben tratarse como una actividad separada — menos que sea necesario, es decir, por razones "históricas" o porque conscientemente decidió implementar algo de una manera determinada y luego volver a implementarlo más tarde.

Answer 4

Depende mucho del producto. Cuando trabajé en un campo donde nuestro código tenía que ser auditado desde el exterior, fue una parte planificada de nuestro sprint. PM acaba de preguntarle al departamento de desarrollo qué área era necesaria para la refactorización y se incluyó en el plan. Eso no quiere decir que no arreglarías el código en el área en la que estabas trabajando, pero no dedicarás un día a reescribir un pedazo de código destrozado que funcionó. Ahora estoy trabajando en scrum y los desarrolladores solo lo hacen mientras trabajan. Mi impresión es que aproximadamente la misma cantidad de tiempo se dedica al trabajo de refactorización, de cualquier manera.

Answer 5

Lo que usted hace es crear una cultura donde la deuda técnica no es aceptable a menos que en casos extremos. Muy parecido a las personas que solo pagan en efectivo y usan el crédito solo como último recurso absoluto.

Answer 6

Estoy de acuerdo con Anders. Si tiene que configurar sistemas para administrar la deuda técnica, eso significa que aún la está agregando. Deje de endeudarse, en primer lugar, actualizando su definición de "hecho".

Esto significa que los módulos "endeudados" serán más difíciles de procesar. Los desarrolladores deben ser conscientes de esto y asignar más puntos a la historia para que dejen las cosas "hechas" a su paso.

Answer 7

Si llega tarde al ciclo de publicación, no desea cambiar demasiado la base de códigos. Esto significa que siempre habrá una deuda técnica. Yo suelo escribir ARREGLAME: s para los cambios que son subóptimas y luego hacerse cargo de ellos antes de empezar a implementar características de la próxima versión.

Answer 8

Java Posse han cubierto la gestión de Technical Debt recientemente que parece muy amplia.

Answer 9

Si realmente necesito a acumularse deuda técnica, porque tengo que lanzar algo ahora, abra una incidencia fundamental en ello, por lo que obtiene la más alta prioridad.Pero es solo para situaciones extremas (el cliente está saltando de arriba abajo, la esposa está buscando un dingbat, etc.).

Answer 10

En los proyectos en los que he participado hasta ahora, algunas deudas técnicas han sido "pagadas" (administradas) solo al comienzo de nuevas fases de los proyectos, es decir, después de "grandes lanzamientos" o hitos.

Un aspecto muy importante sobre la deuda técnica es que no solo involucra a los desarrolladores, sino también a la gerencia. En ese sentido, soy consciente de que la mejor manera de enfrentarlo es hacer que sea visible para los "interesados ​​en proyectos no técnicos" que podrían asignar tiempo y recursos para gestionar la deuda técnica una vez que comprendan sus implicaciones.

Este article analiza varios tipos de deuda técnica, cuáles pueden ser saludables, y especialmente cómo gestionar y rastrear la carga de la deuda técnica.