Время освоения: ~40 минут
Цель: Научиться эффективно применять Scrum для итеративной разработки с постоянной адаптацией и улучшением
| Роль | Ответственность | Ключевое правило |
|---|
| Product Owner | Управляет бэклогом, приоритизирует, принимает результат | Единственный владелец приоритетов |
| Scrum Master | Фасилитация, устранение блокеров, коучинг | Не менеджер, не назначает задачи |
| Dev Team | Разработка, самоорганизация, оценка | 3–9 человек, кросс-функциональная |
#Церемонии (для 2-недельного спринта)
| Церемония | Цель | Длительность | Участники |
|---|
| 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 | (Дни × Часы/день) − непроизводственные часы | Реалистичное планирование |
Scrum — это фреймворк для управления сложными проектами через итеративную разработку с частой обратной связью и возможностью адаптации к изменениям.
- Сфокусированность на результате, а не на процессе
- Доставка ценности клиенту как главная цель
- Самоорганизация команды и ответственность за результат
- Непрерывное улучшение через рефлексию
- Роли: 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 — это не методология, а фреймворк. Он предоставляет структуру, но требует адаптации под конкретный контекст команды.
#Основные элементы Scrum (25 минут)
- Владелец Product Backlog и приоритетов
- Представляет интересы заинтересованных сторон (stakeholders)
- Принимает/отклоняет работу команды
- Отвечает за ROI и ценность продукта
- Фасилитатор процесса и коуч команды
- Устраняет препятствия (impediments)
- Обеспечивает соблюдение правил Scrum
- Не является менеджером — не назначает задачи и не оценивает производительность
Development Team (Dev Team):
- 3-9 человек, кросс-функциональная команда
- Самоорганизующаяся и ответственная за результат
- Включает разработчиков, QA, UX, DevOps (в зависимости от контекста)
- Нет подролей — все равны в принятии решений
- Заинтересованные стороны (клиенты, заказчики, бизнес)
- Не являются членами команды, но предоставляют входные данные PO
Sprint Planning (Планирование спринта):
- Длительность: до 8 часов для 2-недельного спринта
- Две части:
- Часть 1: Что будем делать? (выбор задач из Product Backlog)
- Часть 2: Как будем делать? (детальное планирование работы)
- Результат: Sprint Backlog + цель спринта
Daily Scrum (Ежедневный стендап):
- Длительность: 15 минут максимум
- Формат: Что сделал вчера? Что сделаю сегодня? Какие препятствия?
- Ведет сама команда (не SM как менеджер)
- Цель: синхронизация, выявление проблем
Sprint Review (Обзор спринта):
- Длительность: до 4 часов для 2-недельного спринта
- Участники: команда, PO, stakeholders
- Содержание: демонстрация завершенной работы, получение обратной связи
- Не является ретроспективой или планированием
Sprint Retrospective (Ретроспектива):
- Длительность: 60-90 минут для 2-недельного спринта
- Цель: улучшение процессов и работы команды
- Структура: установка контекста → сбор данных → генерация идей → принятие решений → завершение
- Ключевое правило: безопасная среда, без обвинений
- Упорядоченный список всех требований к продукту
- Управляет PO, проводит регулярный refinement с командой
- Включает пользовательские истории, баги, технический долг
- Приоритезация основана на ценности для пользователя
- Задачи, выбранные для текущего спринта
- Создается командой во время Sprint Planning
- Команда берет обязательства, а не получает задания
- Может изменяться только командой в течение спринта
- Рабочий продукт, готовый к доставке пользователю
- Должен соответствовать Definition of Done
- Сумма всех инкрементов = продукт
#4. Definition of Done (DoD)
Что это: Согласованные критерии готовности задачи.
- Код проверен (code review)
- Модульные тесты проходят (>80% покрытия)
- Интеграционные тесты проходят
- Документация обновлена
- Развернуто на стейджинге
- Одобрено PO
- Общее понимание "готово"
- Контроль качества
- Предотвращение состояния "почти готово"
- Отличается от критериев приемки (acceptance criteria) для каждой пользовательской истории
#5. Оценка в story points
Что это: Относительная мера сложности (усилия + риски + неопределенность).
- Выбрать базовую историю (например, 5 баллов)
- Сравнивать новые истории с базовой
- Использовать последовательность Фибоначчи (1, 2, 3, 5, 8, 13...)
- Planning Poker для достижения консенсуса
- Среднее количество story points, завершенных за спринт
- Используется для прогнозирования, а не для оценки производительности
- Должен быть стабильным во времени для надежного прогнозирования
#Практическое применение и адаптация (10 минут)
#1. Адаптация для разных контекстов
Высокая неопределенность:
- Короткие спринты (1 неделя)
- Частый refinement Product Backlog
- Гибкая приоритизация
- Акцент на экспериментах и быстрой обратной связи
- Спринты 2-4 недели
- Более детальное планирование
- Фокус на оптимизации процесса
- Видеосвязь для всех церемоний
- Цифровые доски для визуализации
- Четкие правила взаимодействия
- Асинхронные элементы для подготовки
#2. Измерение успеха Scrum-команды
- Удовлетворенность клиентов и пользователей
- Скорость доставки ценности
- 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 не задаёт вопросы каждому |
#Упражнение 1: Анализ текущей практики
Оцените вашу текущую реализацию Scrum по критериям:
- Какие роли существуют и как они выполняются?
- Как организованы церемонии?
- Как управляется Product Backlog?
- Как определяется Definition of Done?
#Упражнение 2: План улучшения
Выберите одну область и разработайте план улучшения:
- Какую область выберете?
- Какие проблемы видите?
- Какие действия предпримете?
- Как будете измерять успех?