Прежде всего - вы хотите сделать свой реестр очень простым , в противном случае затраты на ведение реестра будут мешать людям использовать его и тратить больше времени, чем на фактическое исправление технического долга, который он должен был решить .....
Если вы все-таки решите пойти дальше, я бы посоветовал вести простой регистр, который представляет собой простой файл / простую базу данных / электронную таблицу Google со следующими полями:
- Имя модуля / компонента
- Описание того, что должно быть исправлено (у вас может быть список категорий, но я думаю, что для этого также нужен текст с одной строкой)
- Расчетное время исправления в днях (я был бы склонен настаивать на целых числах дней, иначе люди будут иметь тенденцию начинать регистрировать мелкие мелочи)
- Какой разработчик взял на себя долг (и предоставил оценку времени исправления)
- По какому проекту был получен долг (любой косвенно, какой руководитель проекта подотчетен)
Правила таковы:
- Разработчики, как ожидается, будут прозрачны в отношении технического долга. Если разработчик должен понести техническую задолженность из-за нагрузок на проект, разработчик должен добавить это в журнал со своим предполагаемым временем исправления.
- Руководители проектов несут ответственность за техническую задолженность, которая у них возникла (т. Е. Оказывали ли они давление на разработчиков, чтобы они использовали ярлыки?). Они должны быть в состоянии обосновать надежное деловое обоснование совокупного долга и предложить, что нужно сделать, чтобы его исправить.
- Если технической задолженности не отмечено, то ожидается, что код будет высокого качества и пройдет любые соответствующие проверки кода. Если отмечается техническая задолженность, то разработчик получает «пропуск» на все, что отмечено (вместо этого обзор мог бы полезно рассмотреть точность регистрации долга и идеи о том, что необходимо сделать для исправления).
- Ожидается, что разработчики дадут справедливые оценки для времени исправления. Если они скажут, что на рефакторинг архитектуры потребуется два дня, то они не должны удивляться, если им дадут два дня, чтобы исправить это позже ...
Я думаю, что этот подход в целом создаст хорошую динамику - разработчики обязаны быть прозрачными и думать о том, как решить техническую задолженность, руководители проектов / бизнес-лидеры должны делать компромиссы, но ясно, что затраты на их долг - лучшие разработчики и архитекторы получат похвалы за выполнение сложных проектов, а также за контроль технического долга.