Scrum для проектного менеджера: роли, спринты и церемонии

Scrum это способ вести проект короткими повторяющимися отрезками: команда берёт кусок работы на одну или несколько недель, доводит его до готового результата и показывает заказчику. Потом цикл повторяется. Весь пугающий словарь вокруг метода сводится к четырём вещам, и каждую из них можно объяснить на кухонном примере.

Разбираю эти слова по очереди, свожу в таблицу с переводом на обычный язык и отдельно называю термины, которые новичку разрешено пропустить мимо ушей. После такого разбора фраза «на рефайнменте порежем эпик» перестаёт звучать как заклинание.

• Спринт: отрезок работы с заранее назначенным концом.
• Бэклог: очередь задач, отсортированная по важности.
• Роли: кто решает, кто расчищает дорогу, кто делает руками.
• Церемонии: четыре встречи, у каждой свой измеримый результат.

Почему словарь Scrum пугает сильнее самого метода?

В двух словах: барьер создаёт лексика. Спринт, бэклог, инкремент, велосити, рефайнмент: за английскими корнями прячутся вещи, которые менеджер и так делает каждый день, только называет их привычными словами. Переведите десяток терминов на русский, и метод перестанет выглядеть закрытым клубом со своими ритуалами. Дальше останется договориться о зонах ответственности и о длине рабочего отрезка.

Я много раз наблюдал одну и ту же картину. Менеджер приходит на первую встречу команды, слышит «зафиксируем скоуп спринта и посмотрим велосити», и внутренне выключается. Смысл фразы предельно бытовой: договоримся об объёме работы на ближайшие две недели и вспомним, сколько команда вытянула в прошлый раз.

Жаргон вырос из перевода. Метод описывали на английском, в русские команды он приехал транслитерацией, и половина слов осталась без нормального эквивалента. Отсюда ощущение, что для входа нужен отдельный языковой курс.

Второй источник страха такой: кажется, будто Scrum отменяет привычное планирование. Базовые навыки никуда не деваются, и первые шаги в планировании проекта работают внутри спринта ровно так же, просто горизонт становится короче. Меняется частота проверок, а не суть работы менеджера.

Что такое спринт и чем он похож на закупку продуктов на неделю?

В двух словах: спринт это отрезок работы с заранее назначенным концом, чаще от одной до четырёх недель. Команда договаривается, что успеет за этот срок, и внутри отрезка список задач не растёт. В финале появляется результат, который можно показать заказчику и потрогать руками, даже если он совсем небольшой.

Представьте закупку продуктов на неделю. Вы прикидываете, сколько будете готовить, берёте нужное в магазине и живёте на этом до следующего похода. Если посреди недели захотелось торта, вы записываете его в список на следующий поход. Спринт устроен так же.

Фиксированный конец даёт две вещи. Команда перестаёт работать в режиме бесконечной ленты задач, потому что у отрезка есть финал и понятная цель. Заказчик получает регулярную точку, где можно посмотреть результат и скорректировать курс, не дожидаясь конца всего проекта.

Внутри спринта задачи связаны между собой, и вытащить одну без другой часто невозможно. Здесь пригодится дисциплина, о которой я писал в разборе про управление зависимостями между задачами: если задача ждёт чужого результата, она сжирает половину отрезка простоем.

Длину отрезка команда выбирает сама. Короткие спринты дают частую обратную связь, но встречи начинают отъедать заметную долю времени. Длинные экономят на встречах ценой поздних сюрпризов.

Бэклог: чем очередь задач отличается от обычного списка дел?

В двух словах: бэклог это единый упорядоченный список всего, что команда собирается сделать по продукту. Ключевое слово здесь «упорядоченный»: наверху лежит то, что берут в ближайший спринт, внизу идеи без деталей. Список живёт постоянно, его чистят, дробят и пересортировывают по мере того, как появляется новая информация.

Бытовая аналогия: список дел по квартире, приклеенный к холодильнику. В обычном списке пункты лежат вперемешку, «поменять смеситель» соседствует с «когда-нибудь перекрасить балкон». В бэклоге пункты выстроены сверху вниз, и первые три расписаны до уровня «купить смеситель такой-то модели, вызвать мастера на субботу».

