Какие процессы и инструменты используются для оценки задач, проведения спринтов и ревью
Что проверяют
Как вы встраиваетесь в поток работы: умеете ли оценивать задачи, держать договорённости спринта и давать полезное ревью. Для Node.js-разработчика ревью обычно важнее ритуалов. Следом часто спрашивают, что вы делаете, когда задача явно не влезает в оценку.
Как отвечать
Опирайтесь на свою текущую команду и разбейте ответ на три части:
- оценка: story points по шкале Фибоначчи через Planning Poker или размеры футболок для грубой оценки бэклога. Смысл покера в обсуждении расхождений: если один ставит 2, а другой 13, кто-то видит миграцию базы или внешнюю интеграцию, о которой не знают остальные. Непонятная задача уходит в спайк с ограничением по времени;
- спринт: по Scrum Guide он длится не больше месяца, чаще две недели. События: планирование, дейли, обзор спринта с показом результата и ретроспектива. Задачи ведут в Jira, YouTrack, Linear или GitLab, главное, чтобы доска отражала реальный статус;
- ревью кода: пул-реквест в GitHub или GitLab, обязательный апрув,
CODEOWNERSдля критичных модулей. До человека код проходит CI: ESLint,tsc --noEmit, тесты на Jest, Vitest или встроенномnode:test. Ревьюер смотрит на логику, обработку ошибок в асинхронном коде, миграции и обратную совместимость API.
Добавьте конкретику из своего опыта: сколько длится спринт, есть ли лимит на размер пул-реквеста, сколько обычно ждёте ревью. Если работали без Scrum, например по Kanban, опишите его: лимиты WIP и cycle time вместо story points. Если процессов почти не было, скажите честно и объясните, как договаривались о сроках без них.
Где спотыкаются
Путают обзор спринта и ревью кода. Первое это показ результата заинтересованным людям, второе проверка изменений перед мержем.
Переводят story points в часы один к одному. Тогда они теряют смысл, и оценка превращается в обещание срока.
Описывают идеальный Scrum из учебника. Интервьюер быстро спросит, что у вас на самом деле шло не так, и ответ «всё работало» звучит неправдоподобно.