Scrum

---

Роль	Ответственность	Ключевое правило
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 недели
• Более детальное планирование
• Фокус на оптимизации процесса

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

---

• Удовлетворенность клиентов и пользователей
• Скорость доставки ценности
• ROI и финансовые показатели
• Рыночная конкурентоспособность

• Стабильность velocity (для прогнозирования)
• Снижение cycle time
• Улучшение Definition of Done
• Рост командной автономии

• Количество завершенных задач без контекста
• Процент выполнения спринта как показатель успеха
• Velocity для сравнения команд
• Количество проведенных церемоний без анализа результатов

---

Ошибка	Почему это плохо	Как исправить
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. Как будете измерять успех?

---

• Фокус на ценности для клиента, а не на процессах
• Самоорганизация команды — основа успеха
• Definition of Done обеспечивает качество
• Velocity для прогнозирования, а не для оценки
• Успех измеряется бизнес-результатами

🎯 Следующий шаг: Проведите аудит вашей команды и начните с одного улучшения на следующем спринте.

---