Какие роли и церемонии есть в Scrum?

Какие роли и церемонии есть в Scrum?

Scrum — это agile фреймворк для управления проектами, основанный на повторяющихся циклах (спринтах) по 1-4 недели. В Scrum есть четко определенные роли, артефакты и церемонии (события). Это создает предсказуемость и позволяет команде быстро адаптироваться к изменениям.

Три основные роли в Scrum

1. Product Owner (PO)

Кто это? Представитель бизнеса, который отвечает за то, что строится.

Ответственность:

• Видение продукта: Знает, куда идет проект
• Product Backlog: Создает, приоритизирует, уточняет требования
• Stakeholder Management: Говорит с клиентами, понимает их боли
• Приемка работы: Определяет, готов ли инкремент (сделанная работа) к релизу
• ROI: Максимизирует ценность каждого спринта

Ключевые вопросы PO:

• Что сделать?
• Почему это важно?
• Какой порядок?
• Когда это нужно рынку?
• Какой бюджет?

Типичная неудача: PO не может быстро принять решение → спринт зависает

2. Scrum Master (SM)

Кто это? Фасилитатор и тренер, который помогает команде следовать Scrum процессу.

Ответственность:

• Scrum Process: Объясняет правила, не дает отступать
• Удаление блокеров: Не решает сам, но помогает команде решить проблемы
• Коучинг: Помогает улучшать процес
• Защита команды: Не дает отвлекать разработчиков во время спринта
• Метрики: Собирает скорость (velocity), отслеживает тренды

Ключевой принцип: SM — это слуга, не босс. Не управляет людьми, управляет процессом.

Типичные вопросы SM:

• Почему команда медленнее, чем неделю назад?
• Какие препятствия мешают прогрессу?
• Как улучшить общение?

Частые ошибки: SM становится микроменеджером вместо фасилитатора

3. Development Team (DT)

Кто это? Кросс-функциональная команда, которая реально делает работу.

Ответственность:

• Разработка: Писать код, тесты, документацию
• Оценка: Оценить сложность задач (story points)
• Планирование: Выбрать задачи на спринт, которые реально успеют
• Daily Communication: Синхронизироваться ежедневно
• Качество: Обеспечить, что код готов к продакшену (Definition of Done)

Кто может входить в команду?

• Разработчики (backend, frontend)
• QA / тестировщики
• UX дизайнеры (иногда)
• BA (иногда)

Идеальный размер: 5-9 человек

• Слишком мало (1-2) = не хватает навыков, зависимость
• Слишком много (10+) = коммуникационный overhead

Четыре церемонии (события) в Scrum

1. Sprint Planning (Планирование спринта)

Когда? В начале каждого спринта Сколько? Максимум 4 часа для 2-недельного спринта (8 часов для 4-недельного) Кто участвует? Вся команда + Product Owner

Цель: Выбрать задачи на спринт

Повестка:

1. Product Owner рассказывает о требованиях

   • Что самое важное для бизнеса?
   • Какие требования у клиента?
   • Какой deadline?

2. Команда задает вопросы уточняющие

   • Что именно нужно?
   • Как это измерить?
   • Какие ограничения?

3. Команда оценивает задачи (story points)

   • Фибоначчи шкала: 1, 2, 3, 5, 8, 13, 21...
   • Если оценка > 8, разбить на более мелкие

4. Команда выбирает задачи на спринт

   • Скорость из прошлого спринта = сколько story points может сделать
   • Обычно берут 80-90% скорости (не все 100%, место для непредвиденного)

5. Записать Sprint Goal

   • Одна фраза: "После этого спринта система будет..."
   • Дает направление, если что-то изменится во время спринта

Типичная ошибка: PO давит на команду: "Берите больше, это же легко!" → Спринт не готов, люди выгорают

2. Daily Standup (Ежедневная синхронизация)

Когда? Каждый день, в одно время Сколько? 15 минут МАКСИМУМ Кто участвует? Вся Development Team + Scrum Master. PO опционально.

Формат: Каждый разработчик отвечает на 3 вопроса:

1. Что я сделал вчера?
2. Что я буду делать сегодня?
3. Какие препятствия мешают мне?

Пример:

Иван (Backend):
- Вчера: Сделал API для авторизации
- Сегодня: Тестирую с фронтом
- Блокер: Мария не ответила на мой вопрос про дизайн

Мария (Frontend):
- Вчера: Верстал форму логина
- Сегодня: Интегрирую с API Ивана
- Блокер: Не было

Петр (QA):
- Вчера: Тестировал регистрацию
- Сегодня: Пишу тесты для авторизации
- Блокер: Нужно окружение для тестирования

Это НЕ статус-репорт! ❌ Неправильно: "Я занят" или "Все хорошо" ✅ Правильно: "Сделал X, буду делать Y, мешает Z"

Типичная ошибка: Standup превращается в 60-минутное совещание с обсуждением решений. Это проводится ПОСЛЕ standup'а, не во время.

3. Sprint Review (Демо спринта)

Когда? В конце спринта Сколько? Максимум 2 часа для 2-недельного спринта Кто участвует? Вся команда + Product Owner + Stakeholders + Клиенты

Цель: Показать, что сделано. Получить feedback.

Повестка:

1. Демонстрация выполненной работы

   • Только то, что готово (Definition of Done)
   • Live demo, не slides
   • На реальных данных

2. Ответы на вопросы

   • Почему это именно так?
   • Когда выйдет в продакшен?

3. Feedback от stakeholders

   • Что нравится?
   • Что не нравится?
   • Какие изменения нужны?

4. Обновление Product Backlog

   • На основе feedback добавляются новые требования
   • Приоритизируются для будущих спринтов

Типичная ошибка: Демо на разработчика-ском окружении с тестовыми данными → клиент не видит real use case

4. Sprint Retrospective (Ретроспектива)

Когда? В конце спринта, после Review Сколько? Максимум 1.5 часа для 2-недельного спринта Кто участвует? Вся Development Team + Scrum Master. PO опционально.

Цель: Улучшить процесс. Не критиковать людей, а улучшать систему.

Формат (популярный "Start, Stop, Continue"):

1. Start: Что нового начать?

   • "Писать unit тесты перед написанием кода"
   • "Ежедневные синхронизации с QA"

2. Stop: Что прекратить?

   • "Длинные встречи без итогов"
   • "Отправлять code review в 22:00"

3. Continue: Что продолжить?

   • "Pair programming помогает качеству"
   • "Daily standup 15 минут идеален"

Другие форматы:

• 4Ls: Liked, Learned, Lacked, Longed For
• Mad, Sad, Glad: Что разозлило? Что огорчило? Что обрадовало?
• Speedboat: Что ускоряет, что замедляет?

Правила: ✅ Честность и психологическая безопасность ✅ Фокус на процесс, не на людей ✅ Конкретные действия ("улучшим коммуникацию" — не очень) ✅ Приоритизировать: что самое важное?

Типичная ошибка: Ретро становится жалобной книгой, но ничего не меняется

Артефакты Scrum

1. Product Backlog

• Приоритизированный список всех требований
• Владелец: Product Owner
• Живой документ (постоянно меняется)

2. Sprint Backlog

• Задачи, выбранные на текущий спринт
• Видимая для всей команды (Jira, Trello, доска)

3. Increment (Инкремент)

• Готовая к использованию часть продукта
• Сумма всех готовых задач спринта
• Может быть не развернута, но готова

Timeline одного спринта (2 недели)

Понедельник:
09:00 - Sprint Planning (4 часа)

Вторник-Пятница:
09:15 - Daily Standup (15 минут)

Вторник:
Движение: Разработка

Среда:
Движение: Разработка + QA

Четверг:
Движение: Разработка + QA

Пятница:
09:15 - Daily Standup
После обеда - Разработка

Следующий Понедельник (начало второй недели):
09:15 - Daily Standup
После обеда - Разработка

...

Четверг Недели 2:
14:00 - Sprint Review (2 часа)
16:00 - Sprint Retrospective (1.5 часа)

Пятница Недели 2:
Подготовка к новому спринту

Что BA должен знать о Scrum?

1. BA часто близко работает с PO: BA изучает требования, PO приоритизирует
2. Уточнение требований: BA должен быть готов объяснить задачи на Planning
3. Definition of Done: BA участвует в acceptance критериях
4. User Stories: BA пишет истории, которые дает команде
5. Feedback: BA собирает feedback от юзеров в Sprint Review

Частые проблемы в Scrum

❌ Product Owner в отпуске → спринт зависает ❌ Разработчик отдергивается на "срочные" задачи → спринт не готов ❌ Scrum Master микроменеджит → команда стрессирует ❌ Sprint Review только для технической команды → клиент не видит ценность ❌ Retrospective без действий → ничего не меняется

Ключевые выводы

• 3 роли: PO (что), SM (как работать), DT (делает)
• 4 церемонии: Planning, Daily, Review, Retrospective
• Предсказуемость через регулярные циклы
• Адаптивность через feedback и улучшения
• Фокус на ценности для клиента

Scrum — это не наука, это искусство. Правила просты, мастерство приходит с опытом.