Блог Scrum.ru

10 мифов про DoD

Составил хит-парад распространенных заблуждений относительно определения готовности (Definition of Done, DoD). Многие из них могут показаться очевидными, но в этом обзоре я постарался рассмотреть различные случаи и вопросы, с которыми сталкивался в своей практике в качестве Скрам-мастера. Это поможет лучше понять, что такое DoD и как его можно применить в вашей команде.

Миф 1: DoD нужен для того чтобы понять готова ли фича

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

Миф 2: DoD - это список требований

Часто когда говорят про требования, то имеют в виду функциональные требования. Однако, нужно понимать что бывают требования нескольких типов: функциональные и нефункциональные по продукту, требования по качеству продукта, в некоторых организациях бывают даже требования по процессу разработки. Если мы говорим о функциональных требованиях, то им не место в DoD - они содержатся в описании элементов бэклога продукта. Нефункциональные требования действительно могут быть частью DoD, однако помимо них в DoD могут быть командные договоренности, например рефакторинг или пройденный code review. Я бы сказал что в DoD содержатся требования по обеспечению оговоренного уровня качества продукта. Для действительно кросс-функциональной команды это могут быть требования по выходу инкремента продукта в релиз и даже действия, которые совершаются после релиза (например, уведомление пользователей и поддержки, сбор метрик).

Миф 3: DoD - это критерии приёмки

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

Миф 4: DoD - это определение успешности разработки фичи

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

Миф 5: DoD нельзя изменять

Еще один миф. DoD - это способ обеспечения качества продукта, и это "живой" элемент, если вы видите что для обеспечения еще большего качества вам нужно что-то добавить в DoD, сделайте это. Например, вместо code review вы решили вести разработку в паре. Тем более что в Скраме у вас для этого есть специальное место для этого - Ретроспектива Спринта.

Миф 6: DoD - это что-то разработческое, на бизнес не влияет

В Скраме нет разделения на бизнес и разработку. Есть Скрам-команда, в которой есть представитель бизнеса - Product Owner и разработчики (в широком смысле слова, все кто создают продукт). DoD - это общее соглашение в команде по обеспечению оговоренного уровня качества продукта, было бы странно, если эта договоренность касалась лишь части команды.

Миф 7: DoD - необязательный элемент

По мнению Кена Швабера, одного из создателей Скрама, если свести фреймворк к одному элементу то это был бы готовый инкремент. В этом случае определение готовности становится вторым по значимости элементом фреймворка. Определение готового помогает Скрам-команде обеспечивать цикл эмпирического процесса по продукту, обеспечивая прозрачность по состоянию продукта, его готовность к релизу для пользователей. В целом, этот элемент появился в фреймворке когда Кен обратил внимание что часто разные участники процесса разработки продукта по-разному понимают что значит завершенная работа.

Миф 8: Большой DoD замедляет разработку

Смотря в какой перспективе мы рассматриваем разработку. Представим что команда изначально создавала продукт и проводила тестирование вручную. Со временем и ростом объема функциональности ручное тестирование будет занимать всё больше времени и команда принимает решение об автоматизации тестирования. Может сложится впечатление, что это увеличивает общее время разработки. Однако, если в начале и возможна просадка по времени - ведь нужно написать отсутствующие тесты и в целом обучиться этому навыку, но со временем команда будет экономить время за счёт более быстрого и более надёжного тестирования и команда сможет быстрее обнаруживать и исправлять дефекты. То есть в долгосрочной перспективе команда получит экономию по времени.

Миф 9: Разные задачи могут иметь разный DoD

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

Миф 10: DoD используется в одной отдельной команде

DoD прикладывается к продукту, а не к команде. Если над продуктом работает более одной команды, то у них должно быть общее определение готового инкремента. Это очень полезно и практично особенно, если у команд общая кодовая база - вы можете поместить в DoD ваши соглашения по стандартам написания кода, тестов и т.д. В то же время, у каждой команды может быть отдельные применимые только у них команде пункты, которые расширяют общий DoD. Они ни в коем случае они не должны снижать качество продукта. Например, в общем DoD может быть пункт про наличие проходящих unit-тестов. А в одной из команд может быть соглашение, что все unit-тесты пишутся до кода, по TDD.
Хотите глубже разобраться в Скраме и получить опыт работы в настоящей профессиональной Скрам-команды? Тогда приглашаем вас на наш ближайший тренинг Applying Professional Scrum (APS-SD) в ноябре, свободные места ещё есть.
Scrum Инженерные практики Сергей