Требования поступали из разных источников: от стейкхолдеров (бизнес-аналитиков, product owner, заказчиков), через систему управления задачами (Jira) и на регулярных синхронизациях.
Процесс коммуникации выглядел так:
- Формулирование требований: Стейкхолдер или бизнес-аналитик оформлял требования в виде пользовательских историй, задач или эпиков в Jira. При этом использовались стандартные шаблоны, включающие описание функционала, критерии приемки, ссылки на связанные сущности и иногда макеты.
- Уточнение и декомпозиция: На митингах команды (Daily Scrum, Planning, Refinement) происходило обсуждение новых и будущих требований. Если требования были неясными или слишком объемными, проводились дополнительные уточняющие сессии (Grooming) с участием представителей бизнеса, разработчиков и QA. В процессе уточнения требования могли быть декомпозированы на более мелкие задачи.
- Документирование: Вся информация фиксировалась в Jira. Для более сложных или кросс-функциональных требований использовались Confluence-страницы, связанные с задачами в Jira. Там хранились детальные описания, flow-диаграммы, схемы баз данных, и другая необходимая информация.
- Верификация понимания: QA участвовал в обсуждении требований со самого начала (Shift-left testing подход). Это позволяло задавать вопросы, выявлять потенциальные несоответствия и неопределенности на ранних этапах, а также предлагать сценарии тестирования.
- Управление изменениями: Все изменения требований отражались в Jira/Confluence с указанием дат и инициаторов. В случае значительных изменений проводились дополнительные обсуждения и переоценка влияния на сроки и объем работ.
- Уведомления: Использовались уведомления Jira/Slack о новых задачах, изменениях статусов, комментариях.
Основные инструменты: Jira, Confluence, Slack, инструменты прототипирования (Figma и др., ссылки на макеты вставлялись в описание задач).
Такой подход обеспечивал прозрачность, своевременное уточнение и общее понимание требований всеми членами команды.