¶ Блок 3 "Основы использования Scrum
Scrum — это способ организовать рабочее время команды так, чтобы она регулярно поставляла результат, а не просто была постоянно занята задачами.
В основе Scrum лежат регулярные мероприятия. Они нужны не «для галочки», а чтобы:
-
команда понимала, что и зачем она делает,
-
работа шла предсказуемо,
-
проблемы выявлялись рано, а не в конце проекта.
Если мероприятия Scrum формально есть, но их цель не понятна — Scrum перестаёт работать и
превращается в набор встреч в календаре.
¶ Спринт (Sprint)
Спринт — это фиксированный отрезок времени, в течение которого команда работает над понятной целью и в конце показывает конкретный результат.
Длительность спринта — от 1 до 4 недель (чаще всего 1–2 недели).
Результат спринта — инкремент продукта: часть функциональности, которую можно показать заказчику, протестировать или даже выпустить в продакшен.
Важно: спринт — это не просто «период работы», а контейнер для всех остальных мероприятий Scrum. Все планирования, стендапы, ревью и ретроспективы происходят внутри спринта.
¶ Зачем нужен спринт
Спринт решает сразу несколько задач:
-
ограничивает горизонт планирования (не на месяцы вперёд),
-
помогает команде держать фокус,
-
позволяет регулярно получать обратную связь,
-
снижает риск «делать не то».
Вместо абстрактного «когда-нибудь закончим» появляется понятное:
«Через две недели у нас будет вот такой результат».
¶ Ключевые принципы спринта
-
Фиксированная длительность Длина спринта не меняется от раза к разу. Это создаёт ритм и предсказуемость.
-
Цель спринта У каждого спринта есть цель, отвечающая на вопрос: зачем мы вообще делаем эти задачи?
-
Ограниченные изменения Бэклог спринта не должен постоянно меняться. Новые задачи добавляются только если они несут критическую бизнес-ценность.
-
Готовность к использованию Результат спринта должен быть в состоянии «почти можно выпускать», а не «почти почти готово».
¶ Как выбрать длительность спринта
-
1 неделя — высокая динамика, быстрый фидбек, но больше встреч.
-
2 недели — самый популярный вариант, баланс скорости и стабильности.
-
3–4 недели — подходит для сложных доменов и тяжёлых релизов.
Важно: длина спринта выбирается осознанно и не меняется без причины.
¶ Чего не должно быть в спринте
-
бесконечного добавления задач,
-
размытых целей («просто поработаем над проектом»),
-
переносов всего подряд «на следующий спринт»,
-
ситуации, когда результат невозможно показать.
Если спринт заканчивается, а показать нечего — значит, проблема не в людях,
а в планировании или постановке задач.
¶ Короткий пример
Спринт на 2 недели. Цель спринта: пользователь может зарегистрироваться и войти в систему.
В спринт входят:
-
регистрация,
-
авторизация,
-
базовая валидация,
-
простые тесты.
В конце спринта:
-
форму можно открыть,
-
пользователь может зарегистрироваться,
-
QA может проверить,
-
заказчик может дать фидбек.
¶ Что такое Story Point (SP)
Story Point (SP) — это условная мера сложности задачи, которую используют команды разработки для оценки объёма и сложности работ.
Обычно Story Points начинают использовать, когда команда уже некоторое время работает вместе и успела выполнить достаточное количество задач разной сложности. Это помогает сформировать общее понимание того, что для команды является простой, средней или сложной задачей.
Вместо того чтобы писать:
- лёгкая задача,
- средняя задача,
- сложная задача,
команда использует Story Points.
Например:
- 1–2 SP — относительно простая задача;
- 3–5 SP — задача средней сложности;
- 5–8 SP — сложная задача.
Важно понимать, что SP не являются количеством часов или дней. Это относительная оценка сложности задачи внутри конкретной команды.
Для одной команды задача на 3 SP может быть средней, а для другой — уже сложной. Поэтому Story Points имеют смысл в контексте конкретной команды и её опыта.
¶ Планирование спринта (Sprint Planning)
Планирование спринта проводится в начале каждого спринта и определяет, чем команда будет заниматься в ближайший период времени.
Результат планирования — бэклог спринта: набор задач, которые команда реалистично планирует выполнить, исходя из приоритетов и своих возможностей.
Планирование — это не обещание «сделать всё», а совместное решение команды, что именно она берёт в работу.
¶ Три ключевых вопроса планирования
1. Почему этот спринт ценен?
Product Owner формулирует цель спринта — краткое описание того, какую ценность получит продукт или бизнес по итогам спринта.
Цель спринта:
-
помогает принимать решения по задачам,
-
задаёт общий фокус команде,
-
отвечает на вопрос «зачем мы делаем именно это».
Пример цели спринта: Пользователь может зарегистрироваться и восстановить пароль без участия поддержки.
2. Что мы будем делать?
Команда совместно с Product Owner выбирает задачи из бэклога продукта,
учитывая:
-
приоритеты,
-
зависимости,
-
ресурсы команды,
Важно: задачи не спускаются сверху — команда сама подтверждает, что она готова взять этот объём работы.
3. Как мы это будем делать?
Команда декомпозирует задачи на более мелкие шаги:
-
продолжительностью не более одного рабочего дня,
-
с понятным результатом,
-
с явными точками проверки.
Чем меньше и понятнее задачи — тем:
-
проще их оценить,
-
легче отслеживать прогресс,
-
ниже риск срыва спринта.
¶ Почему планируют только 70–80% capacity
Рекомендация планировать не более 70–80% capacity связана с тем, что:
-
всегда возникают незапланированные задачи,
-
появляются блокеры,
-
требуется время на коммуникацию,
-
часть работы оказывается сложнее, чем ожидалось.
Оставшийся буфер:
-
снижает стресс,
-
повышает качество,
-
делает выполнение спринта более предсказуемым.
¶ Частые ошибки при планировании
-
планировать «по максимуму» без запаса,
-
игнорировать реальные capacity и velocity,
-
давить на команду цифрами,
-
менять состав задач в середине спринта,
-
воспринимать план как контракт, а не прогноз.
Хорошее планирование — это не про героизм, а про реалистичные ожидания и устойчивую работу команды.
¶ Приоритизация задач
¶ RICE
RICE — это модель приоритизации,
которая помогает объективно сравнивать задачи
и принимать решения на основе данных, а не ощущений.
Метод особенно полезен, когда:
-
задач больше, чем capacity команды;
-
разные стейкхолдеры тянут в разные стороны;
-
нужно аргументированно объяснять приоритеты бизнесу.
¶ Формула RICE
RICE = (Reach × Impact × Confidence) / Effort
¶ Reach (Охват)
Сколько пользователей, клиентов или процессов
затронет задача за выбранный период времени.
Примеры:
-
500 пользователей в месяц;
-
3 команды внутри компании;
-
все новые пользователи продукта.
Важно:
-
период времени должен быть одинаковым для всех задач;
-
лучше использовать реальные данные, а не предположения.
¶ Impact (Влияние)
Насколько сильно задача повлияет на пользователя или бизнес.
Чаще всего используется относительная шкала:
-
3 — сильное влияние;
-
2 — среднее влияние;
-
1 — слабое влияние;
-
0.5 — минимальное влияние.
Примеры влияния:
-
рост конверсии;
-
снижение количества ошибок;
-
ускорение Time to Market.
¶ Confidence (Уверенность)
Насколько команда уверена в оценках Reach и Impact.
Обычно выражается в процентах:
-
100% — есть точные данные;
-
80% — есть косвенные данные;
-
50% — предположение;
-
<50% — гипотеза.
Важно:
-
низкая уверенность сильно снижает итоговый RICE;
-
это защита от «хотелок» без фактов.
¶ Effort (Усилия)
Сколько ресурсов потребуется на реализацию задачи.
Может измеряться в:
-
человеко-днях;
-
человеко-неделях;
-
story points.
Важно:
-
чем больше Effort, тем ниже итоговый приоритет;
-
Effort должен оцениваться командой, а не стейкхолдером.
¶ Пример расчета RICE
Задача: оптимизация онбординга
-
Reach: 1 000 пользователей в месяц
-
Impact: 2
-
Confidence: 80% (0.8)
-
Effort: 10 человеко-дней
RICE = (1000 × 2 × 0.8) / 10 = 160
Задачи с большим RICE получают более высокий приоритет.
¶ Когда RICE не стоит использовать
-
если все задачи примерно одинаковые;
-
если нет данных даже для грубых оценок;
-
если решения принимаются исключительно политически.
¶ MoSCow
MoSCoW — это способ разделить задачи по степени их важности.
Представим, что команда разрабатывает интернет-магазин и готовит первую версию продукта к релизу.
У команды есть следующие задачи:
| Задача | Приоритет | Почему |
|---|---|---|
| Регистрация и авторизация пользователей | Must have | Без этого пользователь не сможет нормально работать с системой |
| Добавление товаров в корзину | Must have | Основная функция интернет-магазина |
| Оформление заказа | Must have | Без этой функции невозможно совершить покупку |
| Поиск по товарам | Should have | Функция важна для удобства, но без неё можно запустить первую версию |
| Фильтрация товаров | Should have | Улучшает поиск нужного товара, но не является критичной для запуска |
| Избранные товары | Could have | Полезная функция, но её отсутствие не мешает основному сценарию покупки |
| Тёмная тема | Could have | Улучшает пользовательский опыт, но не влияет на основную работу магазина |
| Интеграция с бонусной программой | Won't have | Решили не включать в текущий релиз и перенести на будущее |
¶ Как выглядит итоговое распределение
Must have — обязательно сделать для релиза:
- регистрация и авторизация;
- корзина;
- оформление заказа.
Should have — желательно сделать, если хватит времени и ресурсов:
- поиск;
- фильтрация.
Could have — полезные дополнительные функции:
- избранное;
- тёмная тема.
Won't have — в этот релиз не входит:
- бонусная программа.