Отличия Definition of Done от Acceptance Criteria (CoS)

Sat, 06 Apr 2019 16:01:08 +0300

В нашей работе очень важно помнить о том, что нам нужна прозрачность (transparency) того, что делает команда, для всех кто работает с этой командой: это могут быть другие команды, Заинтересованные лица (они заинтересованы в том, что делает эта команда, и будут как-то использовать тот результат, что она делает), а в особенности для Владельца продукта.

Так как же Команде разработчиков договориться с Владельцем продукта о том, что же такое сделано? И тут, на помощь нам приходит Критерии Готовности (DoD или Definition of Done) – это чек-лист работ, которые проходит каждая из задач команды, после чего она может на каждую из них свою печать “Готово”. Этим команда заверяет, что продукт сделан правильно.

Владелец продукта, принимая задачу от команды, уже знает, что все очевидное и ожидаемое, по умолчанию от команды, сделано. А чтобы, это действительно было так, то стоит, этот список действий, записать в явном виде и согласовать с двух сторон. Цель в том, чтобы не было разночтений, все четкой ИЛИ работа СДЕЛАНА, ИЛИ НЕ СДЕЛАНА, только в этом случае, будет доверие к команде от Владельца Продукта и Заинтересованных лиц.

Кто составляет этот список?

Команда. Это именно команда, говорит, что для нее значит, что задача сделана, это общий список без привязки к контексту. Это может быть для ИТ проекта: “Прошли автотесты, Сделан регресс, Написана пользовательская документация, и т.д.”, для доставки: “заказ собран в коробку, упакован в пакет, зарегистрирован в систему, наклеен штрих-код, положен на полку на складе”.

Достаточно ли это для Владельца продукта?

Очевидно, нет! То, что код прошел все технические процедуры, а коробка лежит в красивом виде на правильной полке, не говорит ничего о содержимом. Для содержимого, есть дополнительный критерий, называемый Критерий Приемки (Acceptance Criteria). Он уже составляется Владельцем продукта, для того чтобы понимать, что сделали вещь правильную.

Соединение DoD и AC, дает нам прозрачность в том, что была сделана правильная вещь правильным способом.

Давайте посмотрим на это, на примере метафоры нашего любимого аэропорта.

Мы приходим в аэропорт и сдаем багаж. Каждый багаж проходит необходимые проверки: по размеру, весу и содержимому. Если в самолет загрузили багаж, то команда самолета уверена, что все, что загружено правильной формы, безопасно и т.д. Эти все процедуры – это критерии готовности (DoD), в которых вам можно, что сдав свой багаж, вы получите его целым по прилету. И тут-то содержимое чемоданов – это критерий приемки (AC), он то и важен для вас, в соответствии с ним, вы смотрите, что все что вы положили в чемодан, прилетело в целости и сохранности.

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

В пиццерии

DoD: пицца приготовлена, пожарена, нарезана, упакована в коробку / подана на стол и нигде в процессе не испорчена

Acceptance Criteria: пицца именно того размера и вида (состав ингредиентов), какого заказал клиент.

Говоря математическим языком: DoD – это необходимое условие, а AC – это достаточное условие. Они всегда идут рука об руку, но путать их не надо.

Еще, для больших команд, применяется критерий готовности Релиза (Definition of Done for a Release).

Если вам не нравится слово Критерий приемки, то можете взять вариант Хенрика Книберга «Как продемонстрировать» (How to demo) или Майка Кона «Условия удовлетворения ожиданий» (Conditions of Satisfaction). Эти варианты больше подходят для задач без ИТ, например, в высокоуровневых бизнес-целях.

Что такое идеальный DoD?

DoD – это те работы, которые мы делаем с каждым элементом бэклога, каждый спринт. И в идеале, у вас в результате есть то, что сразу можно поставить \ отдать пользователю. Но что делать, если для этого нужно сделать что-то еще? Например, провести сборку, сделать нагрузочное тестирование, подготовить документацию, получить согласования от юристов, бухгалтерии, безопасников и т.д. Быть честным!

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

Список Критериев может создаваться как самим Владельцем продукта, а может и командой разработки. Команда, на планировании или PBR, может задавать вопросы относительно этого списка в целях прояснения понимания, что нужно сделать, а так же предлагать от себя дополнительные критерии. Здесь важный нюанс, что ответственность за то, как будет проверяться каждый элемент бэклога, лежит на Владельце продукта.

Сокращенно, AC – называть не удобно и можно путать с Agile Coach, Автоматизированная Система и т.д. Поэтому, давайте пользоваться термином CoS (Conditions of Satisfaction) Условия удовлетворения ожиданий

Автор: Роман Петров

Kanban.club: posts tagged Conditions of Satisfaction