> Какие процессы и методологии используются в команде

Короткий ответ

В командах уровня senior обычно сочетают Agile-фреймворки с инженерными практиками. Чаще всего это Scrum или Kanban для планирования, плюс CI/CD, code review, trunk-based development и парное программирование. Методологии выбирают под контекст: продуктовые команды тяготеют к Scrum, платформенные и инфраструктурные - к Kanban. Ключевой критерий зрелости - не название фреймворка, а предсказуемость поставки и качество обратной связи.

Подробное объяснение

На уровне senior ожидается понимание, что процессы - это инструмент, а не догма. Обычно выделяют несколько слоёв. Первый слой - фреймворк управления работой: Scrum с фиксированными спринтами и ролями, Kanban с непрерывным потоком и WIP-лимитами, либо гибридные модели вроде Scrumban. Второй слой - инженерные практики: CI/CD, обязательный code review, trunk-based development, feature flags, автоматизированное тестирование. Третий слой - ритуалы обратной связи: ретроспективы, post-mortem без поиска виноватых, регулярные one-on-one. Четвёртый слой - метрики: lead time, cycle time, deployment frequency, change failure rate, MTTR. Senior понимает trade-off между предсказуемостью и гибкостью: жёсткий Scrum даёт прогнозируемость, но плохо переносит срочные внеплановые задачи, а Kanban гибок, но требует дисциплины по WIP-лимитам. Также важно учитывать масштабирование: SAFe, LeSS или Spotify-модель применяют в крупных организациях, но они добавляют координационные издержки. Зрелая команда адаптирует процесс под себя и регулярно его пересматривает на ретроспективах.

На практике

В реальной работе процесс выглядит так. Планирование спринта или наполнение бэклога раз в одну-две недели. Ежедневные стендапы на 15 минут для синхронизации, а не для отчётов. Разработка ведётся в короткоживущих ветках или напрямую в trunk с feature flags. Каждый pull request проходит code review минимум одним инженером и автоматические проверки в CI. Деплой в прод происходит несколько раз в день через пайплайн. Инциденты разбираются на blameless post-mortem с action items. Ретроспектива в конце итерации даёт конкретные улучшения процесса. Метрики DORA отслеживаются, но не превращаются в KPI для наказания. Если команда распределённая, добавляются асинхронные практики: письменные обновления, записанные демо, документация решений через ADR.

Пример кода

Пример конфигурации CI-пайплайна, который поддерживает trunk-based development и быстрый feedback loop.

YAML
name: ci
on:
  pull_request:
  push:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage
      - run: npm run build

Как отвечать на собеседовании

Стоит показать, что вы понимаете процесс как систему обратной связи, а не как набор ритуалов. Начните с того, какие фреймворки вы использовали и почему. Опишите, как команда принимала решения: где был Scrum, где Kanban, и что это давало. Упомяните инженерные практики: code review, CI/CD, trunk-based development, feature flags. Приведите метрики, по которым вы оценивали эффективность процесса. Расскажите про конкретный случай, когда вы изменили процесс и какой был измеримый результат. Если спросят про масштабирование, честно скажите про trade-off между координацией и автономией команд.

Что проверяет интервьюер

Проверяется зрелость суждений, а не знание названий фреймворков. Интервьюер хочет услышать, что вы умеете адаптировать процесс под контекст, а не слепо следовать книге. Важно, понимаете ли вы связь между процессом и качеством поставки. Также проверяется опыт работы с метриками и способность улучшать процесс на основе данных. Отдельно оценивается умение работать в команде: как вы даёте и принимаете обратную связь, как участвуете в ретроспективах и post-mortem.

Типичные ошибки

Называть Scrum единственно правильным подходом и игнорировать контекст. Путать ритуалы с ценностями Agile. Считать, что процесс важнее результата. Не упоминать инженерные практики, ограничиваясь планированием и стендапами. Использовать метрики как инструмент наказания, а не улучшения. Игнорировать trade-off при масштабировании на несколько команд. Рассказывать только теорию без конкретных примеров из практики.