Definition of Done. Что это за знаменитый список?

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

Итак, речь пойдет о Definition of Done в контексте разработки ПО, а также о требованиях и стандартах завершения задач.

Что такое Definition of Done (DoD) и критерии готовности?

Definition of Done — это список критериев, которым должна соответствовать каждая задача команды, чтобы считаться выполненной.

Другими словами, это общие для всех задач команды критерии приёмки задачи (Acceptance criteria, AC) — набор условий и требований, необходимых для успешного завершения задачи или user story.

Definition of Done (DoD) и его собрат Definition of Ready (DoR) — составные части методологии Scrum. Методология применяется для организации труда в разработке программного обеспечения.

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

Оттого работа и разделена на задачи; уже упомянутая нами задача команды в Scrum называется User Story — это короткое описание потребности пользователя, связанное с этапами планирования и проверки. На русском языке user story ожидаемо звучит "пользовательская история".

Задачи user story состоят из различных элементов, которые должны соответствовать критериям готовности.

При чем тут Definition of Ready?

Часто DoD в русскоязычной практике употребляется как «критерии готовности» или «определение готовности». Однако это не совсем корректно, ведь такой перевод конфликтует с понятием Definition of Ready. Но более корректный перевод термина Definition of Done, используемый в русскоязычной среде, — определение выполненности.

Кстати, важно, чтобы DoD создавала команда разработки. Это добавит ей чувства ответственности за свой труд. Если такой возможности нет, то по крайней мере согласуйте с ней, что включается в выполненную работу. И еще: команды должны не только формально согласовывать DoD, но и реально следовать ему в своей работе (не удивляйтесь, но иногда критерии выполненности игнорируются частично или полностью).

История Definition of Done

Времена до появления понятия

Definition of Done упоминается куда чаще, чем его собрат Definition of Ready (DoR). История его путешествий по страницам литературы достаточно забавна [1]. Можно сказать, что сначала словосочетание в книгах о программировании появилось в очень прямолинейной форме. Есть в языке ассемблера компьютера PDP-11 [2] символ DONE, у него есть несколько значений. Нужно выяснить текущее определение, так называемый Definition of DONE [3].

Одно из первых появлений в интересном для нас смысле неожиданно оказывается в книге о преодолении посттравматического стрессового расстройства ветераном войны во Вьетнаме [4]:

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

Здесь речь идёт о возвращении ветерана к мирной жизни. Не в смысле физического его возвращения домой, а в смысле обретения спокойствия в мирной деятельности. Общее у этого отрывка и у определения выполненности состоит в том, что и командам, строящим процесс по Scrum, необходимо самостоятельно определить для себя, что такое выполненная задача, какие условия должны быть выполнены для признания задачи завершённой и где находится граница конца работы. Также важно учитывать, что критерии могут быть индивидуальными для каждого элемента и требования должны формулироваться к конкретному элементу работы (инкременту).

Первые упоминания DoD

Конец 1990-х и начало 2000-х годов — время бурного появления различных гибких подходов к разработке ПО. Оттуда вырос Scrum, но помимо него было и множество других: Extreme Programming, Lean, Crystal. Во время подготовки этой статьи я узнал и о ещё одной концепции: QRPD, Quality Rapid Product Development. Судьба этого процесса и некоторых других процессов схожа — они затерялись на страницах истории. Однако именно в книге об этом методе разработки я нашёл первое упоминание Definition of Done в качестве единого термина в нашей области [5]. В этих методологиях DoD применяется для оценки готовности инкремента продукта, что позволяет определить завершённость работы на каждом этапе жизненного цикла.

К слову, автор книги и подхода, Орион Моше Копельман, переехал на остров Мауи [6] и предложил свою кандидатуру в качестве мэра острова [7]. Вот такой поворот.

Первое упоминание термина в книге одного из авторов Scrum случилось в 2004 году [8]. Само упоминание не выглядит как презентация понятия, а происходит походя. С другой стороны, Scrum Guide, который можно считать «инструкцией к Scrum» уже с первой своей версии содержит особый раздел Done [9]. Там и описывается термин, где определение выполненности связано с завершением спринта и формированием инкремента.

Definition of Done на практике

Вот как выглядит определение выполненности в наиболее свежей версии Scrum Guide [10]:

Определение выполненности* — это формальное описание состояния Increment**, при котором он соответствует требованиям качества, предъявляемым продукту.

В случае с Definition of Done авторы подхода Scrum не предлагают каких-либо готовых решений, как это было с Definition of Ready. Они пишут, что если какое-либо определение выполненности существует в стандартах организации, то нужно воспользоваться им как базисом. Если такого определения нет, то команда должна выработать своё. При этом важно, чтобы соответствие кода всем критериям было обязательным для завершения задачи и передачи результата.

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

Для упомянутой переменной части даже существует специальное понятие — условия удовлетворённости (Conditions of satisfaction). Эти условия описывают уже не столько взгляд разработчика, сколько предполагаемую бизнес-ценность.

