Пример 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 постановки на разработку
Ниже приведены пункты чек-листа, дополненные моими комментариями. В конце статьи можно скачать вариант без пояснений.
В Jira созданы история и подзадачи для аналитика, дизайнера, backend-разработчика, frontend-разработчика, инженера по тестированию
Это часть принятого у нас в таск-трекере процесса. Подзадачи создаются для каждого исполнителя, а декомпозиция выполняется внутри подзадачи.
Указаны ссылки на связанные постановки, страницы спецификации обмена, историю в Jira
Мы указываем ссылки отдельным блоком в начале постановки, чтобы повышать удобство навигации по документации. При необходимости, ссылки также добавляются в текст постановки.
Сформулированы User Story и проблематика: какая именно проблема или задача бизнеса решается
User Story позволяет верхнеуровнево описать суть постановки в одном предложении.
Поиск эффективного решения проблемы всегда начинается с анализа самой проблемы. Кроме того, проблематика необходима для фиксации и донесения до всех членов команды ценности, которую принесет выполнение задачи. В проблематике описывается:
Кто сталкивается с проблемой?
В чем состоит проблема? Когда и как она проявляется?
Как и на что она влияет?
Как в настоящий момент обходят эту проблему? Какие имеются альтернативы? Почему они не являются полноценным решением?
Составлены Use Cases (сценарии работы пользователей)
Основные сценарии — это целевые сценарии, по которым ожидается работа пользователя в системе.
Альтернативные сценарии — это иные возможные сценарии, которые необходимо учесть при разработке. Их типовые варианты:
Отсутствие данных для вывода или обработки. Например, пользователь вводит значение, которое должно быть проверено по таблице с настройками, но нужная настройка не задана.
Переход по прямой ссылке на каждую из страниц в основном сценарии. Например, по основному сценарию пользователь должен последовательно пройти по 3 страницам и ввести данные на каждой из них, но он переходит сразу на 2-ю или 3-ю страницу по прямой ссылке.
Выход до завершения основного сценария. Например, пользователь заполняет форму и закрывает систему вместо нажатия «Сохранить». Веб-приложение может сохранить данные в LocalStorage, не сохранять данные или отобразить браузерное окно с подтверждением закрытия вкладки.
Негативные сценарии — это сценарии, обрабатывающие поведение системы при возникновении ошибок понятным для пользователя образом. Их типовые варианты:
Транспортная ошибка в ответе сервера.
Ошибка в ответе смежной системы при синхронном обмене.
Разработаны макеты для экранов шириной 1200 px, 768 px, 320 px (и др. при необходимости).
Макеты разрабатываются дизайнером в соответствии с подходом, описанном в отдельном документе. Аналитику необходимо убедиться, что все макеты отрисованы и актуализированы, и добавить ссылку на раздел в Figma в постановку.
Описана логика обработки данных, проверок и ограничений
Проверены и учтены зависимости во всех разделах системы
В подпунктах должны быть перечислены все разделы системы (шапка и подвал, авторизация, регистрация, профиль пользователя, раздел «Уведомления» и др.) Необходимо проверять, вызывают ли работы, описываемые в постановке, изменения в каждом из них. Например, при добавлении нового поля в форму регистрации необходимо определить, нужно ли выводить это поле в профиле пользователя.
Учтены зависимости в рассылках
В подпунктах должны быть перечислены все каналы рассылок (email, СМС, push, Telegram-бот и др.). Необходимо не только оценивать потребность в разработке новых уведомлений, но проверять, вызывают ли работы, описываемые в постановке, изменения в каждом из уже существующих.
Пункты 7 и 8 DoR могут быть объединены, но мы выделили рассылки отдельно. Описание шаблонов и логики отправки уведомлений мы также описываем в отдельном разделе, чтобы в дальнейшем не приходилось искать информацию о рассылках в разных постановках.
Учтены ограничения, накладываемые статусами
В подпунктах должны быть перечислены все объекты, имеющие статусные модели (договоры, заказы, обращения и др.). Для каждого объекта должна быть указана ссылка на статусную схему. Например, при добавлении возможности прикрепить файл к заказу необходимо указать, в каких статусах она должна быть доступна.
Статусные схемы должны быть актуализированы в ходе работы над постановкой.
Обновлена модель базы данных
В постановке должны быть описаны все необходимые изменения базы данных. Общая ER-диаграмма должна быть актуализирована. Таблицы и поля, добавляемые в рамках текущей задачи, должны быть выделены цветом.
Оценена необходимость заполнения новых таблиц и новых полей в уже существующих таблицах данными. Данные подготовлены
Написание скриптов для заполнения полей, как и ручное заполнение данных требует времени, которое должно быть учтено при планировании сроков релизов.
Оценена необходимость регулярной очистки данных в базе
Обновлены спецификации обмена
В подпунктах должны быть перечислены все спецификации обменных процессовсо смежными системами (с ERP, с CRM и др.). Спецификации должны быть актуализированы в ходе работы над постановкой. Изменения уже существующих процессов, выполняемые в рамках текущей задачи, должны быть выделены цветом.
Продуман подход к сбору метрик по использованию функциональности
Основные подходы, которые мы используем — это настройка целей в Яндекс.Метрике и анализ данных в базе. При необходимости в таблицы могут быть введены дополнительные поля для сбора статистики.
Постановка перечитана аналитиком. В постановке нет речевых ошибок, лишних слов, сплошных полотен текста, непонятных сокращений
Рекомендую делать это утром со свежим взглядом. Постановка должна быть удобной для чтения и понятной всем читателям: бизнес-заказчику, разработчику, представителям команд смежных систем.
Если в рамках задачи создавался новый раздел/рассылка/обмен: дополнены п. 7, 8, 9, 13 DoR
Не нужно помнить об актуализации DoR, если такой пункт добавлен в DoR:)
FE-разработчик согласовал макеты
Это еще один этап нашего процесса, который позволяет экономить время на внесение изменений при реализации.
Задача согласована бизнес-заказчиком
В несогласованные задачи чаще вносятся изменения, что влияет на сроки поставки ценности для пользователя.
Проведена встреча 3 Амиго. У разработки и тестирования нет вопросов
Так выглядит наш Definition of Ready сейчас. Его первая версия содержала меньше пунктов и была менее детализирована. Мы продолжаем развивать его:
Дополняем новыми пунктами, когда выявляем типовые вопросы или улучшаем процессы.
Дополняем новыми подпунктами при создании функциональных блоков.
Добавлю, что при всей широте DoR в нашей команде аналитик не прорабатывает каждый пункт в одиночку. При проектировании проводятся встречи с дизайнерами и разработчиками, на которых мы вместе формируем лучшие решения. Но полнота описанных в постановке требований является зоной ответственности аналитика.
Мои основные выводы за полтора года использования Definition of Ready
Не нужно пытаться удержать в голове все детали рабочего процесса и все возможные вопросы. Эффективнее сосредоточить силы на решении задачи, а типовые операции записать в чек-лист.
DoR удобно сделать конкретным, не пытаться унифицировать его под любую задачу. Для написания других документов эффективнее разработать отдельные чек-листы.
DoR, как и подход к другим процессам, может и должен постоянно актуализироваться, чтобы не становиться ограничением для команды. Мы развиваемся и получаем новый опыт, выводы из которого позволяют улучшать процессы в команде. А совместное обсуждение изменений DoR помогает обмениваться знаниями и извлекать больше пользы из любой ошибки.
Как и обещала, делюсь файлом с чек-листом без дополнительных пояснений: Definition of Ready.
Существует ли Definition of Ready задачи в ваших командах? Из каких критериев он состоит? Буду очень рада узнать о вашем опыте в комментариях
