Scrum vs Kanban на собеседовании системного аналитика

Зачем спрашивают на собесе SA

Agile — стандарт IT-разработки. SA должен встраиваться в процессы команды. На собесе SA: «отличие Scrum и Kanban», «зачем Sprint Review», «что делает SA на ритуалах». Senior — нюансы scaled Agile (SAFe, LeSS), метрик, антипаттернов.

Главная боль без понимания — SA приходит из waterfall, на ритуалах не знает, что говорить, ставит требования в начале спринта блок-схемой и удивляется, почему команда переоценивает задачи.

Scrum: основные элементы

Роли:

• Product Owner (PO) — отвечает за бэклог, приоритизацию, ценность.
• Scrum Master (SM) — фасилитирует процесс, убирает препятствия.
• Development Team — кросс-функциональная команда, 5-9 человек.

В РФ часто SA — отдельная роль (вне Dev Team по Scrum Guide). На практике SA вписывается как член команды или близко к PO.

Артефакты:

• Product Backlog — приоритизированный список фич. Owner — PO.
• Sprint Backlog — то, что взяли в текущий спринт.
• Increment — то, что готово к концу спринта (соответствует DoD).

События (ceremonies):

• Sprint Planning (1-4 ч) — что сделаем в спринт.
• Daily Stand-up (15 мин) — что сделал, что планируешь, что блокирует.
• Sprint Review (1-2 ч) — демо инкремента стейкхолдерам.
• Sprint Retrospective (1-2 ч) — рефлексия процесса, улучшения.

Sprint — фиксированная итерация (обычно 2 недели). На бакле спринт — длиннее (3-4 недели). На стартапах — 1-2 недели.

DoR / DoD — Definition of Ready (что нужно для старта) / Definition of Done (что нужно для завершения).

Kanban: основные принципы

Без ролей (можно использовать существующие — PM, Tech Lead и т.д.).

Без спринтов. Continuous flow.

Доска — визуализация workflow:

| Backlog | To Do | In Progress | Review | Done |
| WIP: ∞  | WIP: 5| WIP: 3      | WIP: 2 | WIP: ∞|

WIP-лимиты — главная фишка. Ограничение количества задач в каждой колонке. Цель — найти боттлнек, ускорить flow.

Принципы:

• Визуализируй workflow.
• Ограничь WIP.
• Управляй потоком (flow).
• Делай политики явными.
• Внедряй петли обратной связи.
• Улучшай по необходимости.

Никаких обязательных ритуалов. Часто всё равно используют daily, replenishment meeting (вместо planning), service delivery review (вместо review).

Метрики и фокус

Scrum:

• Velocity — сколько story points команда закрывает за спринт.
• Sprint Goal achievement — достигнута ли цель спринта.
• Burndown chart — прогресс по спринту.

Kanban:

• Cycle time — от старта работы до Done.
• Lead time — от создания задачи до Done.
• Throughput — задач за единицу времени.
• Cumulative Flow Diagram — визуализация WIP по колонкам с течением времени.

Главное отличие: Scrum — фокус на спринтовой цели, time-boxed. Kanban — фокус на flow, continuous.

Когда что выбирать

Scrum подходит:

• Продуктовая разработка с long-term roadmap.
• Команда стабильна, scope относительно предсказуемый.
• Нужны регулярные демо стейкхолдерам.
• Команда новая в Agile — даёт структуру и ритуалы.

Kanban подходит:

• Поддержка / эксплуатация (инциденты непредсказуемы).
• Maintenance / bug-fixing.
• Pipeline аналитики, где задачи разной природы.
• Команда зрелая, не нуждающаяся в строгой структуре.
• High-priority interrupts частые (не помещаются в спринт).

Combo (Scrumban):

• Продуктовая команда, но с непредсказуемыми срочными задачами (поддержка + features).

Scrumban — гибрид

Берёт из Scrum:

• Время-боксы (planning, retro каждые 2 недели).
• Backlog с приоритизацией.

Берёт из Kanban:

• WIP-лимиты.
• Continuous flow в течение спринта.
• Без жёсткого «спринт-планирования», задачи pull-based.

В РФ многие команды реально работают по Scrumban, называя это «Scrum».

Роль SA в Scrum / Kanban

На Sprint Planning / Replenishment. Помогает PO детализировать stories, разбираться в технических ограничениях. Ставит уточняющие вопросы.

На Daily. Что блокирует — например, не получили ответ от внешней команды по интеграции. Что ускоряет — финализирована схема API.

На Sprint Review. Помогает презентовать функционал бизнесу, отвечать на вопросы по требованиям.

На Retro. Участвует в улучшении процесса, особенно по части документации, постановки задач.

Между ритуалами.

• Уточнение требований (refinement).
• User stories + AC для backlog.
• API-контракты, ER-диаграммы, sequence-схемы.
• Координация с внешними командами (интеграции).

Если SA — отдельная роль (вне Dev Team). Тогда часто работает как «proxy PO» или внутри trio с PM/Tech Lead, помогая трансформировать бизнес-задачи в техническую постановку.

Частые ошибки

Скрам как «дейли + спринт-планинг» без сути. Без ретро, без DoD, без commitment'a — это не Scrum, это карго-культ.

Жёсткий Scrum в поддержке. Спринт ломается каждый день срочными инцидентами. Лучше Kanban.

Kanban без WIP-лимитов. Доска без ограничений — просто список задач. Нет давления на flow.

Слишком частые митинги. Daily 30+ мин, planning 4 часа, retro каждую неделю — выгорание команды. Сокращай ритуалы под realnost.

SA приходит на planning без подготовки. AC должны быть готовы до планинга. Иначе planning превращается в «давайте обсудим, что это за фича».

Story points как KPI. Velocity — внутренний измеритель команды, не KPI для бизнеса. Превращение в KPI портит честность оценок.

Игнорировать ретро. Retro — единственное место для улучшения процесса. Скип = застой.

Sprint = waterfall на 2 недели. «Спринт-планинг → разработка → review → деплой только в конце» — это микро-waterfall. Делать инкремент быстрее, кусочками.

Связанные темы

• User Stories и Acceptance Criteria для SA
• Acceptance Criteria Given/When/Then на собесе SA
• ТЗ vs SRS на собесе SA
• UML Use Case на собесе SA
• Подготовка к собесу системного аналитика

FAQ

Что лучше для команды из 3 человек?

Часто Kanban — Scrum-ритуалы для маленькой команды overhead'нуты. Если есть стейкхолдеры, требующие демо, — короткие Scrum-спринты.

Можно ли использовать story points в Kanban?

Можно, но обычно метрика Kanban — cycle time / throughput, а не velocity. Story points в Kanban избыточны.

Что такое SAFe?

Scaled Agile Framework — структурированный подход для скейлинга Agile на 50-150+ человек. Несколько уровней (Team / Program / Portfolio). В РФ применяется в крупных банках и телекомах.

Чем PO отличается от PM?

В Scrum-команде PO отвечает за бэклог. PM (Product Manager) — шире: стратегия, рынок, roadmap. На малой команде один человек выполняет обе роли. В крупном продукте — это разные люди.

Bug — как обрабатывается в Scrum?

Critical bug — interrupt, ломает спринт. Non-critical — добавляется в backlog, приоритизируется PO.

Это официальная информация?

Нет. Статья основана на Scrum Guide (2020), материалах Kanban Method (David Anderson) и опыте Agile-команд.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.