Definition of Ready VS Definition of Done VS Acceptance Criteria
Периодически в сети натыкаюсь на холивары на тему, что же такое Definition of Done, совпадает ли Definition of Done и Acceptance Criteria и т.д. А уж если в ветке кто-то вспомнит, что еще существует Definition of Ready – все, тушите свет. В общем, я, как всегда, решила не проходить мимо и вставить свои 5 копеек.
Тем более как раз свои старые записи листала, и хорошая картинка с тренинга попалась:
В чем же нюансы и почему это вызывает столько недопонимания?
Давайте по пунктам:
В общем, как вы поняли из трех пунктов выше, основной смысл всего этого добра – чтобы вся команда понимала:
…и не тратила ценное время и энергию.
Примеры 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:
Используете описанные артефакты у себя? Расскажите в комментариях!
Информация полезна? Поддержи развитие проекта!
На кофе и новые материалы для читателей блога 🙂
Критерии Готовности к Разработке (Definition of Ready)
Информация, которая требуется команде для понимания и выполнения работы над Элементом Бэклога Продукта. Описание критериев готовности Элементов к разработке должно быть таким, чтобы для выполнения работы команде не требовалось дополнительных обсуждений и исследований. Такие Элементы можно принять в работу немедленно (они Immediately Actionable). Например, Элементы можно проверять на соответствие критериям I.N.V.E.S.T.
I.N.V.E.S.T. – это аббревиатура, объединяющая шесть характеристик, которыми должен обладать Элемент Бэклога Продукта, чтобы соответствовать Критериям Готовности к Разработке.
Диаграмма Сгорания Работ Спринта визуально показывает прогресс Команды в Стори Поинтах по дням спринта. Это графическое представление того, сколько работы уже сделано и сколько еще остается сделать. Диаграмма позволяет Команде прогнозировать успех Спринта и предпринимать меры, чтобы к моменту окончанию Спринта все запланированные задачи были были завершены.
Критерии Приемки (Acceptance Criteria)
Специфические требования и приемочные тесты, которым должны соответствовать Элементы Бэклога Продукта, чтобы работа по ним считалась завершенной с точки зрения клиента / Владельца Продукта. Определение Критериев Приемки звучит очень похоже на Критерии Готовности, но в действительности эти понятия отличаются: Критерии Приемки касаются требований клиента к конкретному Элементу Бэклога, а Критерии Готовности формируются командой и касаются многих Элементов.
Оценка (Estimation)
Оценка – это прогнозирование усилий, которые потребуются для завершения работы над Элементом Бэклога Продукта. Она обеспечивает Владельцу Продукта и Скрам-мастеру уверенность в дате релиза и является базой для расчета производительности Команды. Существует множество способов оценки усилий Скрам-командой, но при этом всегда используются относительные единицы: например, Стори Поинты. Обычно оценка проводится в рамках Уточнения (Груминга) Бэклога Продукта.
Величина, отражающая количество работы, которое Скрам-команда может выполнить за один Спринт. Является важной метрикой в Скраме. Производительность вычисляется в конце Спринта как сумма Стори Поинтов по всем полностью завершенным Элементам Бэклога Спринта.
Чтобы оценить объем работы над Элементом Бэклога Продукта, Скрам-команды обычно используют Стори Поинты. Это условная величина, позволяющая давать Элементам Бэклога относительные веса. Чаще всего для оценки в Стори Поинтах используются числа Фибоначчи (1, 2, 3, 5, 8, 13, …), что позволяет провести оценку достаточно быстро.
Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми
DoR | Definition of Ready
Definition of Ready (DoR) инструмент про который довольно сложно найти информацию в интернете. Строго говоря в Скрам Гайде нет такого термина или описания этого инструмента. Однако если обратиться к Scrum Glossary то можно найти такой термин как Ready.
Ready: a shared understanding by the Product Owner and the Developers regarding the preferred level of description of Product Backlog items introduced at Sprint Planning
Ready — это общее понимание/договоренность между Владельцем Продукта и Командой Разработки о предпочтительном уровне проработки элемента Бэклога Продукта к моменту планирования.
DoR должен быть своеобразным щитом для команды
Существует мнение, что DoR это своеобразный щит для команды от изменения требований. С одной стороны это действительно так. Скрам помогает нам ограничить постоянные изменения длиной спринта. В рамках спринта мы определяем цель и создаем условия в которых команда может ее достичь. DoR помогает нам создавать такие условия.
Однако он не должен превращаться в бюрократический барьер. В ситуации когда за 15 минут до планирования в ТОПе Бэклога Продукта появляется задача, по которой не все пункты DoR выполнены, Команда Разрабоки берет такую задачу в работу, а Владелец Продукта принимает на себя риски связанные с этим. Такой подход дает компании ту самую гибкость, которую описывает нам Agile манифест. Конечно такая ситуация не должна повторяться слишком часто. Иначе это может симптомом наличия системной проблемы, связанной с управлением Беклогом Продукта.
Как работать с Definition of Ready
Есть распространенное заблуждение, что работа с DoR заканчивается в тот момент, когда он составлен и команда регулярно его использует. На самом деле некоторые пункты в DoR могут быть дисфункцией. Например, наличие пункта «Архитектура согласована» в DoR у Скрам Команды прямо говорит нам о том, что команда на самом деле не автономна. Что может Скрам Мастер сделать в такой ситуации? Помочь команде затянуть к себе необходимую экспертизу и сократить время на согласования. Другой вариант попросить отдел Архитектуры сформулировать стандарты. Это поможет команде приносить на согласование решения соответствующее этим стандартам и также сократит время на согласование.
Говоря общими словами нам нужно критически посмотреть на каждый пункт DoD и задать себе вопрос: «Как он влияет на Time To Market?»
Для более полного понимание прикрепляю к этой статье Definition of Ready одной из моих команд.
Подробнее вы можете ознакомиться на примере.
Definition of Ready (DoR) пример
До PBR:
Во время PBR:
* Если применимо к задаче
Любой инструмент нужно использовать осознанно, в том числе и DoR. Если инструмент не решает никакой проблемы, то есть большая вероятность, что команда бесполезно потратит время на его создание. На практике он станет просто бесполезным артефактом. Опытный Скрам Мастер сможет определить, когда команда достаточно созрела для внедрения DoR.
Упражнение на создание Критериев готовности (Definition of Done, DoD)
Алексей Бушманов
06.05.2021
Комментариев нет
Если ваша команда работает по скраму или с использованием других аджайл-подходов, то возможно одним из первых рабочих соглашений команды были Критерии готовности (Definition of Done).
Один из способов сформировать эти критерии — найти готовые примеры из интернета. Но важно отметить, что для команды важен не сам артефакт — наличие собственно списка критериев, но действие, которое члены команды выполняют совместно для того, чтобы увидеть свои слепые зоны и создать то рабочее соглашение, которое они сами будут поддерживать.
Например, если кто-то в команде считает, что при создании фичи в коде не может быть ошибок, а кто-то готов смириться с тем, что там могут быть незначительные проблемы, тогда это отличный повод обсудить это в команде. Лучше это сделать в начале проекта, чем непосредственно перед тем, как владелец продукта или продакт-менеджер попросит сделать поставку.
Если у вас присутствует такой диалог (больше чем просто спор, а каждый объясняет свою позицию и озвучивает свои ценности), то ваша команда вступила во вторую из четырех стадию формирования команды (фомирование, шториминг, нормирование, высокая производительность) — поздравляем! Это кстати ещё одна причина для формирования Критериев готовности — переместить команду от незнакомцев к членам единой команды.
Затем положите стикеры на стол и попросите членов команды написать на стикерах определения «Готово» (1 тезис на стикер), а затем поместите его на доску в нужном месте. Далее, следующий человек может или переместить карту в другое место (сейчас, дальше, позже), либо написать новый стикер и разместить его в выбранной им области. Игра продолжается до тех пор, пока вы будете чувствовать удовольствие или не получите список Критериев готовности, которое разделяет большинство участников. Возможно, вам захочется обсудить усиление вашего определения «Готово» со временем. Легко представить, что Критерии готовности в первом спринте будут отличаться от, например, 73-го после нескольких релизов и множества отзывов клиентов, когда у вас например будет внедрено непрерывное развертывание (Continuous Deployment, CD).
Если вам интересно посмотреть готовые карточки, используйте размещенные идеи ниже — они не лучше, чем предложения любого участника относительно командных Критериев готовности, но они могут также помочь объединить членов команды и помочь им и взаимодействовать в игре, сотрудничая друг с другом.
Алексей Бушманов
Сертифицированный скрам-мастер, тренер и коуч Сфера интересов: Развитие команд и организаций, тренинги и обучение
DoD |Definition of Done| Критерии готовности
Definition Of Done (DoD) — критерии, определяющие степень готовности задачи.
Часто у членов команды нет общего понимания о том, что такое «готово». Это может приводить к постоянным конфликтам внутри команды и багам на продуктивной среде. Также довольно распространена ситуация, когда Владелец Продукта просит команду закончить работу быстрее. Например, ему нужно раньше конкурентов вывести продукт на рынок. Часто в такой ситуации урезается скоуп тестирования или функционал реализуется путем приделывания костылей. Такой подход ведет к накоплению технического долга.
DoD — это чек-лист, c помощью которого можно понять, что задача готова. Каждая команда имеет свои критерии готовности. Они определяются в зависимости от контекста и состава команды. Очень важно, чтобы каждый член команды полностью понимал и принимал каждый пункт в этом списке. Другими словами DoD это разновидность командного соглашения по конкретному вопросу.
Критерии готовности, которые выбрала команда, это открытая информация, доступная всем заинтересованным лицам. Их наличие обеспечивает прозрачность, как внутри команды, так и во вне по отношению ко всей организации. Со временем команда улучшает критерии готовности путем ретроспективных изменений. Уровень DoD является показателем зрелости команды.
DoD в LeSS
Если продукт развивают несколько команд, использующих LeSS-фреймворк, то критерии готовности должны быть общими. Другими словами, нужен единый Definition of Done.
Пример DoD Scrum команды
Пример DoD Kanban команды
Аналитика
Разработка
Тестирование
Definition of Ready
Кроме критериев готовности хорошей практикой считается использовать Definition of Ready или DoR. Это критерии, которые должен соблюсти заказчик, чтобы его задачу взяли в работу. Например, «к задаче должны быть написаны критерии приемки».
