Привет! Я почти 20 лет работаю в ИТ-разработке в разных ИТ-компаниях, командах, ролях. И работал по разным методологиям. В этой статье хотел бы поделиться командным опытом, полученным в работе в SCRUM-командах за последние 5-7 лет, и своими взглядами на процессы постановки задач для команд разработки.

Поделюсь нашим опытом организации и проведения уточнения бэклога продукта (Product Backlog Refinement) при работе по SCRUM.

Все, что описано по этому процессу в SCRUM guide заключено в одном абзаце:

Элементы Product Backlog, которые могут быть реализованы Scrum Team до состояния готовности в течение одного Sprint, считаются готовыми для взятия в Sprint в ходе события Sprint Planning. Они достигают такого уровня прозрачности после активностей по уточнению. Уточнение Product Backlog — это процесс разбиения элементов Product Backlog на более мелкие и конкретные элементы, и их дальнейшего уточнения. Это постоянная деятельность по добавлению деталей, таких как описание, порядок и размер. Атрибуты элементов зависят от предметной области выполняемой работы и могут быть очень разными.

Definition of Ready (DoR)

Исходя из того, что процесс детализации элементов бэклога продукта организовывает сама команда и владелец продукта, то необходимость и степень детализации конкретного определяют команда и владелец продукта, договариваясь между собой. Часто критерии готовности элемента бэклога для взятия командой в реализацию в спринте оформляются в виде чек-листа, называемого Definition of Ready.

Информации на тему Definition of Ready (DoR) в русскоязычном сегменте сети не так уж и много, но эта тема достойна отдельной статьи. Важно, что список критериев/чек-лист может развиваться и дополняться командой по мере развития процессов, например, решениями на ретро. Можно начать с малого-реального, а не с какого-то далекого будущего-идеального. Но даже небольшой первый список критериев лучше зафиксировать письменно при обсуждении в команде. Это поможет всем участникам однозначно понимать каждый из пунктов и иметь возможность вернуться к этому списку в любой момент времени.

Один из важных пунктов, который имеет смысл включать начиная с первых версий — это критерии приемки. Это перечень проверок/шагов, понятных каждому в команде (включая специалистов по тестированию), которые требуется выполнить, чтобы проверить, что элемент бэклога реализован, и реализация соответствует требованиям/ожиданиям владельца продукта.

Для примера, приведу первую версию DoR, с которого мы начали работать в команде:

• задача зафиксирована в письменном виде: в Jira и/или связана с статьей в Confluence;

• в задаче сформулирована ценность для пользователя продукта, процесса или команды разработки;

• задача понятна всем членам команды;

• в задаче сформулированы критерии приемки;

• в задаче есть макеты интерфейса (если они требуются);

• задача может быть выполнена в рамках одного спринта;

• указаны зависимости задачи от других задач, если они имеются.

Владелец продукта – ключевой участник процесса PBR

Итак, мы договорились о критериях, которые должны быть выполнены в процессе уточнения элементов бэклога. Теперь вернёмся к нашей цели — каким образом мы будем проводить уточнение элементов бэклога? Ключевой участник этого процесса – владелец продукта. Если владелец продукта не вкладывается в уточнение элементов бэклога, то команда не будет эффективно работать и вкладываться в создание инкремента. Владельцу продукта помогает в процессе PBR вся команда. Конечно, это идеальный вариант, по факту же — это делают наиболее активные из участников.

Сначала владелец продукта самостоятельно или с помощью аналитиков начинает формулировать и фиксировать задачу в бэклоге, в письменном виде в Jira и в статьях на Confluence. Этот процесс у нас ещё строго не формализован и зависит от текущей загруженности и личной ответственности самого владельца продукта. Но мы регламентировали и поставили в постоянное расписание еженедельную встречу уточнение бэклога продукта (Product Backlog Refinement), которую проводит владелец продукта. Он представляет команде те задачи, которые он хотел бы взять в следующий спринт и обсуждает их с командой. Такая регулярность дисциплинирует и Владельца продукта и команду.

