Scrum

Быстрый справочник

• Scrum — фреймворк, не методология: он намеренно неполный, ты добавляешь детали
• SM фасилитирует, не управляет: SM который назначает задачи убивает самоорганизацию
• Velocity — инструмент планирования, не KPI производительности
• Definition of Done: это не "задача выполнена", а "продукт готов к релизу"
• Ретроспектива: главная точка роста команды; без psychological safety — бесполезна
• Sprint Goal важнее спринт-беклога: команда должна знать ЧТО они создают, не просто выполнять задачи
• Kanban для support/ops, Scrum для product development — выбирай по типу работы

---

Роль	Ответственность	Ключевое правило
Product Owner	Управляет бэклогом, приоритизирует, принимает результат	Единственный владелец приоритетов
Scrum Master	Фасилитация, устранение блокеров, коучинг	Не менеджер, не назначает задачи
Dev Team	Разработка, самоорганизация, оценка	3–9 человек, кросс-функциональная

Церемония	Цель	Длительность	Участники
Sprint Planning	Выбрать задачи + спланировать выполнение	до 8 часов	Вся команда
Daily Scrum	Синхронизация, выявление блокеров	15 минут	Команда
Sprint Review	Демо результатов, обратная связь	до 4 часов	Команда + Stakeholders
Retrospective	Улучшение процессов	60–90 минут	Команда

Артефакт	Что содержит	Кто управляет
Product Backlog	Все требования (истории, баги, техдолг)	Product Owner
Sprint Backlog	Задачи текущего спринта	Команда
Increment	Рабочий продукт, соответствующий DoD	Команда
Definition of Done	Единые критерии готовности задачи	Команда совместно

Метрика	Как считать	Для чего
Velocity	Сумма story points завершённых задач за спринт	Прогнозирование, не оценка людей
Capacity	(Дни × Часы/день) − непроизводственные часы	Реалистичное планирование

---

• Сфокусированность на результате, а не на процессе
• Доставка ценности клиенту как главная цель
• Самоорганизация команды и ответственность за результат
• Непрерывное улучшение через рефлексию

• Роли: Product Owner, Scrum Master, Development Team
• Церемонии: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective
• Артефакты: Product Backlog, Sprint Backlog, Increment
• Правила: Фиксированные спринты, time-boxed церемонии, Definition of Done

💡 Помните: Scrum — это не методология, а фреймворк. Он предоставляет структуру, но требует адаптации под конкретный контекст команды.

---

• Владелец Product Backlog и приоритетов
• Представляет интересы заинтересованных сторон (stakeholders)
• Принимает/отклоняет работу команды
• Отвечает за ROI и ценность продукта

• Фасилитатор процесса и коуч команды
• Устраняет препятствия (impediments)
• Обеспечивает соблюдение правил Scrum
• Не является менеджером — не назначает задачи и не оценивает производительность

• 3-9 человек, кросс-функциональная команда
• Самоорганизующаяся и ответственная за результат
• Включает разработчиков, QA, UX, DevOps (в зависимости от контекста)
• Нет подролей — все равны в принятии решений

• Заинтересованные стороны (клиенты, заказчики, бизнес)
• Не являются членами команды, но предоставляют входные данные PO

---

• Длительность: до 8 часов для 2-недельного спринта
• Две части:
  • Часть 1: Что будем делать? (выбор задач из Product Backlog)
  • Часть 2: Как будем делать? (детальное планирование работы)
• Результат: Sprint Backlog + цель спринта

• Длительность: 15 минут максимум
• Формат: Что сделал вчера? Что сделаю сегодня? Какие препятствия?
• Ведет сама команда (не SM как менеджер)
• Цель: синхронизация, выявление проблем

• Длительность: до 4 часов для 2-недельного спринта
• Участники: команда, PO, stakeholders
• Содержание: демонстрация завершенной работы, получение обратной связи
• Не является ретроспективой или планированием

• Длительность: 60-90 минут для 2-недельного спринта
• Цель: улучшение процессов и работы команды
• Структура: установка контекста → сбор данных → генерация идей → принятие решений → завершение
• Ключевое правило: безопасная среда, без обвинений

---

• Упорядоченный список всех требований к продукту
• Управляет PO, проводит регулярный refinement с командой
• Включает пользовательские истории, баги, технический долг
• Приоритезация основана на ценности для пользователя

• Задачи, выбранные для текущего спринта
• Создается командой во время Sprint Planning
• Команда берет обязательства, а не получает задания
• Может изменяться только командой в течение спринта

• Рабочий продукт, готовый к доставке пользователю
• Должен соответствовать Definition of Done
• Сумма всех инкрементов = продукт

---

