Scrum-мастер: карта курса, профессия и путь к сертификации PSM I

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

Этот курс — про второй способ. Экзамен PSM I мы тоже сдадим, и сдадим уверенно, но как побочный эффект понимания, а не как результат зубрёжки карточек.

Статья, которую вы читаете, — это карта. Она отвечает на четыре вопроса: зачем вообще нужна роль Scrum-мастера, что такое Scrum в сжатом виде, как устроен путь к PSM I и в каком порядке читать остальные тринадцать статей.

Проблема, ради которой всё это придумали

Начнём не со Scrum, а с задачи, которую он решает.

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

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

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

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

Три столпа связаны жёстко: каждый следующий бессмыслен без предыдущего. Это не абстракция, а рабочий диагностический инструмент — почти любая поломка в Scrum-команде сводится к тому, что один из столпов выбит.

Запомните эту таблицу — она пригодится и на экзамене, и в первый рабочий день.

Scrum за один экран

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

Весь фреймворк умещается в короткий список, и на экзамене его нужно знать буквально:

Обратите внимание на слово «обязательство» (commitment). Это нововведение редакции 2020 года, и оно ключевое для понимания: артефакт без обязательства — просто список. Product Backlog без Product Goal — свалка хотелок. Increment без Definition of Done — «вроде работает у меня локально».

Подробный разбор каждого элемента — в статьях «Scrum Guide построчно», «Три ответственности», «События Scrum» и «Артефакты и обязательства».

Кто такой Scrum-мастер на самом деле

Теперь главное. Scrum Guide 2020 формулирует роль так: Scrum-мастер отвечает за эффективность Scrum-команды и делает это, помогая команде улучшать свои практики в рамках фреймворка. Scrum-мастер — «истинный лидер, служащий Scrum-команде и организации в целом».

Служение раскладывается на три контура.

Разница между контурами — не в важности, а в горизонте. Помощь команде даёт эффект за один-два спринта, работа с Product Owner — за квартал, изменение организации — за год и больше. Начинающие Scrum-мастера почти всегда застревают во внутреннем круге: там результат виден быстро и там комфортно. Признак роста — когда вы начинаете тратить время на внешние контуры.

Что написано в Guide, что делают на практике и чего делать не стоит

Это разделение будет проходить через весь курс, и здесь — первая, самая важная его порция.

Последний пункт — классическая ловушка PSM I. Формулировка Guide: Scrum-мастер обучает команду держаться в тайм-боксе и обеспечивает, чтобы событие состоялось, но если Scrum-мастер участвует в Daily Scrum, он делает это как Developer — то есть только когда сам работает над элементами Sprint Backlog.

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

Путаница здесь стоит людям карьеры, поэтому разложим явно.

Последняя строка — самая честная. Хороший Scrum-мастер работает на собственное устаревание в конкретной команде. Если через год команда без вас не может провести планирование — это не признак вашей незаменимости, а признак того, что коучинг не сработал.

Про классическое проектное управление и его инструментарий — трек Project Management и материалы по PMBoK; здесь мы их не дублируем, а показываем, где границы.

Сценарий: «Сделайте мне отчёт по загрузке команды»

Реалистичная ситуация, которая случится с вами в первые месяцы.

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

Плохой ответ №1 — подчиниться. Вы заводите таймтрекинг. Через месяц разработчики научаются проставлять красивые восемь часов, данные становятся фикцией, а вы — надзирателем. Прозрачность (первый столп) уничтожена вашими руками.

Плохой ответ №2 — отказать со ссылкой на Guide. «В Scrum такого нет». Вы формально правы и практически проиграли: вас записывают в бесполезные догматики, а отчёт всё равно заведут через голову.

Рабочий подход — разобраться в потребности за просьбой. Отчёт о загрузке никому не нужен сам по себе; за ним всегда стоит настоящий вопрос. Задайте его вслух: «Какое решение вы хотите принять на основании этих данных?»

Обычно выясняется одно из трёх:

1. «Я не понимаю, чем занята команда» — потребность в прозрачности. Ответ: пригласить на Sprint Review, дать доступ к Product Backlog с Product Goal, показать инкремент. Это ровно то, для чего артефакты и созданы.
2. «Мне кажется, мы делаем мало» — потребность в предсказуемости. Ответ: показать, сколько элементов бэклога доведено до Done за последние спринты, и обсудить, что мешает. Метрики потока — тема статьи «Эмпиризм и метрики» и трека DORA и инженерные метрики.
3. «Мне надо обосновать бюджет наверху» — потребность в аргументах. Ответ: помочь собрать данные, которые не разрушают доверие, — поставленную ценность вместо потраченных часов.

Обратите внимание на структуру хода: вы не спорите о фреймворке, вы переводите разговор с решения («заведи таймтрекинг») на проблему («что вы хотите понять»). Это базовый приём, и ему посвящена статья «Коучинг команды, конфликты и сопротивление».

Откуда взялся Scrum

Короткая историческая канва помогает не путать первоисточники с наслоениями. На экзамене история не спрашивается, но понимание, что Scrum Guide менялся, спасает от споров с людьми, читавшими редакцию 2011 года.

Ключевое изменение 2020 года: исчез термин Development Team как отдельная сущность внутри Scrum-команды. Раньше говорили «Scrum-команда = PO + SM + Development Team», теперь — одна команда, внутри которой есть три ответственности. Это не косметика: правка убирает деление на «тех, кто решает» и «тех, кто делает». Экзаменационные вопросы проверяют именно новую формулировку, а половина статей в интернете написана по старой — это главная причина, почему нужно читать первоисточник, а не пересказы.

Путь к PSM I

Теперь про сертификацию. PSM I (Professional Scrum Master I) — экзамен от Scrum.org, организации, основанной Кеном Швабером в 2009 году.

Формат

Экзамен проверяет знание Scrum Guide, а не ваш опыт. Это принципиально: если в вашей компании принято, что Sprint Backlog утверждает менеджер, а в Guide написано иначе, — на экзамене верен Guide. Разделяйте два режима мышления: «как правильно по Guide» и «как бывает в жизни». Курс будет постоянно указывать, где мы находимся.

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

Соседние сертификации

Практический совет: если платит работодатель и важна «корочка с тренингом» — CSM. Если вы платите сами и хотите сертификат, который что-то говорит о знаниях, — PSM I. Отношение рынка к ним примерно одинаковое, но PSM I дешевле и его нельзя получить, просто отсидев два дня в аудитории.

План подготовки на пять недель

Что делать конкретно:

1. Прочитать Scrum Guide целиком. Это 13 страниц, полчаса. Потом ещё раз, с карандашом, отмечая слова «accountable», «must», «may», «should» — экзамен строится на этих различиях. Официальный текст: scrumguides.org.
2. Пройти бесплатный Scrum Open. На scrum.org/open-assessments лежит открытый тест: 30 вопросов, 30 минут, проходной те же 85%. Правило: не идти на платный экзамен, пока не получаете 100% на Scrum Open три раза подряд с разными наборами вопросов.
3. Пройти Product Owner Open и Developer Open. Экзамен PSM I задаёт вопросы обо всех трёх ответственностях, а не только о вашей.
4. Читать Scrum Guide в оригинале. Русский перевод хорош, но экзамен на английском, и разница между «ensures» и «is accountable for» решает вопросы.
5. Изучить Scrum Glossary — там есть термины, которых нет в Guide, но которые встречаются в вопросах.

Чего делать не надо: покупать «дампы» с реальными вопросами. Кроме этической стороны, они устарели — большинство наборов в сети написаны по редакции 2017 года и содержат прямо неверные ответы для 2020-й.

Три вопроса в формате PSM I

Потренируемся прямо сейчас. Отвечайте, не подглядывая.

Вопрос 1

Кто отвечает за упорядочивание элементов Product Backlog?

• A. Scrum-мастер
• B. Product Owner
• C. Developers
• D. Стейкхолдеры

Ответ: B. Guide прямо говорит: Product Owner отвечает (accountable) за упорядочивание элементов Product Backlog. Тонкость, на которой ловят: PO может делегировать саму работу по упорядочиванию — но ответственность остаётся на нём. Вариант C неверен, хотя Developers участвуют в уточнении бэклога и дают оценки; вариант D неверен, потому что стейкхолдеры влияют через PO, а не напрямую. Логика за правилом: если порядок бэклога может менять кто угодно, исчезает единая точка принятия решения о ценности, и команда начинает получать противоречивые приоритеты от разных людей.

