Используете ли вы Kanban или Scrum
Что проверяют
Как вы встраиваетесь в процесс команды и понимаете ли, зачем нужны его элементы, а не только их названия. Следом обычно спрашивают, что вам нравилось и не нравилось в процессе прошлой команды и как фронтенд уживался с зависимостями от бэкенда и дизайна.
Как отвечать
Опишите процесс по фактам своей команды:
- если был Scrum: длина спринта (по Scrum Guide не больше месяца, чаще две недели), события: планирование, дейли, обзор спринта, ретроспектива. Роли: Product Owner, Scrum Master, разработчики. Как оценивали задачи: story points, planning poker, часы;
- если был Kanban: колонки доски и где у фронтенда узкие места (ревью, тестирование, ожидание API), лимиты WIP, по каким метрикам смотрели поток: cycle time, lead time, пропускная способность;
- инструменты: Jira, YouTrack, Linear, GitHub Projects. Как задача связана с веткой и пул-реквестом, как фронтенд-фича доходит до релиза, есть ли feature flags.
Добавьте фронтовую специфику: как вы нарезали большую фичу на вертикальные куски, которые можно показать на обзоре, как работали, пока бэкенд не готов (договорились о контракте API, подняли моки через MSW), как дизайн попадал в спринт до разработки, а не параллельно с ней.
Сильный ответ содержит ваше мнение: Scrum удобен, когда продукт развивается фичами и нужен ритм показа результатов, Kanban подходит для поддержки и потока разнородных задач, многие команды живут в гибриде. Если формального процесса не было, скажите об этом и опишите, как вы организовывали работу сами: задачи в трекере, приоритеты, регулярная синхронизация с заказчиком.
Где спотыкаются
Сводят Scrum к ежедневным созвонам. Если вы не можете сказать, зачем нужны ретро и обзор спринта, это выглядит как участие без понимания.
Называют Kanban «просто доской с задачами». Без лимитов WIP и работы с потоком это не Kanban, а список дел в колонках.
Критикуют процесс прошлой команды общими словами: «Scrum у нас не работал». Лучше конкретно: что именно не работало, что вы предлагали и что изменилось.