Запланированное ухудшение качества системы происходит, когда владелец продукта принимает на себя решение понизить качество системы, часто для увеличения скорости поставки.

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

Например, на прояснении бэклога команда оценила историю «Я как пользователь могу просмотреть видеофрагмент, чтобы принять решение о просмотре целиком». Разработчики оценили историю в 20, так как согласно DoD нужно всегда обеспечивать HD – качество видеопотока, что невозможно в сложившейся ситуации без существенных доработок. В этом случае владелец продукта разделяет историю на две (табл. 3.11).

Табл. 3.11. Пример планирования ухудшения качества в бэклоге

Первая история была реализована в необходимые сроки, вторая отложена для реализации в более удобное время. Такие отложенные доработки по восстановлению качества системы называются техническим долгом (technical debt, техдолг).

В данном случае техдолг был сформирован по инициативе владельца продукта, следовательно, он должен принять все присущие риски и ответственность по устранению.

Лучшие практики по работе с запланированным ухудшением качества

➠ Максимально стараться избегать образования и накопления техдолга.

➠ Если без этого невозможно, обязательно создавать связанную историю в бэклоге.

➠ Оперативно устранять известные запланированные ухудшения в системе.

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

➠ Выделить в бэклоге спринта определенный буфер под работы по устранению техдолга.