Scrum — итоги раздела
Миграции в инкременте — Пакетная работа; проверка — SQL для тестировщика.
Кратко — что стоит унести из раздела Scrum. Если пункт кажется туманным — откройте указанную главу или оглавление. Диагностика процесса — в чек-листе.
FAQ — Часто задаваемые вопросы
Типичные боли после "внедрения Scrum" — спринты без инкремента, PO в отпуске, velocity как KPI. Здесь — что происходит и что менять; чек-боксы для аудита — в чек-листе.
Вопрос. У нас спринты по две недели, но релиз раз в квартал — это Scrum?
Ответ. Спринт без рабочего инкремента по DoD — формальность. Либо сократите DoD до реально releasable куска, либо честно назовите процесс иначе. Подробнее здесь — глава 4, глава 5.
Вопрос. Product Owner "на совмещении" и появляется раз в месяц.
Ответ. Без доступного PO команда не может приоритизировать — растёт WIP и "почти готово". Нужен делегат с полномочиями или уменьшение scope спринта. Подробнее здесь — глава 2, глава 3.
Вопрос. Scrum Master раздаёт задачи и спрашивает проценты — так и должно быть?
Ответ. Нет: SM фасилитирует процесс, Developers сами берут работу из Sprint Backlog. Статус-рапорт директору на Daily — антипаттерн. Подробнее здесь — глава 3.
Вопрос. В спринт постоянно "подкидывают срочняк" от директора.
Ответ. Scope меняют через PO и пересмотр Sprint Goal, не в обход. Иначе это Kanban без WIP-лимитов и с театром спринтов. Подробнее здесь — глава 4, глава 7.
Вопрос. Velocity упала — нас наказывают на ретро.
Ответ. Velocity — для планирования, не KPI наказания. Падение сигнализирует о блокерах, техдолге или завышенных оценках — разбирайте причину, а не "кто виноват". Подробнее здесь — глава 4, глава 6.
Вопрос. Story points переводят в часы для отчёта CFO.
Ответ. Линейный перевод points → деньги ломает смысл относительной оценки. Для бюджета — отдельные метрики (burn-up, scope, T&M). Подробнее здесь — глава 6.
Вопрос. Sprint Review превратился в слайды "готовность 80%".
Ответ. Review — демо работающего продукта, не отчёт. Если показать нечего — это сигнал о DoD и прозрачности, а не повод для PowerPoint. Подробнее здесь — глава 4.
Вопрос. Retrospective "нет времени" уже полгода.
Ответ. Без ретро команда не адаптируется — повторяются одни потери (Lean). Минимум 1–3 улучшения на следующий спринт — обязательство Scrum. Подробнее здесь — глава 5, глава 7.
Вопрос. Daily длится 40 минут — как укоротить?
Ответ. Фокус на Sprint Goal и блокерах; детали — после встречи. SM режет оффтоп и переносит обсуждения. Подробнее здесь — глава 2, глава 3.
Вопрос. Definition of Done есть в Confluence, но в prod не деплоим.
Ответ. DoD должен быть проверяемым: CI, тесты, ревью, деплой на staging минимум. "Готово на dev" — не Done для software-команды. Подробнее здесь — глава 5.
Вопрос. Команда 15 человек в одном Scrum — нормально?
Ответ. Scrum Guide — до 10 в одной команде; больше — декомпозиция на потоки (Scrum of Scrums, Nexus). Иначе Daily и Planning не масштабируются. Подробнее здесь — глава 3.
Вопрос. Waterfall в контракте, Scrum внутри — как не сойти с ума?
Ответ. Гибрид Water-Scrum-Fall: юридически фиксируют вехи, внутри — спринты и инкременты. Важно согласовать приёмку с DoD. Подробнее здесь — глава 1, SDLC.
Вопрос. Kanban для поддержки, Scrum для фич — как стыковать?
Ответ. Scrumban: разные потоки, общий бэклог и WIP-лимиты; инциденты не должны каждый спринт срывать Sprint Goal без правил. Подробнее здесь — глава 5.
Вопрос. Backlog refinement только в первый день спринта — хватает?
Ответ. Обычно нет: refinement регулярный, чтобы Planning не превращался в марафон уточнений. Готовые items — с AC и оценкой. Подробнее здесь — глава 6.
Вопрос. "Почти готово" висит на доске две недели.
Ответ. Признак multitasking и не-DoD: дробите задачи, лимитируйте WIP, доводите до Done. Подробнее здесь — глава 5.
Вопрос. Заказчик не ходит на Review — имеет смысл Scrum?
Ответ. Без обратной связи теряется адаптация — остаётся внутренний конвейер. Минимум — делегат PO с правом решений или смена процесса. Подробнее здесь — глава 2, глава 7.
Вопрос. Сверхурочки каждый спринт "чтобы успеть".
Ответ. Команда переоценивает capacity или scope не режется. Систематические овертаймы — техдолг и выгорание; velocity после этого ненадёжна. Подробнее здесь — глава 5, глава 7.
Вопрос. Burndown "идеальный", а фичи не в prod — обман?
Ответ. Часто закрывают задачи без DoD или скрывают незавершёнку. Burndown должен отражать Sprint Backlog к Done, не к "dev complete". Подробнее здесь — глава 4.
Вопрос. Нет CI — можно "Agile без автотестов"?
Ответ. Инкремент без автоматической проверки хрупкий — Scrum для software предполагает инженерные практики под DoD. Подробнее здесь — глава 5, тестирование.
Вопрос. SAFe / LeSS — нам обязательно масштабировать Scrum?
Ответ. Масштабирование нужно при нескольких зависимых командах; одной команде 5–9 человек достаточно базового Scrum. Подробнее здесь — SDLC, глава 7.
Вопрос. Sprint Goal сформулировали размыто — "улучшить производительность".
Ответ. Цель должна быть измеримой и общей для команды на спринт ("p95 API < 200 ms на checkout"). Иначе Daily теряет фокус. Подробнее здесь — глава 4.
Вопрос. Аналитик пишет ТЗ на весь релиз, Developers "по Scrum" — конфликт?
Ответ. Тяжёлый upfront ТЗ душит адаптацию. Переносите детализацию в refinement и бэклог; документ — живой, не замороженный. Подробнее здесь — глава 6, аналитика.
Вопрос. Кейс ФБР Sentinel — "Scrum не работает"?
Ответ. Урок — отсутствие инкремента и обратной связи, а не "Agile плохой". Без working software и вовлечённого заказчика любой процесс провалится. Подробнее здесь — глава 1.
Вопрос. С чего начать, если нас "пересадили на Scrum" за неделю?
Ответ. 11 шагов внедрения: роли, длина спринта, DoD, одна доска, честный Review. Не покупайте сертификаты раньше практики. Подробнее здесь — глава 7.
Вопрос. Scrum Master без полномочий снять организационный блокер.
Ответ. SM эскалирует через видимость (impediment list, ретро) к тем, кто может решить. Без поддержки руководства Scrum деградирует в театр. Подробнее здесь — глава 3, глава 7.
Вопрос. Госсектор требует акты по ГОСТ — Scrum "запрещён"?
Ответ. Формальная приёмка и спринты совместимы через вехи, ПМИ и traceability; см. гибриды в материалах по ГИС. Подробнее здесь — методологии ГИС, глава 1.
FAQ — Поисковые запросы
Краткие ответы на формулировки, которые часто вводят в Google и Yandex.
Вопрос. Что такое Scrum простыми словами?
Ответ. Фреймворк Agile: спринты 1–4 недели, роли PO/SM/Developers, инкремент в конце, пять событий для прозрачности. Подробнее здесь — зачем Scrum, роли и события.
Вопрос. Scrum vs Agile — в чём разница?
Ответ. Agile — манифест и ценности; Scrum — конкретный фреймворк с ролями, артефактами и спринтами. Подробнее здесь — глава 1, SDLC.
Вопрос. Scrum vs Kanban — что выбрать?
Ответ. Scrum — спринты и инкремент для продукта; Kanban — непрерывный поток и WIP для поддержки. Часто Scrumban. Подробнее здесь — итоги, глава 5.
Вопрос. Scrum vs Waterfall.
Ответ. Waterfall — фазы и фиксированный план; Scrum — адаптация каждый спринт. Гибриды для госсектора. Подробнее здесь — итоги, методология.
Вопрос. Сколько длится спринт в Scrum?
Ответ. Обычно 1–4 недели, длина фиксирована для команды; менять каждый раз нельзя. Подробнее здесь — спринт и ритм.
Вопрос. Product Owner — обязанности и кто может быть PO.
Ответ. Один человек, приоритет бэклога, максимизация ценности; доступен команде в спринте. Подробнее здесь — глава 2.
Вопрос. Scrum Master — чем не является (не начальник).
Ответ. Не раздаёт задачи, не PM отчётности; фасилитация, снятие impediments, коучинг Scrum. Подробнее здесь — команда и SM.
Вопрос. Story points — что это и как оценивать?
Ответ. Относительная сложность, не часы; Planning Poker и история velocity. Подробнее здесь — бэклог и оценка.
Вопрос. Velocity в Scrum — как считать?
Ответ. Сумма points по задачам Done за спринт; для прогноза capacity, не KPI наказания. Подробнее здесь — глава 4.
Вопрос. Definition of Done DoD — примеры критериев.
Ответ. Код, ревью, тесты, CI зелёный, документация, деплой на staging — команда договаривается явно. Подробнее здесь — потери и готово.
Вопрос. Sprint Planning — сколько длится и что на выходе?
Ответ. До 8 ч на месячный спринт (пропорционально меньше); Sprint Goal + Sprint Backlog. Подробнее здесь — глава 2, глава 4.
Вопрос. Daily Scrum standup — 3 вопроса и 15 минут.
Ответ. Прогресс к Sprint Goal, план на день, блокеры; не статус-рапорт руководству. Подробнее здесь — глава 2, глава 3.
Вопрос. Sprint Retrospective — формат и частота.
Ответ. В конце каждого спринта; 1–3 улучшения процесса на следующий цикл. Подробнее здесь — глава 2, внедрение.
Вопрос. Product Backlog — кто ведёт и как приоритизировать?
Ответ. Product Owner; ценность, риск, зависимости; refinement регулярно. Подробнее здесь — бэклог.
Вопрос. Размер Scrum team — сколько человек?
Ответ. Scrum Guide: до 10 в одной команде; больше — несколько команд и масштабирование. Подробнее здесь — глава 3.
Вопрос. Scrum Guide 2020 — что изменилось?
Ответ. Фокус на accountabilities, Product Goal, упрощение ролей; актуальная терминология в статьях раздела. Подробнее здесь — глава 1.
Вопрос. Как внедрить Scrum в компании с нуля?
Ответ. 11 шагов: роли, длина спринта, DoD, одна доска, честный Review; не Jira в первый день. Подробнее здесь — внедрение.
Вопрос. Scrumban — что это?
Ответ. Спринты Scrum + WIP-лимиты Kanban; часто фичи в спринтах, поддержка в потоке. Подробнее здесь — глава 5.
Вопрос. Sprint Goal — пример хорошей формулировки.
Ответ. Одна измеримая цель на спринт для всей команды, не список задач. Подробнее здесь — глава 4.
Вопрос. Burndown chart — как читать?
Ответ. Оставшаяся работа в спринте vs время; отклонение — сигнал риска, если данные честные. Подробнее здесь — глава 4.
Вопрос. Scrum artifacts — список артефактов.
Ответ. Product Backlog, Sprint Backlog, Increment (+ Product Goal, Sprint Goal, DoD как commitment). Подробнее здесь — глава 2.
Вопрос. Scrum events — пять событий.
Ответ. Sprint, Planning, Daily, Review, Retrospective — все внутри спринта. Подробнее здесь — глава 2.
Scrum в одном абзаце
Scrum — лёгкий фреймворк Agile — фиксированные спринты, три accountability (PO, SM, Developers), артефакты с Product Goal / Sprint Goal / DoD, пять событий для прозрачности и адаптации. Ценность — в частых инкрементах и честном измерении velocity, а не в объёме документации.
Сравнение подходов
| Критерий | Waterfall (план-driven) | Scrum | Kanban (поток) |
|---|---|---|---|
| План | Детальный заранее | На спринт + долгий бэклог | Непрерывный поток |
| Поставка | В конце фаз | Каждый спринт | По мере готовности |
| Изменения | Дорогие, формальные | Через бэклог и PO | В любой момент |
| Роли | Фазы и отделы | PO, SM, Developers | Не предписаны |
| Метрика | % по плану | Velocity, Done | Lead time, WIP |
| Сильная сторона | Регуляторика, фикс. scope | Сложный продукт, обучение | Поддержка, ops, дефекты |
Один продукт может сочетать Scrum для фич и Kanban для поддержки (Scrumban).
Когда Scrum уместен
- требования уточняются по ходу;
- нужна регулярная обратная связь заказчика;
- команда может быть кросс-функциональной 3–9 человек;
- организация готова к прозрачности (демо, честный burndown).
Когда тяжелее:
- заказчик не доступен для PO/review;
- контракт запрещает менять scope;
- "команда" — 20 человек без декомпозиции на потоки.
Маршрут по разделу 7-14
Соседние разделы
| Тема | Ссылка |
|---|---|
| SDLC, Agile, SAFe | 7-03 |
| Команда, оценки | 7-02 |
| Требования | 7-04 |