project management - tecnica - ¿Administra activamente la deuda técnica?
technical debt agile que es (10)
Creo que es importante programar el tiempo para pagar la deuda técnica si estás tratando de compensar los pecados antiguos, pero también creo que no debes 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.
Manejarlo de manera activa como sugiere Mike 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.
La refactorización debe ser una parte natural de la escritura del código y, por lo tanto, debe incluirse en sus otras estimaciones y planes, y no debe tratarse como una actividad separada, a menos que sea necesario, es decir, por razones "históricas" o porque haya decidido implementar algo conscientemente. de una manera determinada y luego volver a implementarlo más tarde.
¿Gestiona activamente la deuda de deuda técnica en sus proyectos de desarrollo de software y, de ser así, cómo lo hace?
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.
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.
Aquí hay un artículo con sugerencias específicas sobre cómo hacer eso.
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, en cualquier caso.
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.
Lo que debes hacer es crear una cultura en la que la deuda técnica no sea aceptable a menos que sea en casos extremos. Muy parecido a las personas que solo pagan en efectivo y usan el crédito solo como último recurso absoluto.
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. Normalmente escribo FIXME: s para los cambios que son subóptimos y luego me ocupo de ellos antes de comenzar a implementar las características para la próxima versión.
Java Posse ha cubierto la gestión de Deuda técnica recientemente, que parece muy completa.
Si realmente necesito acumular deuda técnica, porque necesito liberar algo AHORA, presento un error crítico al respecto, por lo que se le da 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.).
En los proyectos en los que he estado involucrado hasta ahora, algunas deudas técnicas han sido "pagadas" (administradas) solo al comienzo de las 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 artículo analiza varios tipos de deuda técnica, cuáles podrían ser saludables y, especialmente, cómo administrar y rastrear la carga técnica de la deuda.