Пример Definition of Ready: как мы проверяем готовность постановки на разработку

Привет, Хабр! Меня зовут Маргарита, я аналитик в департаменте e-commerce в КОРУС Консалтинг. В этой статье я хочу рассказать о том, как в нашей команде появился Definition of Ready постановки на разработку, какие аспекты в него включены и какие выгоды он приносит.

Статья будет полезна системным и бизнес-аналитикам и всем, кто работает с требованиями или процессами в команде.

Как у нас появился Definition of Ready постановки на разработку

О том, что такое Definition of Ready (DoR), я прочитала несколько лет назад в одном из материалов на Хабре. 

Если кратко, это критерии готовности задачи к передаче в разработку (или чек-лист вопросов, которые должны быть проработаны перед началом разработки). Использование DoR позволяет систематизировать подход к аналитике и исключить взятие в спринт недостаточно проработанных задач. Иногда его называют Definition of Done постановки. 

Примеры, которые я смогла найти в открытом доступе на тот момент, показались мне либо очень абстрактными, либо неполными. Из-за этого я не сразу увидела, какую ценность DoR может принести для моей работы.

Позже в процессах разработки в нашей команде закрепился и стал обязательным ритуал «3 Амиго» – встреча, на которой аналитик презентует задачу разработчикам и инженерам по тестированию, получает обратную связь и отвечает на вопросы. Более подробно об этом можно прочитать здесь. Такая встреча помогает нам экономить время команды на погружение в задачи, выяснение деталей в ходе разработки и тестирования, внесение исправлений, вызванных недостаточной полнотой требований.

Проводя эти встречи, я стала замечать, что из раза в раз коллеги задают одни и те же вопросы, если ответы на них не прописаны в постановке на разработку. Приведу некоторые примеры таких вопросов:

• А что делать с историческими записями в таблице? Нужно ли заполнить новое поле в уже имеющихся строках?

• А как данная доработка будет влиять на другой модуль системы?

• А как должна вести себя система, если пользователь перейдет на эту страницу по прямой ссылке?

Конечно, при написании следующих постановок я старалась учитывать поступившие ранее вопросы. Иногда у меня получалось вспомнить и проработать каждый из них и 3 Амиго проходило без вопросов, а иногда нет. Особенно при одновременном выполнении нескольких срочных задач для разных продуктов. В этих случаях требовалось выделять дополнительное время на завершение постановки или решать вопросы в ходе разработки и тестирования.

Так я пришла к созданию своего DoR — чек‑листа, на который удобно опираться во время работы над задачей и по которому можно проверить себя перед 3 Амиго. А когда к команде присоединились другие аналитики, чек-лист стал единым подходом к написанию постановок на разработку.

Наш текущий Definition of Ready постановки на разработку

Ниже приведены пункты чек-листа, дополненные моими комментариями. В конце статьи можно скачать вариант без пояснений.

1. В Jira созданы история и подзадачи для аналитика, дизайнера, backend-разработчика, frontend-разработчика, инженера по тестированию

Это часть принятого у нас в таск-трекере процесса. Подзадачи создаются для каждого исполнителя, а декомпозиция выполняется внутри подзадачи.

2. Указаны ссылки на связанные постановки, страницы спецификации обмена, историю в Jira

Мы указываем ссылки отдельным блоком в начале постановки, чтобы повышать удобство навигации по документации. При необходимости, ссылки также добавляются в текст постановки.

3. Сформулированы User Story и проблематика: какая именно проблема или задача бизнеса решается

User Story позволяет верхнеуровнево описать суть постановки в одном предложении.

Поиск эффективного решения проблемы всегда начинается с анализа самой проблемы. Кроме того, проблематика необходима для фиксации и донесения до всех членов команды ценности, которую принесет выполнение задачи. В проблематике описывается:

• Кто сталкивается с проблемой?

• В чем состоит проблема? Когда и как она проявляется?

• Как и на что она влияет?

• Как в настоящий момент обходят эту проблему? Какие имеются альтернативы? Почему они не являются полноценным решением?

4. Составлены Use Cases (сценарии работы пользователей)

Основные сценарии — это целевые сценарии, по которым ожидается работа пользователя в системе.

Альтернативные сценарии — это иные возможные сценарии, которые необходимо учесть при разработке. Их типовые варианты:

• Отсутствие данных для вывода или обработки. Например, пользователь вводит значение, которое должно быть проверено по таблице с настройками, но нужная настройка не задана. 

• Переход по прямой ссылке на каждую из страниц в основном сценарии. Например, по основному сценарию пользователь должен последовательно пройти по 3 страницам и ввести данные на каждой из них, но он переходит сразу на 2-ю или 3-ю страницу по прямой ссылке.

• Выход до завершения основного сценария. Например, пользователь заполняет форму и закрывает систему вместо нажатия «Сохранить». Веб-приложение может сохранить данные в LocalStorage, не сохранять данные или отобразить браузерное окно с подтверждением закрытия вкладки.

Негативные сценарии — это сценарии, обрабатывающие поведение системы при возникновении ошибок понятным для пользователя образом. Их типовые варианты:

• Транспортная ошибка в ответе сервера.

