Введение
Что такое DoR
Зачем нужен DoR
Где применять DoR
Когда применять DoR
INVEST модель
Заключение
Список литературы

Введение

Наверняка вы не раз слышали, скорее даже использовали с командой артефакт 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 поможет команде:

1. Избежать начала работы над фичами, которые не имеют ясного определения критериев завершенности. Команда будет понимать, когда User Story считается законченной, и что нужно сделать для этого.
2. Не тратить много времени впустую на длительные обсуждения, плохо продуманных задач. Заранее обработанная задача — сохранит время всей команды. Посчитайте сколько времени уходит на обсуждение «плохой» задачи, для одного человека. А теперь умножьте на количество человек в команде. А теперь на количество таких задач.
3. Сфокусировать время и энергию на вещах которые настолько «безопасны» насколько это возможно. Один из самых сильных демотиваторов — функционал, который выкидывается в мусорное ведро.
4. Вовлечь каждого участника в обсуждение задач. Во-первых, это мотивирует команду. Во-вторых, помогает раскрыть каждого члена команды как специалиста. В-третьих, разработчики предложат свое видение проблемы. При обсуждении могут возникнуть иные решения, которые будут кардинально отличаться от первоначальной задумки.

Давайте взглянем на список проблем, которые косвенно, или напрямую вытекают из-за отсутствия DoR:

1. Регулярно появляются расхождения в понимании задачи, между членами команды. К концу спринта, расхождение усиливается, что приводит к казусам, когда в процессе разработки происходили изменения, что естественно. Но ввиду того, что эти моменты не фиксировались, о них знает только тот, кто непосредственно столкнулся с этим.
2. Требования к функционалу, меняются быстрее чем команда успевает понять их. Так как в спринт вошла задача, с высокой неопределенностью, к моменту когда часть уже готова, и заложен «фундамент», появляется новая информация, которая потребует вернуться в начало. Чем хуже проработана задача, тем чаще будет возникать такая ситуация в спринт. В конце это приведет к факапу.
3. Часто возникают проблемы, с оценкой результата полученного от функционала, команда не знает как собрать метрики, или ещё хуже, забыла о них. Scrum это в первую очередь о пользе для заказчика, пользователя или покупателя. Если команда не оценивает пользу задачи, она не получает фидбек и возможность скорректировать курс развития продукта. Это может привести к полному провалу.
4. Также, отсутствие DoR, сильно влияет на тестирование, и вместо того, чтобы QA тестировал ожидания по User Story, он будет тестировать ожидания разработчиков. Код может работать идеально, автотесты будут отрабатывать как часы, но на Production функционал не будет работать.

В конце концов, это приводит к выпуску продукта, который не рабочий, бесполезный, не решает первоочередной проблемы. А это в пустую потраченное время, которое каждый желает тратить на важные вещи. В одной из статей, я встретил отличное высказывание: «Мусор вошёл, мусор вышел».

Где применять 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 модель

• Independent независимость — Старайтесь избегать создания US, которые зависят друг от друга.Такие зависимости порождают проблемы при расстановке приоритетов и на планировании. Заказчик может выбрать US с высоким приоритетом, которая зависит от задачи с более низким приоритетом. Зависимые US надо объединить, разбить иначе или выполнить spike.
• Negotiable обсуждаемость — US не являются формальным контрактным обязательством или требованиями. US это не техническое задание. В процессе спринта их можно и нужно обсуждать и вносить изменения. Карточка с историей, в каком бы виде она не существовала, это краткое описание функциональности, детали которых должны уточняться в ходе работы. Оставляйте на карточках примечания, чтобы породить обсуждение, когда задачу будут выполнять. Здесь важно найти золотую середину, потому что избыток заметок, команда воспримет как исчерпывающую информацию, и никакого обсуждения не будет вообще. Моя команда столкнулась с этим очень быстро. Обсужденные детали становятся тестами, которые можно записать на обратной стороне бумажной, или в комментарии к электронной карточке. Приемочные тесты, просты и понятны всем.
• Valuable ценность для пользователя или покупателя — “Каждая история должна представлять определенную ценность для пользователя” — утверждение которое является неверным. Большинство постоянно забывает про покупателя. Делайте акцент, в зависимости от вашей компании: B2C, B2B, B2G. Главное избегать историй, которые имеют ценность только для разработчиков. Такие истории следует переформулировать, чтобы стали очевидны выгоды, и заказчик смог расставить приоритеты. Не нужно выкидывать архитектурные задачи на помойку, объясните заказчику какую пользу принесет такая задача, и переформулируйте ее.
• Estimable оцениваемость — разработчики должны иметь возможность оценить размер US, то есть примерное время, которое понадобиться на реализацию. Существует три основные причины, по которым трудоемкость может не поддаваться оценке:
  
  
  1. Команде недостает знаний в предметной области
  2. Команде недостает технического опыта
  3. История слишком велика
  
  В первом и втором случае вам поможет spike. В третьем US нужно декомпозировать на более мелкие.
• Small компактность — от размера US зависит очень многое, слишком большие и слишком маленькие US сложно оценивать. С эпиками сложно работать, так как они состоят из нескольких US. Эпики можно поделить на два вида:
  
  
  1. Составные. Тут всё просто — декомпозируем. Учитывайте остальные пункты, первое что скорее всего предложит команда: поделить US по типу архитектурных слоёв: по US на базу данных, backend, frontend и так далее.
  2. Сложные. Большой размер US обусловлен самой их сутью, они либо не декомпозируются, либо это очень сложно. В данном случаем используем spike.
  
  
• Testable тестируемость — подтверждение того, что US разработана успешно, служит удачное прохождение тестов. Если US нельзя протестировать, команда не узнает, когда создание завершено, или придумает критерии сами. Причем у каждого члена команды они будут различными.

Заключение

В заключение: используя DoR, вы не избавитесь от пробелов, которые будут просачиваться в спринт. Так же это не означает, что во время спринта отпадает необходимость постоянного контакта PO с разработчиками. Постоянно фиксируйте результаты обсуждений в виде приемочных тестов, так никто из команды, не потеряет понимание статуса задачи. Проанализируйте и обсудите с командой текущие проблемы, возможно они связаны с отсутствием DoR.
DoR — артефакт, который позволит команде лучше продумывать US, что в конечном итоге снизит риски, и позволит побудить каждого члена команды к постоянному обсуждению задач. Много развернутой информации о INVEST, и User Story, вы найдете в книге «Пользовательские истории». Рекомендую дать прочитать эту книгу каждому члену команды, или хотя бы прочитайте сами и поделитесь с ними информацией.
Напишите в комментариях какие DoD и DoR используются у вас в команде.

Список литературы

1) Роман Пихлер “Управление продуктом в Scrum”
2) Майк Кон “Пользовательские истории. Гибкая разработка программного обеспечения”
3) agilealliance.org
4) linkedin.com
5) boost.co.nz
6) scruminc.com