Dor что это значит
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 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 используются у вас в команде.
Чек-листы в 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. Как правило это инструменты для крупных команд, сложных систем. Где есть аналитики, тестировщики, сложна предметная область и т. д.
При умелом применении они позволяют существенно улучшить взаимодействие и взаимопонимание в команде. Заметно сократить ошибки и риски. И как следствие вывести результаты на качественно новый уровень.
Dor что это значит
Смотреть что такое «DOR» в других словарях:
DOR — bezeichnet: Dor (Stadt), antike Stadt im heutigen Israel eine assyrische Provinz, siehe Liste der assyrischen Provinzen Dor (Rumänien), rumänischer Charakterzug Dor – Liebe deinen Nächsten, Bollywoodfilm aus dem Jahr 2006 Dor (Universalreiniger) … Deutsch Wikipedia
Dor — bezeichnet: Dor (Stadt), antike Stadt im heutigen Israel eine assyrische Provinz, siehe Liste der assyrischen Provinzen Dor (Rumänien), rumänischer Charakterzug Dor – Liebe deinen Nächsten, Bollywoodfilm aus dem Jahr 2006 Dor (Universalreiniger) … Deutsch Wikipedia
dor — DOR, doruri, s.n. 1. Dorinţă puternică de a vedea sau de a revedea pe cineva sau ceva drag, de a reveni la o îndeletnicire preferată; nostalgie. ♢ loc. adv. Cu dor = duios; pătimaş. 2. Stare sufletească a celui care tinde, râvneşte, aspiră la… … Dicționar Român
Dör — Dör … Wikipedia
Dör — Administration … Wikipédia en Français
Dor — Dor, n. [Cf.
dor — |ô| s. f. 1. Sensação mais ou menos aguda mas que incomoda. = MAL, PADECIMENTO, SOFRIMENTO ≠ BEM ESTAR, PRAZER 2. Sensação emocional ou psicológica que causa sofrimento. = DESGOSTO, MÁGOA, PESAR • dores s. f. pl. 3. Conjunto de sensações físicas… … Dicionário da Língua Portuguesa
-dor — dor, a (del lat. « tor, ōris») Parte invariable del sufijo « ador, edor, idor». Forma nombres de agente y de utensilio: ‘cobrador, celadora, colador, lavadora’. También, adjetivos de agente, generalmente frecuentativos: ‘cantador, hablador,… … Enciclopedia Universal
Dor — Dor, v. t. To make a fool of; to deceive. [Obs.] [Written also
Dor — Dor, n. [Cf. AS. dora drone, locust, D. tor beetle, L. taurus a kind of beetle. Cf.
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:
Используете описанные артефакты у себя? Расскажите в комментариях!
Информация полезна? Поддержи развитие проекта!
На кофе и новые материалы для читателей блога 🙂