• Ошибка в ответе смежной системы при синхронном обмене.

5. Разработаны макеты для экранов шириной 1200 px, 768 px, 320 px (и др. при необходимости).

Макеты разрабатываются дизайнером в соответствии с подходом, описанном в отдельном документе. Аналитику необходимо убедиться, что все макеты отрисованы и актуализированы, и добавить ссылку на раздел в Figma в постановку.

6. Описана логика обработки данных, проверок и ограничений

7. Проверены и учтены зависимости во всех разделах системы

В подпунктах должны быть перечислены все разделы системы (шапка и подвал, авторизация, регистрация, профиль пользователя, раздел «Уведомления» и др.) Необходимо проверять, вызывают ли работы, описываемые в постановке, изменения в каждом из них. Например, при добавлении нового поля в форму регистрации необходимо определить, нужно ли выводить это поле в профиле пользователя.

8. Учтены зависимости в рассылках

В подпунктах должны быть перечислены все каналы рассылок (email, СМС, push, Telegram-бот и др.). Необходимо не только оценивать потребность в разработке новых уведомлений, но проверять, вызывают ли работы, описываемые в постановке, изменения в каждом из уже существующих.

Пункты 7 и 8 DoR могут быть объединены, но мы выделили рассылки отдельно. Описание шаблонов и логики отправки уведомлений мы также описываем в отдельном разделе, чтобы в дальнейшем не приходилось искать информацию о рассылках в разных постановках.

9. Учтены ограничения, накладываемые статусами

В подпунктах должны быть перечислены все объекты, имеющие статусные модели (договоры, заказы, обращения и др.). Для каждого объекта должна быть указана ссылка на статусную схему. Например, при добавлении возможности прикрепить файл к заказу необходимо указать, в каких статусах она должна быть доступна. 

Статусные схемы должны быть актуализированы в ходе работы над постановкой.

10.  Обновлена модель базы данных

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

11.  Оценена необходимость заполнения новых таблиц и новых полей в уже существующих таблицах данными. Данные подготовлены

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

12.  Оценена необходимость регулярной очистки данных в базе

13.  Обновлены спецификации обмена

В подпунктах должны быть перечислены все спецификации обменных процессов со смежными системами (с ERP, с CRM и др.). Спецификации должны быть актуализированы в ходе работы над постановкой. Изменения уже существующих процессов, выполняемые в рамках текущей задачи, должны быть выделены цветом.

14.  Продуман подход к сбору метрик по использованию функциональности

Основные подходы, которые мы используем – это настройка целей в Яндекс.Метрике и анализ данных в базе. При необходимости в таблицы могут быть введены дополнительные поля для сбора статистики.

15.  Постановка перечитана аналитиком. В постановке нет речевых ошибок, лишних слов, сплошных полотен текста, непонятных сокращений

Рекомендую делать это утром со свежим взглядом. Постановка должна быть удобной для чтения и понятной всем читателям: бизнес-заказчику, разработчику, представителям команд смежных систем.

16.  Если в рамках задачи создавался новый раздел/рассылка/обмен: дополнены п. 7, 8, 9, 13 DoR

Не нужно помнить об актуализации DoR, если такой пункт добавлен в DoR 🙂

17.  FE-разработчик согласовал макеты

Это еще один этап нашего процесса, который позволяет экономить время на внесение изменений при реализации.

18.  Задача согласована бизнес-заказчиком

В несогласованные задачи чаще вносятся изменения, что влияет на сроки поставки ценности для пользователя. 

19.  Проведена встреча 3 Амиго. У разработки и тестирования нет вопросов

Так выглядит наш Definition of Ready сейчас. Его первая версия содержала меньше пунктов и была менее детализирована. Мы продолжаем развивать его:

• Дополняем новыми пунктами, когда выявляем типовые вопросы или улучшаем процессы.

• Дополняем новыми подпунктами при создании функциональных блоков.

Добавлю, что при всей широте DoR в нашей команде аналитик не прорабатывает каждый пункт в одиночку. При проектировании проводятся встречи с дизайнерами и разработчиками, на которых мы вместе формируем лучшие решения. Но полнота описанных в постановке требований является зоной ответственности аналитика.

Мои основные выводы за полтора года использования Definitition of Ready

1. Не нужно пытаться удержать в голове все детали рабочего процесса и все возможные вопросы. Эффективнее сосредоточить силы на решении задачи, а типовые операции записать в чек-лист.

2. DoR удобно сделать конкретным, не пытаться унифицировать его под любую задачу. Для написания других документов эффективнее разработать отдельные чек-листы.

3. DoR, как и подход к другим процессам, может и должен постоянно актуализироваться, чтобы не становиться ограничением для команды. Мы развиваемся и получаем новый опыт, выводы из которого позволяют улучшать процессы в команде. А совместное обсуждение изменений DoR помогает обмениваться знаниями и извлекать больше пользы из любой ошибки.

Как и обещала, делюсь файлом с чек-листом без дополнительных пояснений: Definition of Ready.

Существует ли Definition of Ready задачи в ваших командах? Из каких критериев он состоит? Буду очень рада узнать о вашем опыте в комментариях