Верхние пункты обязаны быть мелкими и понятными. Огромная формулировка вроде «сделать личный кабинет» в работу не берётся, её сначала разбирают на куски. Механику я подробно показывал в материале про декомпозицию задач от эпика до конкретной задачи, и в Scrum она работает без изменений.

Порядок в очереди определяет владелец продукта, но опирается он на понятные критерии, а не на настроение. Для сортировки удобно брать готовые рамки: матрицу приоритетов RICE и MoSCoW команда осваивает за один вечер, зато споры «что важнее» сокращаются в разы.

Ещё одна деталь, которую новички пропускают: формулировка пункта важна не меньше приоритета. Задача «доработать форму» вернётся с вопросами, задача с описанием сценария и критериями приёмки уйдёт в работу сразу.

Кто такие владелец продукта и мастер Scrum?

В двух словах: ролей три. Владелец продукта решает, что делать раньше, и отвечает за порядок в бэклоге. Мастер Scrum следит за правилами и убирает препятствия у команды. Команда разработки делает работу и сама распределяет её внутри себя. Начальника над командой в этой схеме нет, решения о способе работы принимают исполнители.

Сравнение с ремонтом квартиры объясняет расстановку быстрее любой схемы. Владелец продукта это хозяин квартиры: он говорит, что кухня важнее гардеробной, и принимает работу. Мастер Scrum ближе к прорабу без права командовать: договаривается о лифте, выбивает пропуска, гасит конфликты. Бригада сама решает, кто кладёт плитку.

Самая частая поломка в этой конструкции: владелец продукта пропадает. Он появляется раз в месяц, приоритеты не обновляются, команда угадывает. Спринт при этом формально идёт, а результат никому не нужен.

Вторая поломка зеркальная. Мастер Scrum превращается в надзирателя, требует отчётов и раздаёт задачи поимённо. Самоорганизация после этого умирает за пару спринтов, встречи превращаются в планёрку со списком поручений.

Роль мастера держится на мягких навыках сильнее, чем на знании регламента. Половина его работы это разговоры: с командой, со смежниками, с руководством. Полезные приёмы я собирал в тексте про мотивацию команды для проектного менеджера, они закрывают большую часть ситуаций.

Что происходит на четырёх встречах Scrum?

В двух словах: церемоний четыре, и каждая отвечает на свой вопрос. Планирование отвечает «что берём на отрезок», ежедневная встреча «кто где застрял», обзор спринта «что получилось у заказчика на экране», ретроспектива «как нам работалось и что поменяем». Встреча без ответа на свой вопрос превращается в трату времени всей команды.

Бытовой пример: семья с общим бюджетом. Раз в месяц садятся и решают, на что тратят. Каждый вечер коротко сверяются, кто что успел. В конце месяца смотрят, что получилось, и отдельно обсуждают, почему опять переплатили за доставку. Ровно те же четыре разговора.

Ежедневная встреча ломается чаще остальных. Она превращается в отчёт руководителю: каждый по очереди рассказывает, чем занимался вчера, никто никого не слушает. Живая версия выглядит иначе: команда смотрит на доску и обсуждает задачи, которые застряли ближе всего к финишу.

Обзор спринта тоже часто вырождается. Команда показывает слайды с описанием того, что сделано, вместо работающего результата на экране. Заказчик кивает, вопросов не задаёт, потому что обсуждать презентацию бессмысленно. Смысл встречи возвращается ровно в тот момент, когда человек со стороны бизнеса сам щёлкает по кнопкам и вслух говорит, что ему неудобно.

Ретроспектива страдает от вежливости. Все хвалят друг друга, записывают «работать лучше» и расходятся. Пользу даёт только конкретное решение с ответственным и сроком, и таких решений хватает одного за спринт.

Распределённой команде эти встречи даются тяжелее: сложнее ловить сигналы, что человек застрял и стесняется сказать. Практики из материала про то, как вести проект, если команда удалённая, снимают львиную долю проблем с созвонами и часовыми поясами.

Как звучат термины Scrum в переводе на человеческий?

В двух словах: словарь ниже закрывает почти весь жаргон, который встретится на первых встречах. Слева термин, справа перевод обычными словами. Держите таблицу открытой первые пару спринтов, и через месяц она перестанет быть нужна. Заучивать определения наизусть смысла нет, слова прилипают сами через практику.

