'/%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, изнутри могут не иметь почти ничего общего.
Отсюда главное ограничение: Scrum не решает проблемы сам. Он делает их заметными: незакрытые задачи в конце цикла, растущий список дефектов, обзоры, на которые не приходит заказчик. Дальше решать придётся команде, и более точное соблюдение правил тут ничего не добавит.
- Требования уточняются по ходу, и полного описания на старте у вас нет.
- Результат можно нарезать на части по 1–4 недели.
- Команда до десяти человек вместе с владельцем продукта работает над одним продуктом.
- Заказчик или владелец продукта готов участвовать в обзорах.
- Содержание, срок и бюджет зафиксированы договором целиком.
- Работа приходит потоком мелких однотипных заявок — берите Kanban.
- Один человек ведёт несколько несвязанных проектов одновременно.
- Результат нельзя показать раньше самого конца проекта.
Артефакты и события
Артефакты отвечают на вопрос «что мы делаем и в каком состоянии работа», события — «где мы принимаем решения». Спринт идёт в списке событий первым, потому что вмещает остальные четыре и задаёт им ритм. Уточнение бэклога отдельным событием не считается, ведь команда занимается им между встречами, без тайм-бокса и жёсткого места в календаре. Уберите любой элемент, и остальные перестанут работать: планирование без бэклога превращается в раздачу поручений, а обзор без готового результата — в показ слайдов.
Бэклог продукта
Упорядоченный список всего, что может понадобиться продукту. Наверху стоит цель продукта — одно предложение о том, к какому состоянию продукт идёт. По ней же проверяют, нужен ли элемент вообще.
Бэклог спринта
Цель цикла, выбранные под неё работы и план, как команда их выполнит. Меняется только командой и только пока это работает на цель.
Инкремент
Работающий результат, доведённый до готового состояния по критериям завершённости. Может быть выпущен, даже если решено не выпускать.
| СОБЫТИЕ | ЧАСТОТА И ДЛИТЕЛЬНОСТЬ | УЧАСТНИКИ | ЧЕМ ЗАКАНЧИВАЕТСЯ |
|---|---|---|---|
| Спринт | 1–4 недели, длина постоянна | вся команда | готовый инкремент и данные для следующего цикла |
| Планирование спринта | до 4 ч при двухнедельном цикле | вся команда | цель цикла, состав работ и план, как их сделать |
| Ежедневная синхронизация | 15 мин | разработчики | план на день и препятствия с ответственными |
| Обзор спринта | до 2 ч при двухнедельном цикле | команда и заказчики | обратная связь и обновлённый бэклог |
| Ретроспектива | 1–1,5 ч при двухнедельном цикле | команда | 1–2 улучшения с ответственными |
| Уточнение бэклога (не событие) | 1–2 ч за цикл, без слота | владелец продукта, команда | верхние элементы понятны и оценены |
С чего начать внедрение
Внедрять всё сразу не нужно. Достаточно провести один цикл целиком — с планированием, обзором и ретроспективой — и дальше исправлять то, что действительно мешает именно вашей команде.
- 1Соберите команду и назначьте ролиНазовите владельца продукта — человека, который принимает решения о содержании. Назовите скрам-мастера и сразу договоритесь, что с него спрашивают: результативность команды и препятствия, которые она сама снять не может. Соблюдение расписания встреч в этот список не входит. Команда должна включать всех, кто нужен для готового результата.до старта
- 2Наполните бэклог продуктаСоберите работы в один упорядоченный список. Верхние два-три цикла должны быть понятны и оценены, остальное может остаться крупными формулировками.1–2 дня
- 3Договоритесь о длине спринтаДве недели — рабочий выбор по умолчанию. Одна неделя даёт более частую обратную связь, но увеличивает долю времени на встречи.30 минут
- 4Сформулируйте критерии завершённостиЗапишите, что значит «готово»: код в основной ветке, тесты пройдены, документация обновлена. Пока такого списка нет, приёмка держится на памяти и настроении.1 час
- 5Проведите первый цикл целикомНе сокращайте встречи в первый раз, даже если кажется, что обсуждать нечего. Первый цикл нужен для калибровки, ведь именно он показывает, сколько работы команда действительно успевает.1–2 недели
- 6Включите метрики и ретроспективуСчитать начинайте сразу, а доверять цифрам с третьего цикла, потому что по одной точке ничего не видно и нужна серия. С этого момента ретроспектива опирается на данные и разговор перестаёт держаться на ощущениях.с 3-го цикла
Что смотреть, чтобы понять, работает ли процесс
Из-за чего Scrum не приживается
В середину спринта докладывают работу
Ежедневная встреча превратилась в отчёт руководителю
Нет критериев завершённости
Скорость команды стала показателем для премии
Ретроспектива без решений
Владелец продукта недоступен
Темы про Scrum
Как собрать Scrum в Shtab
Спринт заводится отдельной сущностью, у которой есть свои даты, своя цель и свой состав работ. Ниже — из чего собирается описанный выше процесс.
- 01Спринт с датами и целью. Незавершённое переносится в следующий цикл или возвращается в бэклог по заданному правилу.
- 02Бэклог продукта — отдельный список, из которого элементы перетаскивают в цикл; сумма оценок и остаток ёмкости видны сразу.
- 03Оценка в часах, сторипоинтах, деньгах или своих единицах — итог по циклу и скорость команды считаются автоматически.
- 04Отчёты: диаграмма сгорания, скорость по циклам и время задач в статусах — без выгрузки в таблицы.
- 05Критерии завершённости живут чек-листом в шаблоне задачи, поэтому появляются в каждой новой карточке и попадаются на глаза каждому исполнителю.
- 06Автоматизации закрывают рутину: смена статуса по условию, назначение исполнителя, уведомление о просроченном.
Частые вопросы
Ориентир — десять человек и меньше, считая владельца продукта и скрам-мастера. Прежний норматив «от трёх до девяти разработчиков» заменили на общий верхний предел: по старому счёту команда из одиннадцати человек формально проходила. Если людей меньше трёх, встречи занимают больше времени, чем сама работа. Если больше десяти, планирование растягивается, и команду делят на несколько с общим продуктом: один бэклог, один владелец продукта, одна цель.