• Код проверен (code review)
• Модульные тесты проходят (>80% покрытия)
• Интеграционные тесты проходят
• Документация обновлена
• Развернуто на стейджинге
• Одобрено PO

• Общее понимание "готово"
• Контроль качества
• Предотвращение состояния "почти готово"
• Отличается от критериев приемки (acceptance criteria) для каждой пользовательской истории

---

• Выбрать базовую историю (например, 5 баллов)
• Сравнивать новые истории с базовой
• Использовать последовательность Фибоначчи (1, 2, 3, 5, 8, 13...)
• Planning Poker для достижения консенсуса

• Среднее количество story points, завершенных за спринт
• Используется для прогнозирования, а не для оценки производительности
• Должен быть стабильным во времени для надежного прогнозирования

---

• Короткие спринты (1 неделя)
• Частый refinement Product Backlog
• Гибкая приоритизация
• Акцент на экспериментах и быстрой обратной связи

• Спринты 2-4 недели
• Более детальное планирование
• Фокус на оптимизации процесса

• Видеосвязь для всех церемоний
• Цифровые доски для визуализации
• Четкие правила взаимодействия
• Асинхронные элементы для подготовки

---

• Start: что начать делать?
• Stop: что перестать?
• Continue: что продолжать?
• Формат: стикеры → группировка → голосование → 2–3 action items

• Liked: что понравилось в спринте
• Learned: что узнали/осознали
• Lacked: чего не хватало
• Longed For: о чём мечтали
• Когда использовать: когда команда хочет порефлексировать на уровне роста

• Хорошо выявляет проблемы с культурой и моральным духом
• Не про технические процессы — про чувства людей в команде
• Используй когда чувствуешь что что-то не так, но команда не говорит об этом

• Keep Doing / Less Of / More Of / Stop Doing / Start Doing
• Более нюансированный чем SSC — "делать меньше" отличается от "перестать"
• Когда использовать: команда 6+ месяцев, хочет более точной настройки

• Sailboat: Wind (что ускоряет), Anchor (что тормозит), Rocks (риски), Island (цель)
• Хорошо для начала квартала или при смене направления
• Визуально вовлекает и снижает защитные реакции

• Silent writing first: все пишут стикеры параллельно (2–3 мин), потом обсуждают
• Anonymous tools (Miro, FunRetro): снижает social pressure
• Rotating facilitator: разные люди ведут ретро — все чувствуют ответственность
• Explicit invite: "Алексей, ты сегодня молчишь — что думаешь о X?"

• Максимум 3 action items за спринт (лучше 1–2)
• Каждый item: owner + конкретное action + deadline
• Первые 5 минут следующей ретро: проверь статус предыдущих items
• Если одна и та же проблема появляется 3 ретро подряд — это системная проблема, реши её вне ретро

---

1. SM не фасилитировал — он записывал пункты и иногда оправдывался за "плохое"
2. Action items не выполнялись — через 2 недели то же самое
3. Формат не менялся 3 месяца
4. Критика превращалась в личные нападки ("Вася медленно делает задачи")

1. Новый SM (ротация на 1 квартал) — разрыв паттерна
2. Переход на anonymous Miro стикеры — сразу появились честные комментарии
3. Правило: максимум 2 action items, оба с owner
4. Начало каждого ретро: 2 мин на статус предыдущих items
5. Mad/Sad/Glad формат — вышла наружу настоящая проблема (перегрузка, не технические процессы)

---

Ошибка	Почему это плохо	Как исправить
SM назначает задачи разработчикам	Разрушает самоорганизацию, команда перестаёт думать самостоятельно	SM фасилитирует, команда сама берёт задачи с доски
Definition of Done меняется под каждую задачу	Нет единого стандарта качества, возникает «почти готово»	Один DoD для всех задач команды, меняется только командой целиком
Velocity используют как KPI разработчика	Команда накручивает цифры, растёт технический долг	Velocity — исключительно инструмент прогнозирования спринтов
PO добавляет задачи в Sprint Backlog в середине спринта	Срыв Sprint Goal, команда теряет фокус	Изменения — только в Product Backlog, войдут в следующий спринт
Ретроспектива без конкретных действий	Ничего не меняется, команда теряет веру в процесс	Максимум 3 действия с конкретным ответственным и дедлайном
Daily Scrum превращается в отчёт менеджеру	Люди говорят то, что хотят услышать, а не правду	Daily ведёт команда для себя, SM не задаёт вопросы каждому

---

• Какие роли существуют и как они выполняются?
• Как организованы церемонии?
• Как управляется Product Backlog?
• Как определяется Definition of Done?

1. Какую область выберете?
2. Какие проблемы видите?
3. Какие действия предпримете?
4. Как будете измерять успех?