Пока у нас нет строгой формализации процесса проведения самой встречи, владелец продукта проводит её без жесткого сценария. Для примера я нашел визуализацию одного из вариантов сценария на scrum.org в статье Product Backlog Refinement explained (3/3).

Наши практики

Перед PBR встречами владелец продукта может собирать часть команды для предварительного уточнения и декомпозиции больших и сложных задач. Как и в большинстве случав — у нас не идеальная SCRUM-команда, в которой все могут сделать всё и разбираются во всём. Поэтому такие задачи мы стараемся предварительно декомпозировать, обсуждая с участниками команды, имеющими различную ИТ-специализацию. В обсуждении принимают участие представители всех ИТ-специализаций: аналитик, backend-разработчик, front-разработчик, дизайнер и специалист по тестированию. В обсуждение крупных задач, требующих изменений архитектуры системы, дополнительно привлекаем архитектора.

Привлечение представителей всех ИТ-специализаций требуется для того, чтобы посмотреть на задачу со стороны всех её будущих исполнителей, сформировать наиболее полное разбиение задачи на подзадачи и постараться не упустить каких-то существенных спорных моментов. Чтобы потом в спринте не потребовалось дополнительное время и исследования для решения внезапно возникшей в процессе реализации задачи проблемы.

В процессе такой проработки мы стараемся:

• сформировать набор детальных подзадач (на каждого исполнителя своя подзадача/набор подзадач);

• учесть взаимозависимости между ними;

• дополнить и уточнить исходные формулировки требований в Jira и Confluence;

• согласовать и подготовить изменения в макеты форм;

• спроектировать и описать требуемые API endpoint для front-разработчика и backend-разработчика;

• описать изменения в базе данных сервисов;

• обсудить, как мы будем принимать задачу, на каких тестовых данных;

• решить, какие из тестов будем автоматизировать сразу;

• сформулировать критерии приемки.

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

Например, если заранее договориться о требуемых API endpoint’ах для front-разработчика и backend-разработчика, то в спринте они смогут уже независимо друг от друга начать работу над задачей, а тестировщик начнёт работу над автотестом.

Такие встречи позволяют нам не отрывать всю команду от работы над задачами текущего спринта. На общее обсуждении мы выносим заранее декомпозированную задачу. Таким способом мы сокращаем затраты рабочего времени на встречу PBR, в которой участвует вся команда. Также сокращаем время встречи для планирования спринта, потому что все участники команды к планированию знают все основные задачи, которые мы хотели бы взять в работу в ближайший спринт, и могут детальнее посмотреть подзадачи по ним в удобное время. На планировании остается актуализировать их приоритеты, оценки и понять, какой объем реально выполнить в ближайшем спринте.

Подведём итоги

Обсуждая наши изменения на ретро, многие участники команды говорили, что такие встречи PBR:

• уменьшают количество звонков/встреч по уточнению задач, взятых в работу в спринт;

• повышают уверенность участников команды в том, что взятые задачи будут действительно выполнены в рамках этого спринта;

• ускоряют процессы тестирования;

• усиливают вовлеченность в проект;

• дают понимание направлений дальнейшего развития продукта.

Возвращаясь к вопросу в заголовке этой статьи, в команде мы считаем, что регулярный процесс PBR является нашей инвестицией в текущее развитие продукта. Часы планирования и проектирования экономят в будущем дни разработки и тестирования. И, конечно, нам ещё есть куда расти в оптимизации наших рабочих процессов, поэтому будем очень рады, если вы захотите поделиться своим опытом и лучшими практиками в комментариях.

Дополнительные ссылки на полезные, на мой взгляд, статьи на эту тему:

Формализованная статья о пользе, которую приносит Product Backlog Refinement - The Art of Product Backlog Refinement

Один из способов формализации Product Backlog Refinement в 3 частях:

• Product Backlog Refinement explained (1/3)

• Product Backlog Refinement explained (2/3)

• Product Backlog Refinement explained (3/3)