Dor и dod что это
Синхронизация команды со SCRUM
Как мне кажется, одна их самых больших проблем в скраме — это полный рассинхрон между людьми в команде. Мне пока не удавалось увидеть ни одного стабильного решения этой проблемы. Конечно, есть стандартные инструменты, но далеко не всегда они дают ответы на все вопросы и закрывают все дыры.
Предлагаю зайти к нам в гости и посмотреть как с проблемой синхронизации внутри себя борется команда “Онлайн-ипотеки” компании “Альфа-Банк”.
Статья была подготовлена членами нашей команды: Марина, Дима, Настя, Вероника, Толя.
Не так давно (чуть более полугода назад) в Альфа-Банке стартовал новый проект — «Онлайн-Ипотека». Команда под проект собиралась с нуля. Люди на проект пришли разные и с разных мест работы. Все было прямо по гайду: DevTeam (JS, Java, QA, Аналитик), скрам-мастер и Product Owner. Никто из девтим до этого никогда не работал по скрам-фреймворку.
Первая точка синхронизации: DOR
Итак, мы все собрались, познакомились и почти сразу приступили к делу. Впереди нас ждало множество неочевидных (на первый взгляд) идей. Большинство из них впоследствии стали обыденными и логичными. Но вот что мы долгое время не могли побороть — это мнимая понятность задач. Часто бывает так, что берешь задачу в спринт, а она оказывается не так проста (а иногда и сложна), как казалось на первый взгляд.
Рассинхрон для нас заключался в следующем:
Опыт оказался крайне успешен. Мы стали действовать более слаженно и более продуктивно. На грумингах мы держали DOR перед глазами и использовали как чек-лист при разборе задачи. PO почти всегда узнавал заранее, чего не хватает задаче, и старался как можно скорее уточнить информацию. Иначе такая задача просто не попадала в следующий спринт.
Нам приходилось брать спайки (исследования) из верхних задач в общем бэклоге (backlog) в спринт, но это приносило колоссальный результат. Неопределенность снижалась, и мы начали корректно оценивать трудоемкость задачи.
Тут стоит отметить, что DOR у каждой команды должен быть свой. Дело в том, что он не должен представлять собой набор четких указаний от работодателя. Это скорее требования команды к минимальному описанию задачи и проработке подводных камней, которые должны быть выполнены для удобства и ускорения работы.
Критерии готовности user story к взятию в работу
Вторая точка синхронизации: DOD
Очень хорошо, когда вся команда понимает, какие задачи мы можем помещать в спринт, а какие лучше не стоит. После выполнения условий DOR мы столкнулись со следующим: мы берем задачу (user story) в работу, но как мы можем понять, что она точно готова?
Конечно, мы можем посмотреть на все саб-таски (sub task) и оценить готовность задач по ним. Но что, если мы не завели саб-таску по документации, тестированию или настройке доступов? Есть ли необходимость каждый раз заводить подобные саб-таски?
Ну хорошо. Допустим, мы идеально заводим саб-таски и идеально вовремя их закрываем. Тогда логично было бы закрыть задачу сразу после мерджа в мастер. Но ведь задача еще не на бою! Пользователь не увидит пользы от нашей работы, и все было зря.
Первое время мы спорили о факте закрытой задачи. После чего мы приняли какие-то не совсем формальные правила. Это сильно упростило работу, но время от времени все же конфликты возникали. Тогда мы пришли к следующему стандартному шагу синхронизации.
DOD (Definition Of Done) позволяет решить проблему приемки и общего понимания готовой задачи. DOD очень похож на DOR. Это такой же набор критериев, но на этот раз для готовой задачи. Взглянув на него, мы всегда можем сказать: готова задача или нет.
В результате мы выработали общее понимание того, что надо сделать, чтобы считать задачу закрытой. Только после выполнения всех пунктов задача переходит в DONE.
Подводим итоги первых двух шагов синхронизации
Отлично! Работать стало гораздо удобнее. Мы больше не тратим время на ненужные формальности о разговорах, какая задача готова, а какую стоит еще доработать. С другой стороны, мы больше не боимся брать задачи в спринт. Но что происходит между этими событиями? Раздор, разруха и хаос.
Аналитик не всегда может изначально проверить все задачи в спринте. Один из разработчиков может сделать изменения (без возможности откатиться), которые коснутся другого разработчика. В конце концов, PO тоже люди, и задачи могут меняться в ходе спринта, даже если это сильно не приветствуется в скраме.
На самом деле есть целая масса случаев, которые могут привести к конфликтам и непродуктивной работе между этапами взятия в работу и завершения задачи (для краткости — DOR и DOD). В любой команде почти всегда можно видеть одну и ту же проблему. Кто-то что-то куда-то залил, и второй разработчик теперь страдает. Это провоцирует конфликты и негатив. И, конечно, эта проблема почти всегда возникает, когда одной задачей занимаются несколько разработчиков.
Вначале мы пытались найти что-то из уже существующего вроде DOR и DOD. К сожалению, ничего подобного и подходящего к нам мы не нашли (может быть, плохо искали). Пробовали 1 work in progress, но опыт не удался. Каждая задача состоит из разнородных частей. Наш опыт показал, что при таком подходе кто-то из разработчиков всегда скучает, а кто-то вынужден задерживаться на работе и доделывать свою “половинку”. Не так давно мы собрались и подумали над еще одним промежуточный этапом:
Третья точка синхронизации — наша собственная задумка: DOT
DOT (Definition Of Test) представляет собой набор критериев тестирования задачи и сборки ее в единое целое на тестовом стенде. Также мы устанавливаем правила о том, что девтим не может приступать к дальнейшим действиям (pull requests и тд), пока DOT не будет выполнен полностью.
Взглянем на рисунок и попробуем разобрать идею более подробно. Для начала представим, что у нас имеется только один разработчик на одну задачу:
Сразу отметим здесь ключевую особенность. У нас есть то, что должно быть сделано, и то, что делать нельзя до выхода из зоны тестирования. Сюда можно отнести прохождение pull request, мердж в мастер, выкатку и прочее.
Сразу стоит отметить отличие от DOR и DOD. Когда мы говорим про DOR, мы говорим о том, что нужно для решения задачи. При разговоре о DOD, мы говорим какую задачу можно считать сделанной. В DOT на нас влияют сразу несколько видов обстоятельств. С одной стороны, разработка задачи должна быть завершена. С другой, многие действия для доведения задачи в полностью готовый вид делать не стоит.
По-настоящему раскрывает себя идея в случае нескольких разработчиков с одной задачей. Посмотрим на такой случай. В нашем примере у нас будут фронт и бэк:
Схема очень примерная. Понятно, что у нас один специалист может помогать (или мешать) другому. Необходимость доработать задачу может всплыть раньше. А выкаткой на бой может заниматься другой человек. Главное тут другое. У нас есть некая область с четко оговоренными ДО и ПОСЛЕ. Более того, ПОСЛЕ не может наступить, пока не будут выполнены все условия DOT. И только после этого можно получить ОК от тестирования.
Что еще тут важно? Как видно из картинки, разработка может начинаться в разное время. Самое главное тут то, что в область тестирования входят несколько разработчиков в разное время, но выйти из нее они могут только вместе. Чем они будут заняты в это время — можно договориться.
После того как задача полностью протестирована, все разработчики получают волшебный ОК от тестирования, и теперь уже стартуют из одной точки. Интересно, что здесь крайне мала вероятность каких-то недочетов в синхронизации. Оставшиеся действия занимают примерно одинаковое время.
Потребностью DOT является необходимость жесткой синхронизации разработчиков между собой. В одну область входят несколько разработчиков в разное время, но выходят всегда в единой точке.
Минусом такого подхода является дополнительное время на продумывание организации задач на этапе формирования. Но на самом деле такие затраты легко окупаются. При этом, задачи становятся более структурированными и прогнозируемыми.
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.
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 Done, DoD)
Критерии того, что задача/user story считаются завершенными. Т.е. это «фильтр на выход» (тогда как критерии подготовленности — «фильтр на вход» в разработку).
Например:
Команда определила для себя следующие DoD для задач, которые она планирует отправить в релиз программного продукта:
Бэклог продукта (Product Backlog)
Список всего, что предполагается сделать в продукте. В идеале, это должен быть приоритизированный список: задач, инициатив, гипотез, пользовательских историй, багов, улучшений и прочих требований к продукту. Если ваш бэклог приоритизирован на 2-4 итерации вперед, то у вас достаточно приоритизированный бэклог.
Декомпозиция бэклога (Backlog Slicing, слайсинг или нарезка бэклога)
Техники декомпозиции крупных элементов бэклога продукта (требований к продукту) на более мелкие элементы:
Критерии, которые определяют, что задачу/user story можно взять разработку. Т.е. это «фильтр на вход» (тогда как критерии готовности — «фильтр на выход» из разработки).
Например:
Команда устанавливает следующие DoR для входящих задач по разработке программного продукта:
Другими словами, пока данные критерии не будут выполнены, команда не начнет писать код.
Критерии приёмки (Acceptance Criteria)
Условия того, что задача/user story считается выполненной с точки зрения конечного пользователя. Другими словами, успешно выполняются пользовательские сценарии использования данного функционала.
Например, критерий приемки функционала «Счетчик невыполненных задач»:
Когда по задачам пользователя наступает deadline, то он получает push-уведомление о просроченной задаче. Открывая это уведомление, пользователь видит счетчик просроченных задач, т.е. видит общее количество таких задач.
Модель Кано (Kano Model)
Модель позволяет классифицировать функциональные требования к продукту на основании их ценности для клиентов.
Модель разделяет все такие требования на пять категорий:
Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми