​#знания #полезности

Флоу взаимодействия при передаче требований в разработку у нас на проекте выстроен таким образом (в нем мы привлекаем Гейм-дизайнера, Тех. лида и QA):

1. Гейм-дизайнер в данном случае у нас выполняет одну из функций БА — создает описание какого-то функционала в Confluence. Если у меня есть время, а Гейм-дизайнер занят, то описание могу создать я. Шаги флоу такие же, только на один короче.
2. Затем, передает его мне на ревью. Если у меня есть вопросы, мы их обсуждаем и правим при необходимости на месте там же (вносит правки строго тот, кто описывал фичу. Другой лишь оставляет комменты).
3. Если возникают технические вопросы в плане реализации каких-то моментов, то мы помечаем их. И после ревью с Гейм-дизом, я пингую Тех лида — договариваемся, когда он может уделить время пообщаться и ответить на вопросы.
4. Как только вопросы закрыты, я "нарезаю" стори для команды в Jira. Проверяю.
5. Затем, пингую QA для ревью этих стори. Если после ревью у него нет вопросов, то они попадают в Бэклог, откуда мы берем задачи для презентации команде. Если вопросы есть, он оставляет комментарии, и уже я дорабатываю стори.
Вот и все.

Ключевая практика — это связка работы с тех. лидом и QA. Данная практика хорошо себя показала, и работает у нас хорошо. Тех. лид и QA уже погружен частично в будущую задачу, что на презентации будет проще сориентироваться и оценить ее. А вероятность возврата задачи на доработку сократилось где-то на 45%.

Данный флоу — не 100% гарантия качества на вашем проекте. Тут может быть много нюансов. Например, размер команды, опытность участников, даже характер и отношение к работе.
Если не знаете как быть, то, как минимум, есть такая схема. А там уже можно ее подтюнить по ситуации.