DoR и DoD — критерии контроля задач

Часто в разработке продуктовых (и не только) команд встречаются проблемы, при которых постановка и результат работы отличаются друг от друга. Обычно проблемы заключаются в том, что требования входят слабо формализованными, работа с ними проходит неструктурированно, за последовательностью валидации требований от сбора до передачи в разработку редко кто понимает, как следить.

Чтобы избежать ситуации, когда представления стейкхолдера или заказчика отличаются от конечной реализации, были придуманы разные способы контроля за процессом подготовки требований до разработки, в том числе, в какой момент считать задачу завершенной и как за всем этим следить. Подробнее об этом редакции РШУ рассказал Павел Кондратьев, старший менеджер проектов ГК Юзтех.

Как мы с вами прекрасно понимаем, требований от бизнеса в стиле «просто добавьте нам кнопочку, чтобы потом происходил magic» недостаточно, чтобы сорваться и побежать делать задачу.

На вопрос «чего будет достаточно» отвечает Definition of Ready — список критериев готовности задачи к разработке.

Как правило, команда сама для себя на установочной встрече или на любых других регулярных встречах обсуждает и регулирует этот список, который может включать в себе как минимальный базовый набор, так и развернутый чек-лист: что нужно сделать, чтобы задачу можно было взять и быстро довести через разработку до прода. Более того, в зависимости от типов задач которые нужно сделать, DoR может несущественно отличаться. Так, например, очевидно, что DoR для интеграций и небольших бизнес-фич будет разным, но какая-то часть пунктов все равно будет пересекаться.

Итак, что же может входить в подобный чек-лист? Например, на этапе discovery команде может потребоваться следующее:

1. Зафиксированные бизнес-требования.

2. Макеты дизайна.

3. Список стейкхолдеров или ЛПР.4. Критерии приемки.5. Соответствие задачи требованиям INVEST или любым другим схожим.6. Проведенный PBR или прергумминг, чтобы обстучать идею о команду и понять реализуемость и верхнеуровневые трудозатраты на разработку.

Для этапа delivery уже важны более приземленные аспекты:

1. Артефакт от аналитиков с описанием, что нужно сделать (endpoint, поля БД — все, чего по мнению команды достаточно для старта работ).

2. Проведение ревью артефактов аналитики. Да, я помню, что выше написано, что на этапе discovery уже было обсуждение. Но проверить глазами, что решение зафиксировано правильно и подготовиться к следующему пункту все равно надо.

3. Декомпозиция задач.

4. Оценка задач (лидом или нет — уже решает РП и/или команда).

5. Проведение груминга.

6. Проведение планирования.

7. Подготовлены тест-кейсы или чек-листы QA.

Как видите, получившийся список достаточно внушительный. Конечно, он очень приблизительный и может варьироваться от команды к команде. Естественно, он не полный, и возможно под ваши нужды что-то кажется лишним, а что-то вообще отсутствует. Я привел примеры тех пунктов, которые мы использовали в предыдущих командах. Однако, используя подобный чек-лист при подготовке задачи, к моменту когда будут закрыты все пункты, и у руководителя проектов, и у команды, будет полное представление о том, что при подготовке задачи постарались учесть все необходимое и ничего важного не было упущено.

Кстати, у каждого пункта, должен быть ответственный. А в идеале и сроки.

Задача уже в Done? Хорошо. А как мы с вами это поняли? А у всех ли членов команды одинаковое представление о том, что задача выполнена?

Тут нужны критерии готовности задачи — список поинтов, исходя из которых команда сама в состоянии понять, что и кому нужно сделать, чтобы задача считалась завершенной. Как пример, в списке могут быть:

1. Задача успешно прошла тестирование на dev/test-стенде (у кого как настроен релизный цикл).

2. Задача успешно прошла тестирование на stage-стенде.

3. Задача прошла бизнес-приемку (показали продакт-менеджеру или заказчику).

4. Проведен smoke-тест проекта.

5. Проведен regress-тест проекта.

