Упражнение на создание Критериев готовности (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. Это критерии, которые должен соблюсти заказчик, чтобы его задачу взяли в работу. Например, «к задаче должны быть написаны критерии приемки».
Критерии Готовности [Определение Готовности] (Definition of Done)
Критерии Готовности — это требования качества, предъявляемые к продукту и его Инкрементам — описание того, что нужно сделать, чтобы считать завершенной работу над будущими Инкрементами и реализованными в них Элементами Бэклога Продукта.
Критерии Готовности играют роль сommitment’а для Инкремента (в русской версии Scrum Guide термин сommitment переведен абстрактным словом «приверженность»). Commitment есть у каждого из трех артефактов Скрама и способствует понятности артефакта и лучшему соответствию между артефактом и конкретной работой Скрам-команды. В частности, Критерии Готовности помогают Скрам-команде оценивать, проверять и доводить работу над Элементами Бэклога до конца.
Определение Критериев Готовности звучит похоже на Критерии Приемки, но в действительности эти понятия отличаются: Критерии Приемки касаются требований клиента к конкретному Элементу Бэклога, а Критерии Готовности формируются командой и касаются многих Элементов и Инкрементов в целом.
Руководство по Scrum версии 2020 года следующим образом описывает назначение, содержание и применение Критериев Готовности (в этой версии термин Definition of Done впервые переведен как Определение Готовности, но мы пользуемся русским переводом, сложившимся за 10 предшествующих лет):
Критерии Приемки (Acceptance Criteria)
Специфические требования и приемочные тесты, которым должны соответствовать Элементы Бэклога Продукта, чтобы работа по ним считалась завершенной с точки зрения клиента / Владельца Продукта. Определение Критериев Приемки звучит очень похоже на Критерии Готовности, но в действительности эти понятия отличаются: Критерии Приемки касаются требований клиента к конкретному Элементу Бэклога, а Критерии Готовности формируются командой и касаются многих Элементов.
Цель Продукта описывает будущее состояние продукта, которое может выступать в качестве конечной цели, используемой Скрам-командой при планировании работы. Цель Продукта входит в состав Бэклога Продукта и играет в нем роль сommitment’а.
Цель, которая ставится на Спринт, и может быть достигнута через выполнение Элементов Бэклога Спринта. Она описывает то, для чего создаётся Инкремент Продукта.
Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми
Definition of Ready — то, о чем нам забыли рассказать
Введение
Наверняка вы не раз слышали, скорее даже использовали с командой артефакт Scrum — Definition of Done далее по тексту — DoD. Возможно, используете его, даже не осознавая этого. О DoD написано много русскоязычных статей. О нём говорят на конференциях, и тренингах. Разобраться для чего нужен этот артефакт, и найти примеры не трудно. DoD определяет критерии, по которой каждый член команды понимает, что задача закрыта. Глубинная цель — синхронизировать понятие Done, между каждым членом команды. Над этими критериями, часто, команда трудится во время ретроспективы. Существует похожий артефакт, о котором почему-то нет упоминания в русскоязычных ресурсах о Scrum, а там где этот артефакт упоминается, не даётся никаких разъяснений что это, зачем нужен, и как использовать.
Скорее всего, в вашей команде звучали фразы наподобие: «Мы завалили цель, потому что неправильно оценили задачу», или «Наш PO опять пришёл с задачей без должного описания». В моей команде, подобные “сигналы” появлялись не один раз, и я долго искал способ, чтобы решить эту проблему.
На Definition of Ready далее по тексту — DoR я наткнулся случайно, в профильном чате, который посвящен Agile. Попытавшись найти информацию, не нашёл ни одного упоминания в рунете на эту тему. Поэтому отправился читать и переводить англоязычные статьи. Теперь делюсь с вами результатом, надеюсь это поможет сделать вашу команду, еще круче и продуктивнее.
Что такое DoR
И так, что же такое DoR? Google переводчик подскажет, что это «определение готовности». Если DoD включает в себя критерии завершенности задачи, то DoR — критерии готовности задачи к взятию в работу. То есть, если задача, отвечает критериям из DoR, команда может взять её на планировании в работу. Вроде бы просто, вы уже наверняка начали придумывать как наконец то вместе с командой составите целый список требований для вашего PO, чтобы тот стал писать тонну документации, а остальные члены команды спокойно смогли сидеть за своим компьютером, и молча писать код. Это только начало, и DoR не то, чем кажется на первый взгляд.
Зачем нужен DoR
Сначала ответим на вопрос: зачем нужен этот артефакт? Какую пользу он принесет команде? DoR поможет команде:
Давайте взглянем на список проблем, которые косвенно, или напрямую вытекают из-за отсутствия DoR:
В конце концов, это приводит к выпуску продукта, который не рабочий, бесполезный, не решает первоочередной проблемы. А это в пустую потраченное время, которое каждый желает тратить на важные вещи. В одной из статей, я встретил отличное высказывание: «Мусор вошёл, мусор вышел».
Где применять DoR
DoR используют на Product Backlog Refinement далее по тексту PBR или более привычное название артефакта: Grooming. Во время этой активности, User Story становятся готовыми — Ready. Это означает что результатом мероприятия, в Бэклоге продукта, будут Ready US. DoR нужен чтобы описать состояние, при котором US, можно обсуждать на планировании. Это называется Takin in — принятые US.
Чтобы пойти дальше, обращаю внимание, как Джефф Сазерленд, один из основателей Scrum и Agile манифеста, рассказывает о DoR и DoD в своих видео. Сазерленд вводит понятия Done-Done, и Ready-Ready. Когда член команды говорит что задача готова или выполнена, подразумевается, что она соответствует тем критериям, которые команда определила в DoD и DoR соответственно. Это важный аспект, каждый член команды должен понимать его, и не забывать. Иначе возникают смешные ситуации, когда на Daily Петя будет рассказывать что задача уже выполнена, а потом выяснится, что там ещё тесты дописать надо, и было бы неплохо выполнить рефакторинг кода, да и Code Review ещё не проходили.
Таким образом, пока US не достигнет состояния Ready-Ready, она не существует, и не обсуждается на планировании. Верхняя часть бэклога должна состоять только из US, с состоянием Ready-Ready. Лучший способ добиться этого, прорабатывать US вместе с командой. Это позволит взглянуть на задачу с разных сторон, вовлечь в процесс каждого члена команды, и впоследствии развить коллективную ответственность за выпускаемый функционал. Разработчики буду сами отвечать за результат и качество, если осознают, что это плод «их» совместной работы.
Когда применять DoR
Когда команда понимает во время PBR, что задача не соответствует DoR, и несет с собой слишком много неопределенности, составляйте список вопросов, выбирайте исследователя, и откладывайте задачу до следующего PBR. В моей команде, это называлось Research, но впоследствии мы перешли на Spike из XP, так как посчитали что это приносит больше результата и ясности по итогу исследования. Обязательно ограничивайте исследование по времени, и обозначьте результат, который хотите получить по итогу. Во время Spike исследователь может привлечь любую помощь со стороны, например участников других команд, методологов, PO, архитекторов… в общем любого, кого посчитает нужным. Результат — ответы на вопросы, новые данные, прототип. Если таких User Story много, в каждый спринт можно брать по 1-2 Spike, на следующие итерации, таким образом обеспечите постоянный поток Ready задач.
Как уже упоминалось выше, DoR — набор критериев. Команда может попробовать сама составить эти критерии. Проработайте те “сигналы”, которые прослеживаются в итерациях. Обсудите на ретроспективах эти моменты, найдите глубинную причину. Если нет желания тратить следующую ретроспективу на это, воспользуйтесь готовыми решениями.
Во многих статьях описывается модель INVEST, которая похожа на SMART, но более подходит для User Story. Помимо статей, данную модель так же рекомендуют и в Agile литературе. Например Роман Пихлер в книге “Управление продуктом в Scrum” или Майк Кон — “Пользовательские истории. Гибкая разработка программного обеспечения”.
INVEST модель
Заключение
В заключение: используя DoR, вы не избавитесь от пробелов, которые будут просачиваться в спринт. Так же это не означает, что во время спринта отпадает необходимость постоянного контакта PO с разработчиками. Постоянно фиксируйте результаты обсуждений в виде приемочных тестов, так никто из команды, не потеряет понимание статуса задачи. Проанализируйте и обсудите с командой текущие проблемы, возможно они связаны с отсутствием DoR.
DoR — артефакт, который позволит команде лучше продумывать US, что в конечном итоге снизит риски, и позволит побудить каждого члена команды к постоянному обсуждению задач. Много развернутой информации о INVEST, и User Story, вы найдете в книге «Пользовательские истории». Рекомендую дать прочитать эту книгу каждому члену команды, или хотя бы прочитайте сами и поделитесь с ними информацией.
Напишите в комментариях какие DoD и DoR используются у вас в команде.
The Improved Methods
Обучение Agile методам, Agile трансформация компаний, консультации
Боремся с путаницей в терминах: Критерии готовности VS Критерии приёмки
Что-то за последнее время я часто возвращаюсь к дискуссии о «Критериях готовности» (done criteria) и их отличии от «Критериев приёмки» (acceptance criteria). И в отдельных командах, с которыми я работаю, и на тренингах, люди поднимают похожие вопросы. Для меня, обычно, это повод написать пост.
Если высказать свою точку зрения коротко, то, как говорят в Одессе: «Это две большие разницы» :-).
О «Критериях готовности» говорят почти всегда, когда рассказывают о внедрении в Scrum. Хотя не всегда вдаются в подробности, и это порождает волну вопросов позже, когда люди начинают пробовать и «примерять» Скрам на себя. В реальности, ответ не такой однозначный в силу того, что русский перевод фраз «Acceptance criteria» и «Done criteria» может звучать очень похоже. Даже Хенрик Книберг (который, кстати, будет на AgileEE 2010) в своей популярной книге “Scrum and XP: from the trenches” был достаточно туманен, и это отразилось в русском переводе книги такой же неоднозначностью.
Конечно, если говорить философски, то и для одной отдельной Истории Пользователя (Фичи, требования, пожелания, какой_там_термин_вы_используете) нужно определить, когда она сделана/готова. Хенрик предлагает называть всё термином «Как продемонстрировать» (How to demo), хотя многие возмущаются, мол, у нас не демонстрируемая функциональность: «мы пишем сервисы» или «API для разработчиков». По схожей причине многие не любят термин «Критерии приёмки» (Acceptance Criteria), так как не у всех выполняется приёмочное тестирование заказчиком. Лично я люблю термин Майка Кона «Условия удовлетворения ожиданий» (Conditions of Satisfaction). Хотя, всё-таки, чаще всего используют Acceptance Criteria – давайте понимать его в широком смысле слова.
«Критерии приёмки» нужны нам для проверки каждой отдельной Истории Пользователя (фичи и т.п.) и подтверждения, что после реализации система работает, как этого хотел заказчик. Такие критерии будут почти уникальные для каждого элемента бэклога (Product Backlog Item) и должны уточняться, перед тем как команда возьмёт тот или иной элемент в итерацию (спринт).
Когда же речь заходит о результатах целой итерации (спринта), то тут уже стоит вопрос о том, что вся новая функциональность не просто сделана, а ещё и потенциально готова к передаче пользователям, ну или хотя бы демонстрации заинтересованным лицам. Вот тут-то на сцену и выходит термин «Критерии готовности» (Done Criteria или Definition of Done). «Критерии готовности» включают в себя ряд действий, которые нужно выполнить для того, чтобы сократить дополнительные действия между тем, когда команда говорит «мы сделали», и заказчик говорит «заверните, я беру». Если между этими двумя моментами вам нужно сделать ещё много телодвижений, то задумайтесь о том, каков же «Definition of Done» в вашей команде :-).
Поскольку почти все шаги «критериев готовности» должны быть выполнены для каждого элемента в бэклоге, то чаще всего говорят о простом проверочном списке. Достаточно подробно и с примерами критериев об этом написал Николай Алименков в своей статье. Важно помнить, что эти критерии применяются ко всем элементам бэклога, которые были сделаны в спринте. Хорошо бы спросить об идеях ваших тестировщиков и заказчиков, и тогда вы будете выпускать «потенциально готовый продукт» максимально подходящий к вашей ситуации.
Если у вас команда, которая работает над долгосрочными выпусками стабильной версии (т.н. релизами), то, скорее всего, у вас будут критерии ещё более высокого уровня. Их можно назвать «критерии готовности выпуска» (Definition of Done for a Release). Эти критерии повлияют на планирование всего выпуска, и о них нужно помнить постоянно и не откладывать на последний момент.
Простой мозговой штурм позволит вам сделать список из 3-10 элементов, которого будет более чем достаточно. Такой список пригодится и для планирования итерации и, если есть отдельный список, то и для всего выпуска. Ведь необходимо запланировать ровно столько функциональности, сколько вы успеете сделать согласно всем пунктам проверочного листа с «критериями готовности». Будьте реалистами 🙂