Вопрос 2

Спринт длится четыре недели. На второй неделе становится ясно, что Sprint Goal потерял смысл: рынок изменился. Кто может отменить спринт?

• A. Scrum-мастер
• B. Developers большинством голосов
• C. Product Owner
• D. Стейкхолдер, который платит за разработку

Ответ: C. Только Product Owner имеет полномочия отменить спринт. Причина не в иерархии, а в том, что спринт отменяется, когда Sprint Goal устарел, — а цель спринта существует для достижения цели продукта, за которую отвечает PO. Никто другой не находится в позиции, позволяющей сделать этот вывод. На практике решение почти всегда обсуждается со всей командой, но формальная ответственность одна. Дополнительный факт для экзамена: отмена спринта — событие редкое и травматичное, потому что оно уничтожает уже начатую работу; чаще правильный ход — не отменять спринт, а пересмотреть Sprint Backlog внутри него.

Вопрос 3

Выберите все верные утверждения о Daily Scrum. (Несколько правильных ответов)

• A. Он длится не более 15 минут
• B. Каждый участник обязан ответить на три вопроса: что сделал, что сделаю, что мешает
• C. Он проводится в одно и то же время и в одном и том же месте каждый рабочий день
• D. Присутствие Scrum-мастера обязательно
• E. Это событие для Developers

Ответ: A, C, E. Вариант B — самая частая ошибка: три вопроса были в редакциях до 2020 года, сейчас Guide явно говорит, что Developers могут выбрать любую структуру и технику, лишь бы она продвигала к Sprint Goal. Вариант D неверен: Scrum-мастер обеспечивает, чтобы событие проводилось, но участвует только если сам работает над элементами Sprint Backlog. Постоянные время и место (C) — не бюрократия: это устраняет ежедневные переговоры о расписании, то есть снижает трение до нуля.

Если вы ошиблись хотя бы в одном — это нормально и именно поэтому курс состоит из четырнадцати статей, а не из одной. Больше вопросов и разбор типичных ловушек — в статье «Экзамен PSM I».

Карта курса

Курс идёт от смысла к механике, от механики к навыкам и от навыков к выживанию в реальной организации.

Блок 1. Фундамент — зачем всё это.

• Agile-манифест: ценности и принципы, а не набор ритуалов — четыре ценности и двенадцать принципов, разбор того, что авторы имели в виду, и почему «мы делаем аджайл» обычно означает обратное.
• Scrum Guide построчно: что там написано на самом деле — чтение первоисточника с комментариями, разбор ключевых формулировок и различий между редакциями.

Блок 2. Механика — из чего собран фреймворк.

• Три ответственности: Product Owner, Scrum Master, Developers — границы ответственности, типичные наложения, что происходит при совмещении ролей.
• События Scrum: спринт, планирование, дейли, обзор, ретроспектива — цель каждого события, тайм-боксы, что ломается при отмене.
• Артефакты и обязательства: цель продукта, цель спринта, Definition of Done — почему Definition of Done важнее, чем кажется, и как он связан с качеством.
• Работа с бэклогом: уточнение, декомпозиция, пользовательские истории, оценка — практики, которых нет в Guide, но без которых бэклог превращается в свалку.

Блок 3. Навыки — то, чем вы реально занимаетесь.

• Фасилитация: как вести встречи, чтобы они приносили пользу — конкретные форматы, работа с молчащими и доминирующими участниками, дизайн встречи.
• Коучинг команды, конфликты и сопротивление изменениям — мощные вопросы, работа с сопротивлением, когда коучинг не нужен и вредит.
• Эмпиризм и метрики: velocity, burndown и как ими злоупотребляют — что измерять можно, что нельзя, и как отвечать на «почему velocity упала».

Блок 4. Реальность — почему в жизни всё сложнее.

