Scrum enfatiza que todos los miembros del equipo deben conocer la deuda técnica del producto. Pero a veces, esta deuda no es tangible como una simple lista de tareas pendientes. ¿Deberíamos registrarlo como una tarea más en la cartera de productos para revisar en otro sprint? ¿O deberíamos ponerlo en algún documento relacionado con este producto, para que el equipo pueda saber qué tareas deben tratarse más adelante en el desarrollo?
No veo una buena manera de mantener esta deuda en la mente de los desarrolladores; se puede olvidar más tarde.
Como regla general, la deuda técnica aumenta el costo del trabajo futuro en el producto. Por lo tanto, incluso si no realiza un seguimiento explícito de la deuda, generalmente se mostrará como un lastre en las métricas, como la velocidad del equipo a lo largo del tiempo.
La deuda técnica probablemente también afectará las estimaciones de elementos de la cartera de productos (PBI) de su equipo durante la planificación de Sprint, ya que el código crudo (y los productos cargados de deuda en general) son intuitivamente de mayor esfuerzo.
Aunque Scrum expone implícitamente la deuda técnica a través de la velocidad y también la refleja dentro de las estimaciones de PBI, a menudo es mejor rastrear la deuda explícitamente en el Product Backlog. Algunas razones para hacer esto incluyen:
Si trata la deuda técnica simplemente como un trabajo que debe priorizarse, a diferencia de algún tipo especial de trabajo que no es trabajo, entonces la Lista de Producto es sin duda el lugar adecuado para ello.
Crea PBIs para la deuda técnica de la misma forma que lo harías para cualquier otro tipo de obra. Los PBI deben escribirse en cualquier nivel de granularidad que sea apropiado para el nivel de priorización del trabajo dentro de la acumulación.
Por ejemplo, puede conservar algunas refactorizaciones valiosas pero no esenciales como una epopeya para "algún día". Por el contrario, los parches esenciales o las reelaboraciones deben escribirse como historias de usuario individuales cuando el equipo está listo para descomponer el trabajo durante la planificación del Sprint, o durante el refinamiento del backlog cuando es probable que el trabajo esté dentro del alcance de un próximo Sprint.
La respuesta estándar de Scrum sería preguntarle al equipo qué piensan. Se supone que los Equipos Scrum se organizan a sí mismos, lo que significa que pueden elegir la mejor manera de completar su trabajo. El equipo debe poder identificar la gestión de la deuda técnica como un problema y luego generar ideas.
Sin embargo, en el mundo real, a veces, es posible que el equipo no tenga la experiencia o los conocimientos necesarios para detectar estos problemas antes de que sea demasiado tarde. Un buen entrenamiento de alguien que haya experimentado estos problemas antes puede ayudar a guiar al equipo a hacer las preguntas correctas y pensar en ciertos problemas antes de que se conviertan en problemas.
No tendría objeciones si el equipo quisiera mantener el trabajo de la deuda técnica rastreado en el Product Backlog. Creo que esto es probablemente lo correcto: se puede revisar con el resto de la cartera de productos. Si hay dependencias entre la deuda técnica y las funciones (como resolver la deuda técnica daría lugar a que se entregue una función de mayor calidad en menos tiempo), el propietario del producto y el equipo de desarrollo pueden identificarlas y gestionarlas.
Sí, la deuda técnica, al final del día, terminará en su sistema de seguimiento de tareas de una forma u otra.
Una manera obvia:
Además, con el tiempo, suele ser bastante obvio para los miembros del equipo, incluso en la fase de planificación, dónde está la deuda real. Claro, hay algunas deudas insidiosas que aumentan muy lentamente, pero algunas cosas son bastante obvias. Estos, también, deberían terminar en la cartera de pedidos.
Finalmente, puede realizar una gestión proactiva de la deuda, por ejemplo, asegurándose regularmente de que todos los componentes de terceros se actualicen regularmente; que los componentes obsoletos (que no tienen nuevas versiones durante X meses/años) se eliminen gradualmente, y tal. Todo esto, de nuevo, son simplemente más entradas atrasadas marcadas como "deuda técnica".
¿Deberíamos registrarlo como una tarea más en la cartera de productos para revisar en otro sprint? ¿O deberíamos ponerlo en algún documento relacionado con este producto, para que el equipo pueda saber qué tareas deben tratarse más adelante en el desarrollo?
Creo que en realidad debería tener un plan bien estructurado sobre cómo abordar la deuda técnica.
Encuentre métricas para captar la importancia de realizar estas tareas para el estado general del proyecto. Algunos ejemplos son:
Tomas Owens
Todd A. Jacobs