'/%3e%3cpath%20d='M83.8172%20112C100.688%20112%20111.886%2098.2694%20112%2083.8882H44.0245C25.8409%2083.8882%2016.001%2094.3169%2016.001%20112H83.8172Z'%20fill='url(%23paint1_linear_101_577)'/%3e%3cpath%20d='M44.1725%2044.1138H16.0008C15.9465%2051.0963%2018.504%2058.2306%2024.2977%2064.0225L44.1706%2083.8881L52.8986%2075.3569L61.7636%2066.7019C63.2767%2065.2244%2063.2786%2062.7888%2061.7636%2061.3094L44.1725%2044.1138Z'%20fill='%233A5FFF'/%3e%3cpath%20d='M83.8248%2083.8862H111.996C112.051%2076.9037%20109.493%2069.7693%20103.7%2063.9774L83.8267%2044.1118L75.0986%2052.6431L66.2337%2061.2981C64.7206%2062.7756%2064.7187%2065.2112%2066.2337%2066.6906L83.8248%2083.8862Z'%20fill='%233A5FFF'/%3e%3cdefs%3e%3clinearGradient%20id='paint0_linear_101_577'%20x1='16.001'%20y1='30.055'%20x2='111.998'%20y2='30.055'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3clinearGradient%20id='paint1_linear_101_577'%20x1='111.998'%20y1='97.9451'%20x2='16.001'%20y2='97.9451'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3c/defs%3e%3c/svg%3e)
Каркас, а не инструкция по работе
Scrum задаёт ритм: команда берёт ограниченный объём работы, доводит его до готового состояния и показывает результат заинтересованным людям. Цикл повторяется с той же длительностью, поэтому со второго-третьего раза становится видно, сколько работы команда реально успевает, — и прогноз перестаёт быть догадкой.
Scrum не описывает, как проектировать, тестировать, оценивать или писать код. Он фиксирует только каркас: кто принимает решения о содержании, когда команда собирается и какие артефакты обязаны существовать. Всё остальное каждая команда достраивает под себя — именно поэтому два внешне одинаковых процесса могут выглядеть совершенно по-разному.
Отсюда главное ограничение: Scrum не решает проблемы сам. Он делает их заметными — незакрытые задачи в конце цикла, растущий список дефектов, обзоры без заказчика. Дальше нужны решения команды, а не более точное соблюдение правил.
- Требования уточняются по ходу, а не заданы полностью на старте.
- Результат можно нарезать на части по 1–4 недели.
- Команда 3–9 человек работает над одним продуктом.
- Заказчик или владелец продукта готов участвовать в обзорах.
- Содержание, срок и бюджет зафиксированы договором целиком.
- Работа приходит потоком мелких однотипных заявок — берите Kanban.
- Один человек ведёт несколько несвязанных проектов одновременно.
- Результат нельзя показать раньше самого конца проекта.
Артефакты и события
Артефакты отвечают на вопрос «что мы делаем и в каком состоянии работа», события — «когда мы об этом разговариваем». Если убрать любой элемент, остальные перестают работать: планирование без бэклога превращается в раздачу поручений, а обзор без готового результата — в показ слайдов.
Бэклог продукта
Упорядоченный список всего, что может понадобиться продукту. Живёт постоянно и переупорядочивается по мере уточнения приоритетов.
Бэклог спринта
Выбранная на цикл часть работ плюс план, как команда её выполнит. Меняется только командой и только внутри цели спринта.
Инкремент
Работающий результат, доведённый до готового состояния по критериям завершённости. Может быть выпущен, даже если решено не выпускать.
| СОБЫТИЕ | ДЛИТЕЛЬНОСТЬ | УЧАСТНИКИ | РЕЗУЛЬТАТ |
|---|---|---|---|
| Планирование спринта | до 4 ч | вся команда | цель спринта и состав работ |
| Ежедневная синхронизация | 15 мин | команда | план на день и снятые препятствия |
| Уточнение бэклога | 1–2 ч за цикл | владелец продукта, команда | верхние элементы понятны и оценены |
| Обзор спринта | до 2 ч | команда и заказчики | обратная связь и обновлённый бэклог |
| Ретроспектива | 1–1,5 ч | команда | 1–2 улучшения с ответственными |
С чего начать внедрение
Внедрять всё сразу не нужно. Достаточно провести один цикл целиком — с планированием, обзором и ретроспективой — и дальше исправлять то, что действительно мешает именно вашей команде.
- 1Соберите команду и назначьте ролиОпределите владельца продукта — человека, который принимает решения о содержании, — и того, кто отвечает за процесс. Команда должна включать всех, кто нужен для готового результата.до старта
- 2Наполните бэклог продуктаСоберите работы в один упорядоченный список. Верхние два-три цикла должны быть понятны и оценены, остальное может остаться крупными формулировками.1–2 дня
- 3Договоритесь о длине спринтаДве недели — рабочий выбор по умолчанию. Одна неделя даёт более частую обратную связь, но увеличивает долю времени на встречи.30 минут
- 4Сформулируйте критерии завершённостиЗапишите, что значит «готово»: код в основной ветке, тесты пройдены, документация обновлена. Без этого критерия обзор превращается в спор.1 час
- 5Проведите первый цикл целикомНе сокращайте встречи в первый раз, даже если кажется, что обсуждать нечего. Первый цикл нужен для калибровки, а не для рекордов.1–2 недели
- 6Включите метрики и ретроспективуПосле второго цикла появляется первая осмысленная скорость. С этого момента ретроспектива опирается на данные, а не на ощущения.со 2-го цикла
Что смотреть, чтобы понять, работает ли процесс
Из-за чего Scrum не приживается
Состав спринта меняется в середине
Ежедневная встреча превратилась в отчёт руководителю
Нет критериев завершённости
Скорость команды стала показателем для премии
Ретроспектива без решений
Владелец продукта недоступен
Разбор по темам
Как собрать Scrum в Shtab
Всё, что описано выше, настраивается из интерфейса без администратора: цикл, состав работ, оценка и отчёты собираются из штатных элементов рабочего пространства.
- 01Спринт с датами и целью: незавершённое переносится в следующий цикл или возвращается в бэклог по заданному правилу.
- 02Бэклог продукта — отдельный список: перетаскиванием переносите элементы в цикл, сумма оценок и остаток ёмкости видны сразу.
- 03Оценка в часах, сторипоинтах, деньгах или своих единицах — итог по циклу и скорость команды считаются автоматически.
- 04Отчёты: диаграмма сгорания, скорость по циклам и время задач в статусах — без выгрузки в таблицы.
- 05Критерии завершённости — чек-лист в шаблоне задачи: их видит каждый исполнитель, а не только автор регламента.
- 06Автоматизации закрывают рутину: смена статуса по условию, назначение исполнителя, уведомление о просроченном.
Частые вопросы
Рабочий диапазон — от трёх до девяти человек, включая всех, кто нужен для доведения работы до готового результата. Меньше трёх — встречи занимают больше времени, чем сама работа. Больше девяти — планирование и обсуждения растягиваются, и команду обычно делят на две с общим бэклогом.