2021-10-04 09:00:16
О концепции технического долга знают многие. В некоторых командах даже имеют специальный технический бэклог для сбора и управления техническим долгом. Но очень важно систематизировать подход к его идентификации, иначе может создаться ложная иллюзия контроля. Итак, какие есть источники технического долга?
1. Самым важным являются технические риски и компромиссы архитектурного решения, которые сознательно делаются командой для ускорения разработки или из-за текущего контекста. По ним лучше сразу заводить задачи и приоритизировать.
2. Вторым популярным источником являются замечания с ревью кода, на исправление которых прямо сейчас нет времени и они не являются критичными. Правила и критерии таких решений лучше заранее обсудить и прописать в процедуре ревью. При создании задач в техническом бэклоге нужно не забыть привязать к изначальной задаче и исходному PR в git. Ещё дополнительно отлично работают todo в коде со ссылкой на техническую задачу.
3. Следующим источником являются проблемы, найденные в существующем коде во время выполнения другой задачи. Не стоит бросаться их исправлять прямо сейчас. Лучше создать техническую задачку и оставить todo в коде с ее номером. А уже дальше действовать по приоритетам.
4. Последним важным источником является изменение командного Definition of Done или coding conventions. Например, добавление обязательной документации или изменение подхода к покрытию сервиса тестами. Очевидно, что существующий код сам себя не приведёт в соответствие с новыми правилами. Поэтому лучше завести задачки в технический бэклог для визуализации текущей ситуации.
Баланс между скоростью разработки и инженерным дзеном всегда индивидуален для каждого продукта, проекта и команды. Но для принятия верных решений очень полезно четко понимать текущую картину. А в этом очень помогает актуальный приоритезированный технический бэклог.
2.2K views06:00
X
