dod и dor что такое
Синхронизация команды со 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 является необходимость жесткой синхронизации разработчиков между собой. В одну область входят несколько разработчиков в разное время, но выходят всегда в единой точке.
Минусом такого подхода является дополнительное время на продумывание организации задач на этапе формирования. Но на самом деле такие затраты легко окупаются. При этом, задачи становятся более структурированными и прогнозируемыми.
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:
Используете описанные артефакты у себя? Расскажите в комментариях!
Информация полезна? Поддержи развитие проекта!
На кофе и новые материалы для читателей блога 🙂
Чек-листы в Agile-разработке: DoD, DoR, CoS (AC) & ToDo
В руководстве про Скрам-разработку и просто в статьях о Agile практиках разработки часто встречаются методы чек листов типа DoD, DoR, CoS и ToDo. Давайте разберемся что это такое и как ими пользоваться.
DoD – Definition of Done
По каким критериям мы можем сказать что задача выполнена (Done)?
Критерий готовности инкремента продукта. Также можно сказать что это критерии готовности задачи для доски или всех задач в команде.
Это общий чек лист для всех задач, соблюдение которого означает что задачу можно закрыть.
Если в команде нет DoD, то возникают проблемы, при которых задачи переводят в готовые, а результатов по факту нет. Или задача не доделана.
CoS – Conditions of Satisfaction
Conditions of Satisfaction — переводится как условия удовлетворенности.
CoS – это чек лист приемки результатов работ по конкретной задаче. Помимо DoD которые на все задачи распространяется в целом. CoS пишется на конкретную задачу. Чтобы разработчики понимали что именно является результатом. Условиями удовлетворенности результатами.
Часто CoS именуют как AC или Acceptance Criteria – Критерии Приемки. Оба термина правильные, являются синонимами. Просто в сокращенном варианте CoS понятнее чем AC. Потому получил больше популярности.
DoR – Definition of Ready
По каким критериям мы можем сказать что задача подготовлена (Ready)?
DoR – это чек лист с критериями по которым мы можем сказать что задача готова к разработке. Описана, подготовлена, декомпозирована и может передаваться в разработку.
Если в команде нет DoR, то возникают проблемы с пониманием задачи разработчиками, результаты есть, но они не те что ожидалось Клиентами.
Появляются ошибки и растут затраты на переделку задач.
У разных команд чек лист может быть разным.
ToDo – Что делать?
Этот чек лист отвечает на вопрос что делать? Или чаще на вопросы кто и что делает?
Просто список шагов, что позволяет лучше понимать кто и что делает или уже сделал.
Этот чек лист обычно меняется по ходу дела. Может менять по 5 раз в день. Обновляется по ситуации.
Многие системы имеют функционал который позволяет быстро обновлять этот список дел и менять акценты (приоритеты).
Итого
Управление по чек-листам это очень простые, эффективные и удобные практики разработки.
Самые важные и нужные тут это CoS & ToDo. Они применяются очень часто, для команд любых размеров. И даже в индивидуальный разработке.
Реже используются DoD & DoR. Как правило это инструменты для крупных команд, сложных систем. Где есть аналитики, тестировщики, сложна предметная область и т. д.
При умелом применении они позволяют существенно улучшить взаимодействие и взаимопонимание в команде. Заметно сократить ошибки и риски. И как следствие вывести результаты на качественно новый уровень.
Критерии Готовности к Разработке (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, …), что позволяет провести оценку достаточно быстро.
Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми
Критерии готовности (Definition of Done, DoD)
Критерии того, что задача/user story считаются завершенными. Т.е. это «фильтр на выход» (тогда как критерии подготовленности — «фильтр на вход» в разработку).
Например:
Команда определила для себя следующие DoD для задач, которые она планирует отправить в релиз программного продукта:
Бэклог продукта (Product Backlog)
Список всего, что предполагается сделать в продукте. В идеале, это должен быть приоритизированный список: задач, инициатив, гипотез, пользовательских историй, багов, улучшений и прочих требований к продукту. Если ваш бэклог приоритизирован на 2-4 итерации вперед, то у вас достаточно приоритизированный бэклог.
Декомпозиция бэклога (Backlog Slicing, слайсинг или нарезка бэклога)
Техники декомпозиции крупных элементов бэклога продукта (требований к продукту) на более мелкие элементы:
Критерии, которые определяют, что задачу/user story можно взять разработку. Т.е. это «фильтр на вход» (тогда как критерии готовности — «фильтр на выход» из разработки).
Например:
Команда устанавливает следующие DoR для входящих задач по разработке программного продукта:
Другими словами, пока данные критерии не будут выполнены, команда не начнет писать код.
Критерии приёмки (Acceptance Criteria)
Условия того, что задача/user story считается выполненной с точки зрения конечного пользователя. Другими словами, успешно выполняются пользовательские сценарии использования данного функционала.
Например, критерий приемки функционала «Счетчик невыполненных задач»:
Когда по задачам пользователя наступает deadline, то он получает push-уведомление о просроченной задаче. Открывая это уведомление, пользователь видит счетчик просроченных задач, т.е. видит общее количество таких задач.
Модель Кано (Kano Model)
Модель позволяет классифицировать функциональные требования к продукту на основании их ценности для клиентов.
Модель разделяет все такие требования на пять категорий:
Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми