Scrum — роли, артефакты и события
Миграции в инкременте — Пакетная работа; проверка — SQL для тестировщика.
Что такое Scrum
Scrum — лёгкий фреймворк для управления сложной работой: команда решает нетривиальные задачи и регулярно поставляет ценный инкремент продукта. В основе — короткие фиксированные циклы (спринты), внутри которых планирование, ежедневная синхронизация, демонстрация результата и разбор процесса идут по одному и тому же ритму.
Метод придумал Джефф Сазерленд в 1993 году (вместе с Кеном Швабером оформили подход для индустрии ПО); сегодня Scrum — самый распространённый фреймворк Agile. Чаще всего его связывают с IT, но тот же ритм применяют в маркетинге, логистике, медиа и даже в бытовых проектах — от ремонта дома до госпрограмм вроде Sentinel ФБР (см. историю).
Сазерленд в книге Scrum. Революционный метод управления проектами (2016) формулирует обещание фреймворка так: вдвое больше результата за половину времени — не как гарантию, а как следствие снятия потерь (ожидание, полуготовая работа, многозадачность), а не «магии названия». На практике это означает: меньше месяцев без рабочего продукта, честные сроки после нескольких спринтов и демо, которым верят заказчики.
Норма — актуальные определения в Scrum Guide.
Запуск и живая практика — 11 шагов, кейсы и типичные ошибки в статье о внедрении; история «зачем» — в предыдущей главе.
Три роли (accountability)
В Scrum Guide одна Scrum Team (обычно до 10 человек), без классической иерархии «начальник — подчинённые»: команда самоорганизуема, внутри три accountability (зоны ответственности):
| Роль | Суть в одной фразе |
|---|---|
| Product Owner | Максимизирует ценность продукта через приоритеты бэклога |
| Scrum Master | Служит команде и организации: процесс, препятствия, фасилитация |
| Developers | Создают инкремент в спринте — все нужные навыки внутри команды |
Три «ножки табурета» сильной команды по Сазерленду (гл. 3 книги) совпадают с этим устройством: общая цель, автономия в способе работы и кросс-функциональность «от начала до конца». Подробнее о размере команды и SM — в статье о команде.
Product Owner (владелец продукта)
- Отвечает за максимизацию ценности продукта от работы команды.
- Ведёт и приоритизирует Product Backlog; единственный, кто "режет" порядок задач с учётом всех стейкхолдеров.
- Принимает решения по scope: что делаем, что откладываем.
PO — человек с видением, кто взвешивает риски, выгоду и то, что реально вдохновляет команду и бизнес.
Developers (разработчики)
Термин не означает "только программисты". Это все, кто создаёт инкремент в спринте — разработка, анализ, тестирование, дизайн — по составу команды.
- Самоорганизация: как выполнить работу спринта.
- Владеют Definition of Done для инкремента (согласуют с PO и организацией).
Scrum Master
- Служит Scrum Team и организации: помогает применять Scrum, устраняет impediments (препятствия).
- Фасилитирует события, следит за time-box и фокусом.
- SM — лидер-слуга (между капитаном и тренером): не раздаёт задачи сверху, а держит процесс и непрерывное улучшение.
Кейс из книги: бригада NPR в Каире во время событий на площади Тахрир (2011). Старший продюсер (фактически SM) не командовал репортёрами, а снабжал ресурсами и на ежедневных стойках задавал три вопроса — что сделано, что будет сделано, что мешает. Препятствия с прошлой встречи к следующей должны были быть сняты. Команда вышла на ритм ежедневных выпусков без микроменеджмента из Вашингтона — тот же принцип, что и в IT-спринте.
PM часто отвечает за бюджет, контракт и портфель.
SM — за процесс Scrum и здоровье команды.
В маленьких продуктах роли могут совмещать люди, но функции путать опасно.
Артефакты и обязательства (commitments)
| Артефакт | Обязательство (Scrum Guide) | Смысл |
|---|---|---|
| Product Backlog | Product Goal | Единый ориентир продукта |
| Sprint Backlog | Sprint Goal | Зачем этот спринт |
| Increment | Definition of Done | Что значит "готово" |
Product Backlog
- Единственный упорядоченный список всего, что нужно продукту — фичи, исправления, техдолг, исследования.
- Живёт весь жизненный цикл продукта; уточняется (refinement) постоянно.
- PO говорит со всеми заинтересованными лицами, чтобы бэклог отражал полную картину.
Sprint Backlog
- Подмножество Product Backlog на текущий спринт + план, как команда достигнет Sprint Goal.
- Принадлежит Developers; обновляется в течение спринта по мере обучения.
Increment
- Конкретный результат спринта, соответствующий DoD.
- К концу спринта инкремент готов к использованию (не "почти готово на стенде разработчика").
Пример фрагмента Definition of Done (адаптируйте под команду):
definition_of_done:
- код в основной ветке, code review выполнен
- автотесты по затронутым модулям зелёные
- обновлена документация API при изменении контракта
- нет открытых дефектов severity ≥ Major
- демо на тестовом стенде, PO подтвердил критерии
Шаблон user story и Definition of Ready — в аналитике и кратко в 7-03/1.
Жизненный цикл спринта
Спринт — фиксированный отрезок (обычно 1–4 недели, длина одинакова от спринта к спринту). Внутри него четыре ключевых события плюс сама работа над инкрементом:
| Этап | Что происходит |
|---|---|
| Планирование спринта | Команда с PO выбирает цель спринта и задачи с верха Product Backlog; прогноз — по velocity, если спринты уже были |
| Ежедневный Scrum (стендап) | До 15 минут: синхронизация к цели спринта, не отчёт начальству |
| Обзор спринта (демо) | Показ готового инкремента стейкхолдерам; обратная связь уточняет бэклог |
| Ретроспектива | Разбор процесса: что улучшить в следующем спринте (один kaizen лучше десяти пожеланий) |
Между спринтами идёт уточнение бэклога (refinement) — параллельно обычной работе.
Принципы ритма из гл. 4 книги Сазерленда, полезные на практике:
- Демонстрируй или проиграешь — в конце спринта должен быть usable результат, не «процент готовности».
- Время конечно — короткие равные циклы берегут внимание команды.
- Все всё знают — прозрачная доска и ежедневная синхронизация быстрее статус-отчётов.
- Одно командное собрание в день — Daily хватает для координации; детали — после.
Пять ценностей Scrum
Эффективность Scrum опирается не только на роли и встречи, но и на культуру в команде. В Scrum Guide закреплены пять ценностей — их связывают с поведением на планировании, дейли, review и ретро:
| Ценность | На практике |
|---|---|
| Смелость | Браться за сложное, открыто говорить о рисках и проблемах, не прятать «красные» задачи |
| Фокус | Держать в центре цель текущего спринта, а не бесконечный список «срочного» |
| Приверженность | Личная и командная ответственность за Sprint Goal и договорённости спринта |
| Уважение | Ценить профессионализм и автономию коллег, не превращать ретро в поиск виноватых |
| Открытость | Прозрачный прогресс, честный burndown, видимые препятствия — основа эмпиризма (см. гл. 1) |
Без этих ценностей остаётся Scrum-театр: встречи есть, инкремента и доверия — нет (признаки — в внедрении и чек-листе).
События (events) — нормативные детали
Все события time-boxed; пропуск ради экономии времени обычно увеличивает риск и неясность.
| Событие | Длительность (ориентир) | Участники | Цель |
|---|---|---|---|
| Sprint | ≤ 1 месяца, чаще 1–2 недели | Scrum Team | Инкремент + цели спринта |
| Sprint Planning | до 8 ч для месячного спринта (меньше для коротких) | Вся Scrum Team | Sprint Goal + начальный Sprint Backlog |
| Daily Scrum | 15 мин | Developers (SM фасилитирует) | Синхронизация к Sprint Goal |
| Sprint Review | до 4 ч / месяц | Scrum Team + стейкхолдеры | Инспекция инкремента, адаптация бэклога |
| Sprint Retrospective | до 3 ч / месяц | Scrum Team | Улучшение процесса |
Sprint Planning
На практике внедрения:
- Спринт фиксированной длины (не "неделя, потом три").
- Команда берёт верх бэклога и прогнозирует объём; если уже были спринты — опирается на velocity (динамику производительности).
- Правило фокуса: договорившись о объёме спринта, не добавлять новую работу в тот же спринт (исключения — только если команда сама отменяет Sprint).
Daily Scrum
Распространённая формулировка Daily (чуть шире классической тройки "вчера / сегодня / блокеры"):
- Что ты делал вчера, чтобы помочь команде завершить спринт?
- Что сделаешь сегодня для того же?
- Какие препятствия на пути команды?
Этика и антипаттерны дейли — 7-02/111.
Sprint Review
- Демонстрируется только то, что Done по DoD.
- Открытая встреча — PO, пользователи, руководство — как в кейсе Sentinel (см. гл. 1).
- Результат — обновлённый Product Backlog с учётом feedback.
Sprint Retrospective
- Фокус на процессе, не на поиске виноватых (см. Команда, "вините игру").
- Улучшение (kaizen) должно попасть в работу следующего спринта (задача, эксперимент, изменение DoD).
11 шагов запуска (краткая выжимка)
Полный разбор — Внедрение. Типовый порядок:
- Product Owner
- Команда (3–9 человек, все нужные навыки)
- Scrum Master
- Product Backlog
- Оценка бэклога (относительная, Fibonacci)
- Sprint Planning
- Видимость работы (доска, burndown)
- Daily Scrum
- Sprint Review
- Retrospective
- Сразу следующий спринт
Что читать дальше
| Тема | Статья |
|---|---|
| Размер команды, SM | ./3 |
| Спринт, velocity, доска | ./4 |
| Потери, DoD углублённо | ./5 |
| Оценка, Planning Poker | ./6 |
Нормативная база: Scrum Guide.
Живая практика и кейсы: Джефф Сазерленд, Scrum. Революционный метод управления проектами (М.: Манн, Иванов и Фербер, 2016) — история метода, команды, потери, планирование и внедрение; дополняет Guide нарративом, а не заменяет норму.