У команды разработчиков всегда есть субъективное ощущение техдолга, а значит есть и реальный DoD. И этот интуитивный DoD, который, будучи не прозрачным, создает непонимание и проблемы в отношениях в команде. В итоге снижает доверие из-за чего в свою очередь падает эффективность процесса.

Из-за непрозрачного состояния продукта разработчики всё время демотивированы legacy кодом, плохими архитектурными решениями, давлением со стороны заказчика и его нежеланием выделить время на решение технических проблем. Из-за непрозрачного состояния продукта заказчик недоволен багами на проде, абсолютно неадекватными (с его точки зрения!) оценками по сложности реализации даже самых простых и маленьких фич и нежеланием команды решать проблемы бизнеса.

Ну ладно, давайте уже сделаем его прозрачным и начнем делать всё правильно. И вот мы воодушевленные создаем наш новый DoD, заносим туда все свои самые лучшие представления о том, как надо правильно разрабатывать. Под конец митинга заказчик полон надежд: наконец-то разработчики начнут решать его проблемы. Разработчики тоже полный надежд: наконец-то бизнес даст нам время на решение технических проблем.

Но! Под конец митинга SM предлагает оценить, насколько текущий продукт не соответствует новому DoD и соответственно предлагает ликвидировать технический долг. Все в шоке. Зачем нужно пересматривать техническое состояние всего продукта? Неужели нельзя просто применять DoD для всех новых фич, а на техдолг забить?

Допустим, что можно. Что тогда? Заказчик подумает, что раз мы, например, начали писать автотесты, то качество и скорость (а точнее - сложность!) разработки изменятся везде одинаково. Однако, если мы при этом не ликвидируем образовавшийся техдолг - отсутствие покрытия автотестами текущего функционала в проде - то качество и скорость (сложность разработки) изменятся только в тех фичах, которые разработаны ПОСЛЕ принятия нового DoD. При попытке сделать инкремент с изменением старых фич (т.н. legacy код) заказчик будет неприятно удивлен либо плохим качеством (одно написали - другое отвалилось из-за отсутствия покрытия), либо неадекватно высокой сложностью (маленькое изменение потребует покрыть весь затрагиваемый функционал). В итоге либо DoD не выполняется (заказчик давит), либо разработка останавливается из-за нежелания заказчика платить за то, что он не понимает.

Ушат холодной воды - DoD обеспечивает прозрачность продукта (инкремента), а не процесса разработки! Такова реальность. Никто не хочет отдавать долги. Все хотят, чтобы кто-то другой решил их проблемы. И поняв это, все хотят закрыть глаза на неприятную правду - пусть у нас будет красивый DoD. В этом случае все могут свалить ответственность за нерабочий, но красивый DoD, на скрам-мастера, который принес скрам, который на самом деле карго культ, и не работает. Но мы должны выбрать. Нам шашечки или ехать? Мы хотим решать проблемы, или прятать их под коврик?

Возможные варианты действий:

  1. Немедленно инвестировать в ликвидацию техдолга. Поставить себе цель, набить бэклог с техдолгом и быстро всё расчистить. Плюсы: быстрое облегчение, быстрый результат, все счастливы. Минусы: необходимость ставить разработку бизнес-фич на полную остановку на длительное время (обычно неприемлемо для бизнеса).
  2. Запланировать ликвидацию техдолга. Поставить себе цель, набить бэклог с техдолгом и отдавать его параллельно с разработкой бизнес фич. Плюсы: проблемы с техдолгом решаются, бизнес-фичи пилятся. Минусы: скорость разработки резко снижается и будет повышаться медленно по мере ликвидации техдолга, необходимость параллельно менеджерить бэклог с техдолгом, ощутимый результат появится не быстро.
  3. Договориться отдавать долги в процессе. Не ставить цель, но договориться отдавать техдолг всегда при запиле фич. Это становится одним из пунктов DoD - техдолг по всему затронутому функционалу отдан. Чтобы снизить боль, можно запланировать усиление DoD, начиная с самых ценных изменений (где максимум пользы за минимум усилий). Плюсы: не надо менеджерить бэклог с техдолгом, остальные плюсы и минусы такие же как в п.2.
  4. Списывать техдолг. Терпеть техдолг при доработке старых фич, но все новые фичи писать с нуля уже в соответствии с новым DoD. Плюсы: не надо отдавать долги (это всегда приятно!). Минусы: очень разная скорость разработки для нового и старого функционала.

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

Но SM должен быть внимателен. Потому что ситуация может повториться. Ведь не зря же требования менялись настолько радикально! Вполне возможно, мы пытаемся искать подходящую идею продукта под рынок (или крупного клиента) и заказчик тешит себя надеждой на аджайл, который позволит ему сделать "гибкий" продукт, подходящий под любую ситуацию. И в итоге постоянных хаотичных изменений требований, архитектура похожа на кровавое месево - она отражает отсутствие изначальной целостной идеи продукта в голове заказчика. В этом случае нужно применять практики XP для архитектуры и соответственно включать это всё в DoD, чтобы иллюзии заказчика рассеялись и он увидел всю пагубность своего настроя.