Аналитики работают по спринтам?
Что проверяют
Как вы встраиваетесь в ритм команды разработки и понимаете ли, что аналитик обычно работает на шаг впереди спринта. Следом спрашивают, как вы готовите задачи к планированию и что делаете, если требования к нему не готовы.
Как отвечать
Короткий честный ответ: да, в скрам-командах аналитик живёт в тех же спринтах, но его работа сдвинута вперёд. Пока разработчики делают текущий спринт, аналитик готовит требования на следующий, иначе на планировании нечего брать. Дальше опишите свой цикл:
- рефайнмент: вы приносите истории с критериями приёмки, макетами и контрактами API, команда задаёт вопросы и оценивает;
- Definition of Ready: договорённость, без чего задача не берётся в спринт. Например, согласованы критерии приёмки, описаны ошибки и крайние случаи, есть макет;
- внутри спринта: отвечаете разработчикам и тестировщикам, уточняете, но не переписываете требования на ходу. Изменение объёма обсуждается с владельцем продукта;
- обзор спринта: показываете результат заказчику, обратную связь переводите в бэклог;
- ретроспектива: разбираете, где требования подвели.
Назовите инструменты, с которыми работали: Jira или YouTrack для бэклога, Confluence для спецификаций, Miro или Figma для схем. Если команда жила по Kanban, так и скажите: тогда у аналитика своя стадия проработки на доске, а не спринт. Бывает и двухтрековая схема, когда discovery и delivery идут параллельно.
Нужны ваши примеры: длина спринта, сколько историй вы готовили, случай, когда задача вернулась из разработки из-за дыры в требованиях. Если по спринтам вы не работали, не придумывайте. Скажите, в каком процессе работали, и покажите, как перенесли бы свою практику в скрам.
Где спотыкаются
Пересказывают Scrum Guide и ни слова не говорят о своей роли. Интервьюеру нужен ваш процесс, а не определения.
Не упоминают опережение на спринт. Звучит так, будто требования пишутся в том же спринте, где их реализуют, а это сигнал хаоса.
Путают роли: в Scrum Guide нет должности аналитика, он входит в число разработчиков (Developers). Называть себя владельцем продукта без реальных полномочий по приоритетам не стоит.