Scrum. Проведение планирования спринта. (1)

1.

Управление программными
проектами
Планирование спринта: От бэклога к рабочему
плану

2.

Agenda
● Зачем нужно планирование спринта?
● Две части планирования
● Стори-поинты vs оценки времени
● Практика: Planning Poker
● Формирование Sprint Backlog
● Типичные ошибки

3.

Активность 1: "Спринт мечты vs Спринт кошмара"
Представьте два сценария планирования спринта. Что происходит
в идеальном случае? Что приводит к провалу?

4.

Церемония планирования спринта
● Время: ~2-4 часа для 2-недельного спринта
● Участники: Вся Scrum-команда (Developers, PO, SM)
● Результаты:
○
Sprint Backlog с задачами
○
Цель спринта (Sprint Goal)
○
План работы

5.

Две части планирования
ЧАСТЬ 1: "ЧТО делать?" (с Product Owner)
● PO представляет элементы из верха Product Backlog
● Команда задает уточняющие вопросы
● Оценивает сложность (стори-поинты)
ЧАСТЬ 2: "КАК делать?" (без Product Owner)
● Команда детализирует задачи
● Создает план работы
● Формулирует Sprint Goal

6.

Зачем оценивать задачи?
● Предсказуемость: Понимание, сколько работы команда может
сделать
● Управление ожиданиями: Прозрачные обязательства перед
стейкхолдерами
● Измерение прогресса: Velocity = скорость команды

7.

Два подхода к оценке
● Стори-поинты:
○
Оценивают относительную сложность
○
Безразмерные единицы (1, 2, 3, 5, 8,
13...)
○
Учитывают: объем, сложность,
неопределенность, риски
● Оценки времени (часы/дни):
○
Абсолютные значения
○
Кажется более точной
○
На практике часто ошибочна

8.

Почему поинты работают лучше?
● Учитывают разную скорость
разработчиков
● Компенсируют оптимизм: мы
всегда недооцениваем сложность
● Фокус на сложности, а не на
времени
● Относительная шкала более
стабильна

9.

Шкалы стори-поинтов. Числа Фибоначчи
1. Числа Фибоначчи (1, 2, 3, 5, 8, 13,
21...)
● Плюсы:
○
Учитывает растущую неопределенность для
крупных задач
○
Удобна для Planning Poker
○
Стандарт де-факто в индустрии
● Минусы:
○
Может быть избыточной для маленьких проектов
○
Сложность объяснения новичкам

10.

Шкалы стори-поинтов. Степени двойки
2. Степени двойки (1, 2, 4, 8, 16...)
● Плюсы:
○
Простая для понимания
○
Хорошо работает в небольших командах
○
Подходит для технических задач
● Минусы:
○
Слишком крупные шаги для точной оценки
○
Не учитывает среднюю сложность (нет 3, 5, 6)

11.

Шкалы стори-поинтов. Линейная шкала
3. Линейная шкала (1, 2, 3, 4, 5, 6...)
● Плюсы:
○
Интуитивно понятна
○
Легко считать средние значения
○
Подходит для команд с высокой
предсказуемостью
● Минусы:
○
Создает иллюзию точности
○
Сложно оценивать очень крупные задачи

12.

Шкалы стори-поинтов. Размеры маек
4. T-shirt sizes (XS, S, M, L, XL)
Плюсы:
○
Очень наглядна и проста
○
Хороша для начальной грубой оценки
○
Не вызывает споров о точных цифрах
Минусы:
○
Сложно считать velocity
○
Не подходит для точного
планирования
○
Трудно преобразовать в метрики

13.

Какую шкалу выбрать?
● Временные команды: T-shirt sizes или линейная шкала
● Опытные команды: Фибоначчи или степени двойки
● Технические задачи: Степени двойки
● User stories: Фибоначчи
● Важно: Используйте одну шкалу постоянно!

14.

Процесс Planning Poker:
1. PO описывает задачу
2. Команда задает вопросы
3. Все одновременно показывают карту с оценкой
4. Самый высокий и низкий объясняют свою позицию
5. Повторяем раунд, пока не придем к консенсусу
Вывод: Planning Poker помогает учесть все мнения.

15.

Активность 2: "Planning Poker с разными шкалами"
Сценарий: "Оценим 3 задачи разными методами:"
Задача A: "Добавить кнопку 'Поделиться' в приложении"
Задача B: "Реализовать систему кэширования данных"
Задача C: "Интегрировать нейросеть для рекомендаций"
Процесс:
1. Раунд 1: Оцениваем Фибоначчи
2. Раунд 2: Оцениваем T-shirt sizes
3. Раунд 3: Сравниваем результаты
4. Обсуждение: Какая шкала удобнее? Какая точнее?

16.

Как понять, сколько взять в спринт?
● Velocity (мощность) команды: среднее количество поинтов
за прошлые спринты
● Capacity (ёмкость) команды: учет отпусков, больничных,
других проектов
● Опыт: интуитивное понимание своих возможностей

17.

Sprint Goal — компас спринта
● Что это? Краткое описание того, что мы хотим достичь
● Примеры:
○
"Сделать основную onboarding воронку для новых пользователей"
○
"Увеличить производительность главной страницы на 30%”
● Зачем нужно? Помогает принимать решения в течение спринта

18.

Sprint Backlog — наш план
Что включает:
● Выбранные user stories из Product Backlog
● Детализированные технические задачи
● Оценки в часах для daily planning
Важно: Sprint Backlog принадлежит команде, команда сама
решает, как работать

19.

Типичные ошибки при планировании
● Обещание слишком многого ("Давайте возьмем еще одну
фичу!")
● Игнорирование технических долгов
● Смешивание поинтов и часов в обсуждении
● Отсутствие детализации задач
● Участие менеджеров, которые давят на команду

20.

Что на практике?
● Первые спринты будут с ошибками — это нормально
● Velocity стабилизируется после 2-3 спринтов
● Ретроспектива поможет улучшить процесс планирования

21.

Ключевые выводы
● Планирование спринта — это диалог между PO и командой
● Стори-поинты ≠ часы — это относительная мера сложности
● Planning Poker помогает достичь консенсуса в оценках
● Sprint Goal направляет команду в течение спринта

22.

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

23.

Добавление члена команды

24.

Назначение стори-поинтов