Управление проектами.РУ

Управление проектами.РУ
Сообщество тех, кто умеет или хочет научиться
хорошо управлять проектами
28 июля 2020 Все для начинающего РМа
2

Definition of Ready VS Definition of Done VS Acceptance Criteria

Юлия Бажанова
Редактор проекта, РМР, ICP-PPM




Периодически в сети натыкаюсь на холивары на тему, что же такое Definition of Done, совпадает ли Definition of Done и Acceptance Criteria и т.д.  А уж если в ветке кто-то вспомнит, что еще существует Definition of Ready – все, тушите свет. В общем, я, как всегда, решила не проходить мимо и вставить свои 5 копеек.

Тем более как раз свои старые записи листала, и хорошая картинка с тренинга попалась:

Definition of Done (DoD), Definition of Ready (DoR) и Acceptance Criteria (AC) – набор артефактов, которые используются в управлении проектами для того, чтобы убедиться, что работа сделана как надо. Сами термины , насколько я помню, взяты из SCRUM, но, по факту, даже в том же словаре WBS будут схожие разделы. Применимо, конечно же, в первую очередь в разработке ПО, но при желании можно на любом проекте использовать.

В чем же нюансы и почему это вызывает столько недопонимания?

Давайте по пунктам:

  1. Definition of Ready (DoR) – критерий готовности задачи к тому, чтобы взять ее в работу. Как правило, Definition of Ready будет одинаковым для всех задач в проекте. Для этого на старте надо договориться, что именно должно быть в задаче, чтобы ее можно было реализовать, а не бесконечно бегать за уточнениями. Ну, например, задача “подготовить тестовую среду” – так себе задача, ни понимания, что делать, ни деталей, ни ожидаемого результата. Дашь ее кому-нибудь, а человек либо просто зависнет и ничего не сделает (потому что это очень большое умственное усилие – придумать, ЧТО делать, кроме шуток), либо сделает ну совсем не то. А вот если бы мы заранее договорились, что, например, задачу берем только при четко обозначенном измеримом результате, что она не должна превышать 16 часов (иначе надо бить на отдельные задачи) и т.д. – то она бы превратилась в более разумное “поднять сервер с такими-то характеристиками, поставить на него базу и дать доступ такого-то уровня таким-то командам”. И огромная доза мыслетоплева исполнителя была бы сэкономлена для более нужных вещей, и результат был бы более предсказуем.
  2. Definition of Done (DoD) – критерий полной готовности задачи. Так же как и Definition of Ready, обычно одинаков для всех задач в проекте. Для этого на старте нужно сесть и договориться, в каком случае мы считаем, что все, это финал, задача закрыта, и мы к ней больше не возвращаемся? Например, выполнена разработка, код залит в репозиторий, проведено тестирование, выполнена установка на прод, функционал описан в документации. Фух, все, можно выдохнуть и напротив этой задачи поставить галочку. Если этой договоренности не будет, то потом начнется – задача вроде бы сделана, а вроде бы и нет, к ней надо возвращаться и т.д. Сплошная головная боль, потеря рабочего времени и проблемы с загрузкой сотрудников (по документам-то она закрыта, так что время на нее больше не запланировано).
  3. Acceptance Criteria (AC) – критерий того, что задача не просто готова, а еще и работает так, как надо заказчику. А иначе какой смысл в чудесном протестированном и документированном куске кода, если он не несет заявленную бизнес-ценность? И именно поэтому в отличие от Definition of Done и Definition of Ready, Acceptance Criteria для каждой задачи будут уникальными, написанными специально для нее.

В общем, как вы поняли из трех пунктов выше, основной смысл всего этого добра – чтобы вся команда понимала:

  • в каком виде отдавать задачу в работу;
  • когда можно сказать, что задача готова;
  • как будет проверяться готовый функционал;

…и не тратила ценное время и энергию.

Примеры Definition of Done, Definition of Ready и Acceptance Criteria

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

Пример Definition of Ready

Пример Definition of Done

ПримерAcceptance Criteria

Кто отвечает за Definition of Done, Definition of Ready и Acceptance Criteria

Очень хочется сказать “ну конечно, Заказчик!”, но не совсем. Заказчик отвечает только за Acceptance Criteria (за то, чтобы определить, КАК должна работать реализуемая задача). А за Definition of Done (за то, ЧТО будет сделано, чтобы она точно работала так, как и было задумано) отвечает команда. Как и за Definition of Ready, впрочем.

Ну и минутка реальной жизни напоследок

В реальности внятных применений полного комплекта из всех трех артефактов я видела очень мало. Лично у меня обычно не доходит до формализации Definition of Ready, тут я полагаюсь на свой адекват и на адекват владельца продукта, а кейсы с кривыми задачами исправляются на ручном приводе.

А вот Definition of Done я обязательно в начале проекта с командой согласую. Даже если в проекте не аджайл – это отличная перестраховка от появившихся внезапно хотелок архитектуры или информационной безопасности.

Ну и Acceptance Criteria – наше все, конечно. Опять же, для пользовательских задач – must have, а вот на технических могу и пропустить, если в команде высокий уровень взаимопонимания.

P.S. Для тех, кто знает толк – при прямо аджайле-аджайле в компании у команды могут быть (и должны быть) Definiiton of Ready и Definiiton of Done не только для задач, но и для отдельных пользовательских историй, спринтов и релизов.

Не совсем по теме поста, но очень уж хорошая картинка про Definiiton of Done при поиске примеров попалась, не могу не поделиться:

И вот еще про Definiiton of Ready:

Используете описанные артефакты у себя? Расскажите в комментариях!





комментарии

Добавить комментарий

Такой e-mail уже зарегистрирован. Воспользуйтесь формой входа или введите другой.

Вы ввели некорректные логин или пароль

Sorry that something went wrong, repeat again!

2комментария

сначала новые
по рейтингу сначала новые по хронологии
1

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

Автор2
Юлия Бажанова

Ну. значит, пригодится на следующем проекте=))

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: