11. Scrum-ритуалы_ Дейлики, Ревью и Ретроспектива

1.

Управление программными
проектами
Scrum-ритуалы: Дейлики, Ревью и
Ретроспектива

2.

Agenda
● Зачем нужны события в Scrum?
● Daily Scrum: 15 минут на синхронизацию
● Sprint Review: демонстрация инкремента
● Sprint Retrospective: улучшение процесса
● Чего не стоит делать: антипаттерны

3.

Активность 1: "Идеальный день команды"
Представьте, что вы в команде из 5 человек. Опишите идеальный
рабочий день: как вы понимаете, кто что делает? Как узнаете о
проблемах? Как принимаете решения?
Вывод: Без регулярной синхронизации даже в идеальной команде
начнется хаос. Scrum-ритуалы создают этот ритм.

4.

События Scrum как инспекция и адаптация
● Daily Scrum: Инспекция и адаптация прогресса (ежедневно)
● Sprint Review: Инспекция и адаптация продукта (раз в
спринт)
● Sprint Retrospective: Инспекция и адаптация процесса (раз
в спринт)
● Общая цель: Сделать работу прозрачной и постоянно
улучшать ее

5.

Daily Scrum — это не "отчет начальнику"
Время: Максимум 15 минут, каждый день в одно время
Участники: Команда разработки (обязательно), SM, PO (по
желанию)
Формат: Стоя, если оффлайн (чтобы не затягивать)
Цель: Синхронизироваться и спланировать работу на ближайшие
24 часа

6.

Три классических вопроса (и почему они устарели)
● Традиционная форма:
1. Что я сделал вчера?
2. Что я сделаю сегодня?
3. Какие есть препятствия?
● Проблема: Превращается в отчет менеджеру
● Современный подход: Обсуждение продвижения к цели спринта
○
"Какой прогресс по цели спринта?"
○
"Что нужно сделать сегодня, чтобы приблизиться к цели?"
○
"Что мешает нам двигаться к цели?"

7.

Правила эффективного дейлика
● Говорит команда, а не SM: Scrum Master только следит за
временем
● Фокус на Sprint Backlog: Обсуждаем задачи на доске
● Не решаем проблемы: Фиксируем блокеры, решаем после
митинга
● Начинаем вовремя: Даже если не все пришли

8.

Активность 2: "Плохой vs Хороший дейлик"
● Сценарий 1: Разработчики по очереди докладывают SM: "Вчера
кодил, сегодня буду кодить, препятствий нет"
● Сценарий 2: Команда у доски: "Мы застряли на интеграции
платежа. Вася поможет Маше сегодня. Блокер: ждем доступ к
тестовому API от банка"
● Обсуждение: "Чем отличаются два подхода? Где больше пользы?"
● Вывод: "Дейлик — это рабочая встреча команды, а не отчет."

9.

Sprint Review — "что мы сделали?"
● Время: 1 час на 1 неделю спринта (для 2-недельного
спринта — 2 часа)
● Участники: Команда, PO, стейкхолдеры, клиенты
● Цель: Продемонстрировать готовый инкремент и получить
обратную связь

10.

Структура обзора спринта
● Часть 1: Напоминание о цели спринта
● Часть 2: Демонстрация инкремента ("Шоу, а не рассказ!")
● Часть 3: Обсуждение обратной связи
● Часть 4: Обновление Product Backlog (PO вносит изменения
на основе фидбека)

11.

Чего НЕ должно быть на Review?
● ❌ Презентации PowerPoint вместо демо
● ❌ Оправданий, почему что-то не сделано
● ❌ Обсуждения оценок и сроков
● ❌ Технических деталей, непонятных стейкхолдерам

12.

Ключевой вопрос Review
● Вопрос стейкхолдерам: "Готовы ли вы выпустить этот
инкремент в продакшен?"
● Если "нет" — что нужно доработать?
● Если "да" — PO может планировать релиз

13.

Sprint Retrospective — самая важная церемония
● Время: 45 мин на 1 неделю спринта
● Участники: Команда разработки, SM, PO (по желанию)
● Главное правило: Безопасная среда, никакой критики
личности
● Цель: Улучшить процесс работы команды

14.

Формат ретроспективы (Glad/Sad/Mad)
● Что прошло хорошо (Glad)? → Делать больше
● Что можно улучшить (Sad)? → Изменить
● Что вызвало разочарование (Mad)? → Перестать делать
● Итог: 1-3 конкретных действия по улучшению на следующий
спринт

15.

Роль Scrum Master на ретроспективе
● Не менеджер, а фасилитатор
● Создает безопасную атмосферу
● Следит, чтобы все высказались
● Помогает сформулировать конкретные действия

16.

Сводная таблица событий Scrum
Событие
Участники
Длительность
Вопрос
Daily
Команда, SM
15 мин
Как продвигаемся к
цели спринта?
Review
Команда, PO,
стейкхолдеры
1-2 часа
Что сделали? Готово
ли к выпуску?
Retro
Команда, SM
45-90 мин
Как улучшить
процесс работы?

17.

Топ-5 антипаттернов
1. Daily-доклад: Когда говорят только SM или менеджеру
2. Review без демо: Показывают слайды вместо работающего
кода
3. Пропуск ретро: "Нет времени на улучшения"
4. Обвинения на ретро: Нарушение безопасной среды
5. Затягивание встреч: Daily дольше 15 мин, Review дольше 2
часов

18.

Главный вывод
Daily — для команды, про прогресс
Review — для стейкхолдеров, про продукт
Retro — для команды, про процесс
Все вместе — создают цикл инспекции и адаптации

19.

Домашнее задание
1. Сформировать спринт в проекте в taiga:
1. Создать спринт
2. Перетащить в него юз-кейс с подзадачами
3. Назначить исполнителей задачам
2. Попередвигать задачи между колонками, на каждом шаге
прописав в комментариях к задаче, что было сделано
(желательно от лица разработчика).
3. Отправить ссылку в журнал

20.

Создаем спринт

21.

Добавляем юзкейс в спринт

22.

Назначаем исполнителей

23.

Передвигаем в канбане

24.

Добавляем комментарий

25.

Еще передвигаем тот же или другой
Ссылка в нашем случае может быть фейковой

26.

Еще передвигаем тот же или другой
Можем менять статус не перетягиванием,
а прямо в задаче.
CodeReview делает не тот же
разработчик, что писал код

27.

Добавляем комментарий
Ссылка в нашем случае
может быть фейковой