• Антипаттерны Scrum: карго-культ, зомби-скрам, мини-водопад — каталог поломок с диагностикой и лечением.
• Масштабирование Scrum: Nexus, LeSS, SAFe — что нужно для экзамена и что нужно знать про реальные внедрения.
• Экзамен PSM I: формат, подготовка, разбор типичных вопросов — концентрат подготовки и большой блок тренировочных вопросов.
• Первые 90 дней Scrum-мастера в новой команде — план действий: что делать в первую неделю, первый месяц, первый квартал.

Читать лучше подряд: статьи ссылаются друг на друга и постепенно наращивают сложность. Если вам нужен только экзамен и время поджимает — минимальный путь: 02 → 03 → 04 → 05 → 12.

Как этот курс связан с остальным порталом

Чтобы не дублировать материал, зафиксируем разделение:

• Трек Project Management смотрит на Agile сверху, с позиции управления проектом: там сравнение Agile и Scrum с другими подходами, Kanban и теория потока, оценка и планирование и фреймворки масштабирования. Здесь же мы стоим внутри команды и смотрим глазами Scrum-мастера.
• Трек Product Management отвечает на вопрос «что строить»: исследования, приоритизация, метрики продукта. Scrum-мастеру полезно понимать эту логику, чтобы помогать Product Owner.
• Раздел Management даёт классический контекст: модели жизненного цикла, PMBoK, PRINCE2 — то, с чем Scrum сосуществует в реальных компаниях.

Типичные ошибки начинающих Scrum-мастеров

Сводка того, что вы, скорее всего, сделаете, если не предупредить.

1. Стать администратором Jira. Начинается с «мне не сложно поправить статус», заканчивается тем, что доска — ваша, а не команды, и прозрачность держится на вашей памяти.
2. Защищать процесс вместо людей. «Так написано в Guide» — не аргумент в разговоре с уставшей командой. Сначала польза, потом ссылка на источник.
3. Проводить ретроспективы по одному сценарию. Через шесть одинаковых ретро люди отвечают на автомате. Формат нужно менять, и об этом статья «Фасилитация».
4. Молча терпеть нарушения. Product Owner не приходит на обзор, менеджер добавляет задачи в середине спринта, Definition of Done фиктивен — если это не проговаривается вслух, вы соглашаетесь.
5. Считать velocity показателем производительности. Это оценочная единица для планирования, а не KPI. Как только по ней начинают премировать, она перестаёт что-либо измерять.
6. Пытаться внедрить всё сразу. Организация переваривает изменения медленно. Одно улучшение за спринт, доведённое до конца, полезнее десяти начатых.

Мини-итог

• Scrum существует потому, что разработка продукта — эмпирическая работа: точность плана здесь не помогает, помогает короткий цикл обратной связи.
• Три столпа — прозрачность, инспекция, адаптация — работают только вместе, и почти любая поломка процесса диагностируется через них.
• Scrum-мастер отвечает за эффективность команды и служит трём контурам: команде, Product Owner, организации. У него нет формальной власти, и его успех измеряется тем, насколько команда обходится без него.
• Экзамен PSM I проверяет знание Scrum Guide, а не опыт: 80 вопросов, 60 минут, 85% проходной. Готовиться нужно по первоисточнику и открытым тестам Scrum.org, а не по пересказам и дампам.
• Всегда разделяйте три уровня: «так в Scrum Guide» — «так делают на практике» — «так делать не стоит». Курс будет маркировать их явно.

Источники

• The Scrum Guide 2020 — первоисточник, Кен Швабер и Джефф Сазерленд. Читать целиком, в оригинале.
• Scrum.org Open Assessments — бесплатные тренировочные тесты, включая Scrum Open.
• Scrum Glossary — официальный словарь терминов.
• Такеути Х., Нонака И. The New New Product Development Game, Harvard Business Review, 1986 — источник самой метафоры scrum.
• Schwaber K., Sutherland J. Software in 30 Days — короткая книга о том, зачем Scrum нужен менеджменту.
• Agile Manifesto — четыре ценности, официальный русский перевод.
• Evidence-Based Management Guide — подход Scrum.org к измерению ценности, пригодится в статье о метриках.

Что дальше

Начнём с фундамента: прежде чем разбирать механику Scrum, нужно понять систему ценностей, из которой он вырос. Иначе фреймворк действительно превращается в набор ритуалов.

Agile-манифест: ценности и принципы, а не набор ритуалов