Половина слов из таблицы живёт в трекере, и там же они становятся понятными быстрее всего. Настройка доски со столбцами и спринтами разобрана в тексте про Trello, Notion и Jira в управлении проектами: увидев бэклог глазами, термин запоминаешь за минуту.

Какие слова из жаргона можно не учить вообще?

В двух словах: часть терминов нужна тренерам и тем, кто масштабирует Scrum на десятки команд. Новичку они не пригодятся ни на первом спринте, ни на десятом. Пропустите велосити, story points, burndown chart, покер планирования и сложные надстройки: смысл этих слов доходит сам, когда команда упирается в задачу, ради которой их придумали.

1. Велосити. Среднее количество работы за отрезок. Цифра полезна команде для собственных прогнозов, но превращается в оружие, стоит руководству начать сравнивать команды между собой.
2. Story points. Условные единицы сложности вместо часов. Первые спринты спокойно живут на оценках «маленькая, средняя, большая».
3. Burndown chart. График сгорания задач. Доска с колонками показывает то же самое нагляднее.
4. Покер планирования. Способ оценивать задачи карточками. Полезная игра, к которой имеет смысл прийти после того, как встречи заработают.
5. Масштабирующие надстройки. Схемы для десятков команд на одном продукте. Пока команда одна, это чужая боль.

Отдельная категория слов относится к процессу вокруг спринта. Заказчик придёт с новой идеей посреди отрезка, и вопрос «куда её девать» закрывается процедурой. Здесь работает привычный порядок из разбора про управление изменениями в проекте: идея попадает в бэклог, владелец продукта решает её судьбу на следующем планировании.

Знание словаря само по себе никого не делает менеджером. Команды разваливают пропущенные обзоры, приоритеты в голове одного человека и ретроспективы ради галочки. Незнание слова «инкремент» в этом списке даже близко не стоит. Термины доучиваются за месяц. Дисциплина встреч ставится годами, и держится она на менеджере, который приходит на каждую встречу подготовленным и уходит с решением.

Что спрашивают чаще всего

Сколько человек должно быть в команде?

Scrum Guide называет ориентир: десять человек или меньше, включая владельца продукта и мастера Scrum. Причина простая: на ежедневной встрече в большой группе половина участников молчит и скучает. Когда людей становится больше, продукт делят на части и собирают вторую команду.

Работает ли Scrum вне разработки?

Метод придумали для продуктовых команд, но каркас переносится на маркетинг, редакцию, внутренние сервисы. Условие одно: работа должна делиться на куски, каждый из которых даёт видимый результат за отрезок. Для стройки или бухгалтерского закрытия схема подходит плохо, там порядок шагов задан жёстко.

Что делать, если заказчик меняет требования посреди спринта?

Новое требование записывается в бэклог и обсуждается на ближайшем планировании. Если изменение критично прямо сейчас, спринт останавливают и собирают заново, это законная процедура. Тихо подкладывать задачи в текущий отрезок хуже всего: цель размывается, а команда перестаёт верить обещаниям.

Нужен ли отдельный человек на роль мастера Scrum?

В маленькой команде роль часто совмещают с работой аналитика или менеджера. Совмещение владельца продукта и мастера в одном человеке создаёт конфликт: один и тот же сотрудник давит сроками и защищает команду от давления. Разводите эти две роли по разным людям.

Чем Scrum отличается от Kanban?

Scrum строится на отрезках с фиксированным составом работ, Kanban на непрерывном потоке с ограничением числа задач в работе. Команда поддержки, к которой прилетают срочные обращения, живёт по Kanban комфортнее. Продуктовая команда с планируемыми задачами выигрывает от спринтов.

Как понять, что Scrum в команде не прижился?

Тревожных признаков три. Задачи регулярно переезжают из спринта в спринт, обзор проводят без заказчика, а решения ретроспективы никто не выполняет. При таком наборе церемонии остались, смысл ушёл, и чинить надо процесс, а слова тут ни при чём.

Источники

• Scrum Guide, scrumguides.org: официальное описание ролей, событий и артефактов метода.
• Манифест гибкой разработки программного обеспечения, agilemanifesto.org: четыре ценности и двенадцать принципов Agile.