6. Составлен release note. Отправлен или опубликован на заинтересованных.

7. Соблюдены критерии приемки.

8. Все отклонения зафиксированы в виде задач/багов.

9. Дизайн-ревью пройдено.

10. Задача была передана автотестерам.

11. UI-функционал покрыт метриками.

12. Функционал доступен пользователям.

13. Релиз выпущен, все задачи закрыты.

14. Техническая поддержка оповещена.

В списке может быть много пунктов. Только вам и команде решать, что действительно важно и каким критериям должна соответствовать задача, чтобы считаться завершенной. Список может быть и маленьким, и большим. Какие-то пункты внутренними регламентами могут быть расшиты на целый набор действий, которые находятся в ведении тим-лидов или отделов тестирования. Вам будет проще, если это фиксировать и отслеживать через чек-лист.

Списки мы составили, а где их вести? Вариантов и тут немало. Вы можете адаптировать для своих нужд любой планировщик, поддерживающий совместную работу. Главное, чтобы на каждую задачу он был свой. Один из самых простых вариантов — если вы используете wiki-системы для ведения документации. В этом случае критерии могут быть зафиксированы в описании к задаче, и статус может отслеживаться там. Например, отдельной страницей в Confluence. Мы же работаем с коробочной версией Jira и для контроля своих DoD/DoR используем плагин Smart Checklist. Для упрощения DoR и DoD мы ведем в одном чек-листе.

Принцип контроля достаточно прост. Если задача не прошла соответствующий контроль обязательных параметров DoR — команда не берет ее в работу, а ответственным необходимо приложить немного усилий. Для контроля чек-листа можно использовать стандартные ритуалы SCRUM, например грумминг и планирование.

Во время планирования релизов или на дейли можно обращать внимание на состояние пунктов DoD у задач, которые готовятся к релизу. Это позволит понять загрузку ребят в течение дня и позволит дополнительно сфокусироваться на том, что осталось сделать, перед тем как отправлять функционал в релиз

В качестве завершения и небольшого бонуса прикладываю шаблон чек-листа в формате плагина Smart Checklist.

#**DoR:**

- DoR Сформулированны Критерии приемки (PO)

- DoR Описан Контекст (PO)

- DoR Указаны Особенности и ограничения (PO/PM)

- DoR Задача прошла прегруминг команды (PO)

-! DoR Проведен системный анализ US (SA)

-! DoR Требования SA прошли ревью TL (SA)

-! DoR Требования SA прошли ревью QA (SA)

-! DoR Задача декомпозирована до тасок (TL)

- DoR Задача прошла груминг (SA)

x DoR Есть скор по ICE (PO)

x DoR Задача имеет оценку в SP (PO/PM)

#**DoD:**

-! **Dis** Дизайн-ревью пройдено

-! **QA** Список кейсов подготовлен. При необходимости передан АТ команды

-! **QA** Соблюдены критерии приёмки на соответствие бизнес-требованиям

-! **QA** Все отклонения реализации от требований зафиксированы в Jira в виде задач (техдолг)

-! **QA** Функциональность доступна пользователям

-! **PM** DoD Выпущен анонс о релизе на стейкхолдеров

-! **FE TL** UI-функциональность покрыта продуктовой аналитикой и метриками

В заключение хочу добавить, что всех проблем внедрение DoR/DoD не закроет, если плохо налажен процесс работы с бизнес-требованиями. Безусловно, можно обойтись и без него если разработчики спокойно относятся к работе в t-shape режиме и достаточно квалифицированы, чтобы собирать и обрабатывать требования и самостоятельно общаться со стейкхолдерами. Однако, как показывает практика, разработчики не очень любят втягиваться в эти процессы. Инвестиция времени в DoR и DoD позволяет закрыть большинство вопросов, которые появились бы у разработчика, если входящие требования обрабатывали на недостаточном уровне качества и без контроля. Что существенно сократит время на разработку. А как мы знаем, время разработчиков (как и их нервы) — бесценны.