Периодически в сети натыкаюсь на холивары на тему, что же такое 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 будут схожие разделы. Применимо, конечно же, в первую очередь в разработке ПО, но при желании можно на любом проекте использовать.
В чем же нюансы и почему это вызывает столько недопонимания?
Давайте по пунктам:
- Definition of Ready (DoR) – критерий готовности задачи к тому, чтобы взять ее в работу. Как правило, Definition of Ready будет одинаковым для всех задач в проекте. Для этого на старте надо договориться, что именно должно быть в задаче, чтобы ее можно было реализовать, а не бесконечно бегать за уточнениями. Ну, например, задача “подготовить тестовую среду” – так себе задача, ни понимания, что делать, ни деталей, ни ожидаемого результата. Дашь ее кому-нибудь, а человек либо просто зависнет и ничего не сделает (потому что это очень большое умственное усилие – придумать, ЧТО делать, кроме шуток), либо сделает ну совсем не то. А вот если бы мы заранее договорились, что, например, задачу берем только при четко обозначенном измеримом результате, что она не должна превышать 16 часов (иначе надо бить на отдельные задачи) и т.д. – то она бы превратилась в более разумное “поднять сервер с такими-то характеристиками, поставить на него базу и дать доступ такого-то уровня таким-то командам”. И огромная доза мыслетоплева исполнителя была бы сэкономлена для более нужных вещей, и результат был бы более предсказуем.
- Definition of Done (DoD) – критерий полной готовности задачи. Так же как и Definition of Ready, обычно одинаков для всех задач в проекте. Для этого на старте нужно сесть и договориться, в каком случае мы считаем, что все, это финал, задача закрыта, и мы к ней больше не возвращаемся? Например, выполнена разработка, код залит в репозиторий, проведено тестирование, выполнена установка на прод, функционал описан в документации. Фух, все, можно выдохнуть и напротив этой задачи поставить галочку. Если этой договоренности не будет, то потом начнется – задача вроде бы сделана, а вроде бы и нет, к ней надо возвращаться и т.д. Сплошная головная боль, потеря рабочего времени и проблемы с загрузкой сотрудников (по документам-то она закрыта, так что время на нее больше не запланировано).
- 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:
Используете описанные артефакты у себя? Расскажите в комментариях!
Добавить комментарий
6комментариев