Нам известно, что и Definition of Ready, и Definition of Done означают готовность задачи. Из-за этого у многих появляется путаница. На неё накладываются особенности перевода и его варианты в разных источниках. В итоге получается, что какие-то команды используют DoR и DoD как синонимы, кто-то предпочитает что-то одно, а кто-то никак не может решить. Давайте вместе разберёмся, в чём разница между критериями «Подготовлено» и «Сделано», или DoR и DoD.
Чтобы понять разницу, нужно начать издалека
Одним из ключевых артефактов в Scrum является бэклог. Он существует на уровне продукта и на уровне спринта.
Все элементы, которые владелец продукта считает нужным реализовать, попадают в бэклог продукта. Итемы (PBI) в нём детализированы по-разному. Те, что находятся выше, должны быть достаточно проработаны. Те, что попадут в работу нескоро и находятся ниже, могут выглядеть как примерные наброски. Бэклог постоянно меняется, истории из него уходят в работу, какие-то разделяются, что-то теряет актуальность.
Бэклог продукта — источник для бэклога спринта. Последний — это зона ответственности команды. Разработчики выбирают PBI из бэклога, составленного владельцем продукта, и формируют свой на следующий спринт. После согласования и принятия обязательств, бэклог спринта обычно не изменяется.
Подробная статья про бэклог и его составление
DoR vs. DoD
Спринт — это цикл разработки, ограниченный по времени, в который берутся высокоприоритетные истории из бэклога продукта. Истории реализовываются, и задачи превращаются в инкремент продукта.
Но для того, чтобы взять элементы бэклога в текущий спринт, важно, чтобы самые приоритетные пользовательские истории были «подготовлены» (такой вариант перевода используется в русскоязычном ScrumGuide). Это и есть Definition of Ready.
Если DoR отсутствует, то есть критерии не установлены для истории, то такие истории вызовут проблемы: могут возникнуть дополнения на ходу, неучтённый объём работы, а что хуже, непродуманная задача окажется бесполезной.
Если разработчики забирают в работу недостаточно подробные или определённые User Stories, они рискуют.
Определение истории как READY основано на трёх принципах. История должна быть:
- ясной,
- выполнимой,
- проверяемой.
Пользовательская история ясна, если все члены scrum-команды понимают, что она значит. Совместное придумывание User Stories на груминге и их обсуждение повышают ясность.
История считается выполнимой, если команда может полностью реализовать её за один спринт. Если это невозможно, историю нужно разбить на более мелкие.
История проверяема, если есть способ определить, работает ли функция, как от неё ожидалось. Это гарантируют критерии приёмки (Acceptance criteria).
Definition of Ready находится на уровне бэклога и устанавливается до начала планирования спринта.
Примеры DoR:
- пользовательская история ясна,
- ее можно проверить,
- ее можно реализовать,
- определены критерии приёмки,
- учтены зависимости от других историй,
- есть критерии эффективности, масштабируемости, безопасности, если это необходимо,
- размер истории подходит scrum-команде,
- известен тот, кто принимает сделанную историю, и он знает об этом,
- разработчикам понятно, как продемонстрировать законченную историю.
Definition of Done фокусируется на уровне спринта или релиза. DoD составляется самой командой на планировании. В списке требований зафиксировано, что нужно выполнить для определённой истории, чтобы она могла попасть в графу DONE на доске.
Definition of Done — это соглашение между командой разработки и владельцем продукта о том, что считать за минимальные критерии, когда история считается «Сделанной». В русском переводе ScrumGuide используется термин «Критерии Готовности», и этот вариант вносит путаницу, потому что «готово» также относится к ‘ready’.
DoD варьируется от спринта к спринту. Промежуточные спринты могут иметь менее строгие критерии, тогда как DoD крупного релиза будет более серьёзным.
В DoD могут отражаться стандарты компании, например, в отношении качества кода. Всё это прописывается на этапе планирования.
Примеры DoD:
- код написан,
- код прокомментирован, проверен, запущен,
- код проверил наставник или коллега (если это заведено),
- код запускается без ошибок,
- модульные тесты написаны и выполняются без ошибок,
- системные тесты выполняются,
- новая сборка задокументирована и т. д.
В реальной задаче DoD прописываются более детально.
Первоначальная цель DoR и DoD заключалась в создании краткой документации. Она использовалась как внутреннее соглашение между заинтересованными сторонами и scrum-командой.
Когда большая часть разработки основывается на аутсорсинге или субподряде, DoR и DoD используются и в контрактах. Эти критерии выражают ожидания от того, что нужно сделать и насколько высоки требования к качеству.
DoR помогает заказчику создавать хорошо написанные пользовательские истории, которые готовы для разработки. DoD помогает проверить работу в соответствии со всеми требованиями проекта, а не только продемонстрировать, что функционал запускается.