В индустрии ПО любят изобретать, и вопросы управления тоже попадают под эту любовь. Можно заметить, что определение выполненности достаточно сильно походит на используемые в других местах критерии приёмки. Можно, конечно, учесть особенности и назвать их «критериями самоприёмки». Ведь это же сама команда решает, соответствует ли получившийся результат существующим требованиям. Однако при внедрении DoD могут возникать проблемы, связанные с недостаточным пониманием или применением критериев выполненности, что влияет на качество кода и эффективность работы команды.

Распространенные ошибки при работе с Definition of Done

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

1. Слишком общий или размытый DoD
Одна из самых частых проблем — определение выполненности формулируется слишком абстрактно. Например, «код написан» или «функция работает». Такие формулировки не дают команде чёткого понимания, что именно считается завершённой работой, и не обеспечивают нужного уровня качества продукта. В результате возникают разночтения, а продукт может не соответствовать ожиданиям клиента.

Рекомендация: Старайтесь делать список Definition of Done максимально конкретным и измеримым. Включайте в него чёткие критерии качества, тестирования, code review, обновления документации, дополняйте другими важными элементами.

2. Игнорирование DoD в повседневной работе
Бывает, что команда формально создала список критериев готовности, но в реальной работе не сверяется с ним. Яркий пример такой ошибки — задачи закрываются без проверки всех пунктов definition of done, что приводит к накоплению технического долга и снижению качества инкрементов.

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

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

Рекомендация: Разделяйте критерии на общие для всех задач и специфические для определённых типов работы. Это повысит гибкость и релевантность Definition of Done для каждого элемента продукта.

4. Недостаточное вовлечение команды в формирование DoD
Если Definition of Done навязан сверху или составлен без участия всей команды, разработчики могут не чувствовать ответственности за его выполнение. Это снижает мотивацию и приводит к формальному подходу к выполнению критериев.

Рекомендация: Обсуждайте и пересматривайте DoD вместе с командой. Совместное определение критериев приёмки и качества способствует лучшему пониманию и принятию стандартов работы.

5. Забытые или устаревшие критерии
С течением времени продукт и процессы меняются, а Definition of Done может устареть. Если не обновлять DoD, он перестаёт отражать реальные требования к качеству и процессу разработки.

Рекомендация: Регулярно пересматривайте и актуализируйте DoD, особенно после ретроспектив или изменений в проекте. Это поможет поддерживать высокие стандарты качества и соответствовать ожиданиям клиентов.

Избегая этих распространённых ошибок, команда сможет использовать Definition of Done как надёжный инструмент для повышения прозрачности, качества и предсказуемости результата. Помните: чёткое и актуальное определение выполненности — залог успешной работы над продуктом и довольных клиентов.

Заключение

Определение выполненности — это стабильный список критериев приемки, которому должен соответствовать каждый результат работы команды. Часто бывает удобно, когда список принимает форму чек-листа. Перед завершением задачи команда проходится по его пунктам и отмечает удовлетворённые требования к качеству. Информация, собранная в процессе работы, помогает объективно оценить готовность результата. Если результат, то есть код и программный продукт, соответствует всем критериям, то ура, работа сделана. А если нет, то она отправляется на доработку.

*Для сохранения единообразия понятий слово «готовность» из оригинального перевода заменено на «выполненность». Такой термин используется в книге Scrum [11]. «Готовность» применяется для Definition of Ready, понятия из предыдущей статьи».

** Вероятно, переводчики Scrum Guide хотели оставить единство терминологии как для англоязычной, так и для русскоязычной версии и не стали переводить Increment. Хотя в русском языке иногда и встречается использование «инкремента».

Было интересно получить понимание, что имеет в виду разработчик или менеджер, когда говорит об определении готовности задач, продуктов или проектов? Подписывайтесь на блог «Итак, список», в мире ещё много удивительных списков и чек-листов, посмотрите на живые и значимые примеры. А ещё узнаете, как решить многие вопросы этими простыми, но очень мощными инструментами.

Список ссылок

[1] Результаты поиска "definition of done" в Internet Archive
[2] PDP-11 из «Википедии»
[3] Thomas S. Frank, Introduction to the PDP-11 and its assembly language, ISBN 0-13-491704-9
[4] Ron Zaczek, “Farewell, Darkness: A Veteran's Triumph over Combat Trauma”, ISBN 978-1557509895
[5] Orion Moshe Kopelman, Projects at Warp-Speed with QRPD, ISBN 978-1885261168 [6] «Мауи» из «Википедии»
[7] Ori Kopelman Candidate for Mayor с сайта Mauitopia
[8] Ken Schwaber, Agile Project Management with Scrum, ISBN 978-0735619937|[9] OLD Scrum Guide, Version 1, February 2010 с сайта MITCH LACEY & ASSOCIATES, INC. [10] «Руководство по Scrum» с сайта Scrum Guides
[11] Джефф Сазерленд, «Scrum. Революционный метод управления проектами», ISBN 978-5-00057-722-6