Каковы ключевые ключевые моменты при регистрации технического долга?

Question

Я создаю журнал технического долга в The Office и хочу сделать его довольно всеобъемлющим инструментом.

Каковы основные сведения, которые мы должны записывать?

Answer 1

Прежде всего - вы хотите зарегистрируйтесь очень просто, иначе накладные расходы на ведение реестра не позволят людям использовать его и тратят больше времени, чем на самом деле фиксируют технический долг, который он должен был решить ... ..

Если вы все-таки решили идти вперед, я бы предложил сохранить простой регистр, который представляет собой плоский файл/простая база данных/Google таблицу со следующими полями:

• имя модуля/компонентой
• Описание того, что n (у вас может быть список категорий, но я думаю, что для этого также нужен текстовый однострочный)
• Расчетное время исправления в днях (я был бы склонен настаивать на целых днях, иначе люди будут иметь тенденция начать запись тривиальным мелкие вещи)
• Какой разработчик понесены задолженности (и при условии, что оценка времени FIX)
• Какой проект долга были понесены на (любой косвенно, что руководитель проекта подотчетен)

Правила следующие:

• Ожидается, что разработчики будут прозрачными в отношении технического долга. Если разработчику необходимо понести технический долг из-за проектного давления, разработчик должен добавить его в журнал с указанием времени их исправления.
• Менеджеры проектов несут ответственность за технический долг, который они набирают (то есть они оказывают давление на разработчиков, чтобы использовать ярлыки?). Они должны быть в состоянии обосновать обоснованное обоснование бизнеса для общей суммы долга и предложить, что нужно сделать, чтобы исправить это.
• Если техническая задолженность не указана, тогда код, как ожидается, будет высокого качества и будет проходить любые соответствующие обзоры кода. Если технический долг отмечается, то разработчик получает «пропуск» за все, что было отмечено (в обзоре вместо этого можно с уверенностью рассмотреть вопрос о правильности регистрации долга и идеи о том, что следует сделать для исправления).
• Ожидается, что разработчики дадут справедливую оценку времени исправления. Если они скажут, что для реструктуризации архитектуры потребуется два дня, то они не должны удивляться, если им дадут два дня, чтобы исправить ее позже ...

Я думаю, что этот подход создаст хорошая динамика в целом - разработчики должны быть прозрачными и думать о том, как решить технический долг, руководители проектов/бизнес-лидеры должны сделать компромиссы, но ясно, что ответственность за долги несет их ответственность, лучшие разработчики и архитекторы получат престиж для завершения сложных проектов, а также под контролем технического долга.