Экзамен PSM I: формат, подготовка, разбор типичных вопросов

Есть два способа провалить PSM I. Первый — не знать Scrum. Второй, гораздо более обидный и гораздо более частый: знать Scrum по опыту своей команды и не знать, что написано в Scrum Guide. Второй тип провала выглядит так: человек с тремя годами практики набирает 80–83% и искренне не понимает, где ошибся. А ошибся он там, где его компания годами делала «почти по Scrum»: назначала задачи на дейли, продлевала спринт «на пару дней», считала Sprint Review приёмкой у заказчика.

PSM I проверяет не ваш опыт. Он проверяет, отличаете ли вы правило от привычки. Это, кстати, ровно тот навык, ради которого Scrum-мастер и нужен команде: если вы сами не видите границу между «так в Scrum» и «так у нас сложилось», вы не сможете помочь команде её увидеть.

Эта статья — практическая. Мы разберём формат экзамена, честно оценим, чего он стоит, соберём план подготовки, вытащим повторяющиеся шаблоны формулировок и прорешаем пятнадцать заданий с полным разбором дистракторов. Предполагается, что предыдущие статьи трека вы уже прочитали: Scrum Guide построчно, Три ответственности, События Scrum, Артефакты и обязательства.

Формат: сухие факты

Экзамен Professional Scrum Master I проводится Scrum.org онлайн, без прокторинга, из любого места и в любое время после покупки пароля.

Три следствия из этой таблицы, которые определяют всю стратегию подготовки.

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

Второе: запас всего 12 ошибок. 85% — жёсткий порог. Для сравнения: у большинства IT-сертификаций порог 65–75%. Здесь нельзя «в целом понимать» — нужно понимать точно. Типичная картина провала: 6 ошибок по невнимательности (не прочитал «which two», не заметил «должен» против «может»), 4 ошибки на границе «Guide против практики», 3 — на действительно спорных формулировках. Итого 67 из 80, и вы в минусе на один вопрос.

Третье: язык — английский. Даже если вы читаете технические тексты свободно, юридически точные формулировки Scrum Guide требуют отдельного привыкания. The Scrum Master is accountable for — это не то же самое, что responsible for. Should — не то же самое, что must. Читайте Guide в оригинале, а не в переводе: перевод сглаживает ровно те оттенки, на которых строятся дистракторы.

Чем PSM I отличается от CSM

Вопрос возникает у всех, кто выбирает первую сертификацию.

Ни один из вариантов не «лучше». PSM I дешевле, строже и полностью самостоятелен — по нему видно, что человек читал первоисточник. CSM даёт два дня живого обучения с тренером, что для новичка без команды бывает ценнее сертификата. Практический совет: если вы уже работаете внутри Scrum-команды и вам нужна проверяемая планка знаний — берите PSM I. Если вы приходите в Agile «с нуля» и вам нужна структура и живая практика — курс с CSM или Professional Scrum Master (тренинг Scrum.org, который даёт в том числе попытку PSM I) окупится быстрее.

Что экзамен на самом деле проверяет

Scrum.org описывает компетенции Scrum-мастера через «фокусные области». Для PSM I центр тяжести — первая из них, остальные затрагиваются по краям.

Практически: 60–70% вопросов — это первая ветка, ещё 20% — вторая и третья, остальное распылено. Это значит, что Scrum Guide вы должны знать почти дословно, а остальное — на уровне здравого смысла, согласованного с ценностями Scrum.

Важно: экзамен построен на актуальной редакции Guide. Редакция 2020 года убрала многое, что до сих пор гуляет по интернету:

Чего больше нет в Scrum Guide (и любой вариант ответа, опирающийся на это, — неверный):

• три вопроса на Daily Scrum («что делал, что буду делать, что мешает») — убраны в 2020;
• «Development Team» как отдельная сущность внутри Scrum Team — теперь это Developers, а Scrum Team едина и не имеет подкоманд;
• «команда 3–9 человек» — теперь «Scrum Team обычно 10 или меньше человек»;
• рекомендация тратить на refinement «не более 10% времени команды» — этой цифры в Guide нет;
• слово «роль» в отношении PO/SM/Developers — теперь это «accountabilities», ответственности;
• обязательность Sprint Backlog как «прогноза» с оговорками про перевыполнение.

Чего в Scrum Guide не было никогда. Story points, velocity, burndown-диаграмма, planning poker, user story, Sprint Zero, hardening Sprint, релизный спринт, backlog grooming, «три амиго», роль тимлида, роль тестировщика внутри команды. Всё это — практики. Полезные, распространённые, но не Scrum. На экзамене вариант ответа, где команда «обязана» использовать story points, — всегда неверен.

Источники подготовки: что читать и чего избегать

Обязательный минимум.

1. Scrum Guide — 13 страниц. Прочитать целиком минимум четыре раза, один из них — вслух. Это не метафора: чтение вслух заставляет мозг обработать каждое слово, а именно в отдельных словах («may», «must», «typically», «accountable») спрятаны различия между вариантами ответа.
2. Scrum Open — бесплатный тест Scrum.org: 30 вопросов, 30 минут, порог 85%, неограниченное число попыток. Вопросы берутся из того же банка, что и часть экзаменационных. Критерий готовности: три подряд прохождения на 100%, причём вы можете объяснить каждый ответ, а не помните его.
3. Scrum Glossary — короткий словарь терминов Scrum.org. Полезен тем, что фиксирует термины вроде «эмерджентность», «technical debt», «Scrum Team» в трактовке экзаменатора.

Полезное сверх минимума. Nexus Guide и Evidence-Based Management Guide — на PSM I их знание требуется поверхностно (пара вопросов может касаться масштабирования и измерения ценности), но они бесплатны и читаются за час каждый. Про масштабирование мы говорили в Масштабирование Scrum, про метрики — в Эмпиризм и метрики.

Чего избегать. «Дампы» — наборы якобы экзаменационных вопросов с ответами, которые продают и раздают на сомнительных сайтах. С ними три проблемы. Первая: значительная часть ответов там просто неверна, особенно в вопросах, где надо выбрать «наиболее подходящее» действие. Вторая: большинство дампов собрано до редакции 2020 года и содержит «Development Team», «три вопроса дейли», «10% на refinement» — вы выучите то, за что вас на экзамене накажут. Третья, главная: заучивание дампов даёт ноль понимания, а вопросы на экзамене переформулируются. Люди, готовившиеся по дампам, стабильно набирают 70–80% и не понимают почему.

План подготовки на четыре недели

Расчёт на человека, который уже работает рядом с Scrum-командой и может выделять 5–7 часов в неделю. Если опыта нет совсем — растяните до шести недель и добавьте практику в любой команде, пусть даже учебной.

Три приёма, которые дают непропорционально большой эффект.

Журнал ошибок. Каждый неверный ответ в Scrum Open записывайте одной строкой: вопрос → мой ответ → верный ответ → почему я ошибся (не знал факт / не заметил квантор / спутал с практикой моей компании / неверно понял английскую формулировку). К концу третьей недели вы увидите, что ошибки кластеризуются по 2–3 причинам, и будете чинить причину, а не отдельный факт.

Тест «а что сломается». Про каждый элемент Scrum задайте себе вопрос: что произойдёт с командой, если его убрать? Нет Sprint Goal → нечего защищать при изменении объёма, любое изменение читается как срыв. Нет DoD → «готово» означает разное для разных людей, инкремент нельзя выпустить. Нет ретроспективы → проблемы процесса накапливаются молча. Это не мнемоника, это способ отвечать на вопросы, формулировок которых вы не встречали: если вы знаете, какую задачу решает элемент, вы выберете вариант, который эту задачу решает.

Отдельная тренировка на кванторы. Возьмите 20 вопросов и прочитайте только их формулировки, не отвечая: подчеркните must/should/may, best/most/first, all that apply, two, three, отрицания not/except. Это упражнение снимает больше половины «глупых» ошибок.

Как читать вопрос: анатомия и повторяющиеся ловушки

Вопросы PSM I делятся на три класса, и стратегия для каждого разная.

Дальше — восемь шаблонов дистракторов, которые повторяются десятками. Научитесь узнавать их в лицо, и скорость чтения вырастет вдвое.

1. Scrum-мастер как менеджер. «Scrum Master назначает задачи», «Scrum Master решает, сколько работы взять», «Scrum Master оценивает производительность разработчиков». Почти всегда неверно: Sprint Backlog принадлежит Developers, объём определяют они, оценка людей — не функция Scrum-мастера. Подробно — в Три ответственности.
2. Эскалация наружу вместо прозрачности внутри. «Сообщить руководству», «поднять вопрос в комитете», «попросить менеджера вмешаться» как первое действие. Первый ход Scrum-мастера почти всегда — сделать проблему видимой тем, кто может её решить: команде, PO, стейкхолдерам.
3. Нарушение жёстких правил. Продлить спринт, сократить спринт «раз всё сделали», пропустить ретроспективу «в этот раз», отменить Daily Scrum «раз все в одной комнате», выпустить «недоделанный» инкремент как Done. Это грубые нарушения, и они в вариантах ответа встречаются постоянно именно потому, что так часто делают в жизни.
4. Подмена практики правилом. «Команда должна использовать story points», «команда обязана вести burndown», «нужно провести Sprint Zero». Практика не может быть обязательной по Scrum.
5. Ложная демократия. «Команда голосованием решает, что войдёт в спринт вместо приоритетов PO», «команда сама выбирает Product Goal». Самоуправление касается того, как делать работу; что и в каком порядке — зона PO.
6. «Всегда» и «никогда» — но осторожно. В большинстве тестов крайние кванторы — признак неверного ответа. В Scrum это не так: часть правил действительно абсолютна (спринт не длиннее месяца; отменить спринт может только PO; ретроспектива завершает спринт; новый спринт начинается сразу после предыдущего). Проверяйте по Guide, а не по «правилу теста».
7. Ложная точность. «Daily Scrum длится ровно 15 минут» — нет, это максимум, таймбокс. «Sprint Planning длится 8 часов» — нет, максимум 8 часов для месячного спринта. Слово «максимум» и привязка к длине спринта — важны.
8. Смешение Done и приёмки. «Sprint Review — это когда заказчик принимает работу», «инкремент считается Done после подписания стейкхолдером». Готовность определяется Definition of Done, а Sprint Review — рабочая сессия по адаптации бэклога, а не гейт.

Мини-словарь формулировок

Разбор пятнадцати заданий

Ниже — задания в стиле PSM I. Формулировки авторские, но шаблоны и ловушки взяты из реального банка. Отвечайте сами, прежде чем читать разбор.

1. Кто отвечает за оценку (estimate) элементов Product Backlog?

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

Ответ: B. Scrum Guide прямо говорит: «Люди, которые будут выполнять работу, дают финальную оценку размера». Product Owner может влиять на оценку через обсуждение trade-off’ов («если убрать вот эту часть, станет меньше?»), но не назначать её. C неверен ещё и потому, что velocity в Guide отсутствует; D — потому что внутри Scrum-команды нет отдельных «аналитиков» с особыми правами: все, кто работает над инкрементом, — Developers.

2. Кто может отменить спринт?

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

Ответ: C. «Спринт может быть отменён, если цель спринта устаревает. Только Product Owner имеет полномочия отменить спринт». Это одно из немногих мест, где Guide использует слово «только», — и ровно поэтому вопрос популярен. Заметьте: PO может отменить спринт под влиянием команды или руководства, но полномочие принадлежит ему.

3. Команда за три дня до конца двухнедельного спринта выполнила всю работу из Sprint Backlog и достигла цели спринта. Что следует сделать?

A. Завершить спринт досрочно и начать следующий B. Провести Sprint Review и Retrospective раньше, спринт закончить в срок C. Обратиться к Product Owner за дополнительной работой, при этом цель спринта остаётся неизменной D. Дать команде три дня отдыха

Ответ: C. Длина спринта фиксирована и не сокращается из-за досрочного выполнения — отменить спринт можно только по причине устаревания цели, и только PO. Sprint Backlog — эмерджентный: Developers по мере появления новой информации могут взять дополнительную работу, согласовав её с PO, если она не подрывает цель спринта. A нарушает правило фиксированной длины. B — механическая ошибка: события привязаны к концу спринта. D игнорирует, что в спринте ещё есть ёмкость (хотя разговор о устойчивом темпе и техдолге вполне уместен — просто это не «ответ по Guide»).

4. Какие из перечисленных являются обязательствами (commitments) артефактов? Выберите три.

A. Sprint Backlog B. Product Goal C. Definition of Done D. Sprint Goal E. Increment F. Velocity

Ответ: B, C, D. Три артефакта — Product Backlog, Sprint Backlog, Increment. Их обязательства — Product Goal, Sprint Goal, Definition of Done соответственно. A и E — сами артефакты, не обязательства; F в Guide не упоминается вовсе. Это чистый вопрос на память, и он почти наверняка вам попадётся в том или ином виде. Смысл конструкции разбирался в Артефакты и обязательства.

5. Верно или неверно: Daily Scrum — это событие для отчёта Scrum-мастеру и Product Owner о прогрессе.

Ответ: неверно. Daily Scrum — событие Developers, чтобы проинспектировать прогресс к цели спринта и адаптировать Sprint Backlog. Scrum-мастер и Product Owner могут присутствовать, но участвуют как полноправные участники, только если сами работают над элементами Sprint Backlog. Формат «отчёт наверх» — классический признак зомби-скрама: событие происходит, эффекта нет.

6. Организация внедряет Scrum в команде, где раньше был проектный менеджер. Он спрашивает: кто теперь отвечает за управление рисками проекта? Лучший ответ Scrum-мастера:

A. Scrum-мастер — он снимает препятствия B. Product Owner — он отвечает за успех продукта C. Управление рисками распределено: короткий спринт и инкремент сами по себе снижают риск, PO управляет продуктовым риском через порядок бэклога, Developers — техническим через DoD и качество D. Риски в Scrum не управляются, это эмпирический процесс

Ответ: C. Здесь проверяется понимание, а не буква. Scrum не отменяет управление рисками — он встраивает его в структуру: ограниченная длина спринта ограничивает размер потерь, инкремент даёт раннюю обратную связь, порядок бэклога — инструмент снижения продуктового риска, DoD — технического. A и B назначают единственного «владельца рисков», что противоречит распределению ответственностей. D — карикатура на эмпиризм. Смежная тема разбиралась в Управлении рисками трека project-management.

7. Максимальная длительность Sprint Retrospective для месячного спринта?

A. 45 минут B. 1 час C. 3 часа D. 4 часа

Ответ: C. Таймбоксы для месячного спринта: Sprint Planning — до 8 часов, Sprint Review — до 4 часов, Sprint Retrospective — до 3 часов, Daily Scrum — 15 минут независимо от длины спринта. Для более коротких спринтов события обычно короче. Мнемоника, если совсем не запоминается: 8 → 4 → 3 → 15 минут, по убыванию, планирование самое длинное.

8. Developers в середине спринта обнаружили, что одна из взятых историй технически невозможна в текущей архитектуре. Что должен сделать Scrum-мастер в первую очередь?

A. Эскалировать ситуацию архитектурному комитету B. Убрать историю из Sprint Backlog C. Убедиться, что Developers сделали ситуацию прозрачной для Product Owner, и помочь им обсудить, как это влияет на цель спринта D. Организовать внеочередное Sprint Planning

Ответ: C. Шаблон «первое действие»: сделать проблему видимой тем, кто принимает решение, и помочь им поговорить. B — Scrum-мастер решает за Developers, нарушение самоуправления. A — эскалация наружу до попытки решить внутри. D — событие, которого нет в Scrum: пересмотр объёма происходит в рабочем порядке между Developers и PO, а не через ритуал. Обратите внимание: если бы вопрос звучал «что должны сделать Developers», верным был бы вариант про разговор с PO напрямую.

9. Организация требует, чтобы каждая Scrum-команда сдавала отчёт о выполнении спринта в PMO. Как поступить Scrum-мастеру?

A. Отказаться: отчётность не предусмотрена Scrum B. Сделать отчёт самому, чтобы не отвлекать команду C. Понять, какая потребность стоит за требованием, и предложить удовлетворить её через существующую прозрачность Scrum — инкремент, бэклог, участие в Sprint Review D. Поручить составление отчёта Product Owner

Ответ: C. Scrum не запрещает отчётность и вообще ничего не говорит о PMO. Задача Scrum-мастера — помочь организации получить нужную информацию способом, который не создаёт параллельного процесса: чаще всего PMO нужна предсказуемость и видимость, а это ровно то, что даёт инкремент и Sprint Review. A — догматизм, который в реальности разрушает доверие к Scrum-мастеру. B — Scrum-мастер как секретарь, скрывающий от команды организационное трение. D — перекладывание. Эта же логика — в Коучинг команды и сопротивление изменениям.

10. Верно или неверно: инкремент может быть выпущен пользователям только после Sprint Review.

Ответ: неверно. Guide прямо говорит, что инкремент может быть выпущен в любой момент спринта, и что за спринт может быть создано несколько инкрементов. Sprint Review — не гейт релиза и не приёмка, а рабочая сессия по инспекции результата и адаптации бэклога. Это один из вопросов, где практика многих компаний («релиз после демо») напрямую противоречит Guide.

11. В организации нет корпоративного Definition of Done. Кто должен его создать?

A. Scrum-мастер, поскольку он отвечает за качество процесса B. Scrum-команда C. Отдел качества D. Product Owner совместно с заказчиком

Ответ: B. «Если Definition of Done для инкремента является стандартом организации, все Scrum-команды должны следовать ему как минимуму. Если это не стандарт организации, Scrum-команда должна создать Definition of Done, подходящий для продукта». Ключевое слово — «Scrum Team», то есть все трое вместе, а не Developers и не Scrum-мастер отдельно. Второй половиной вопроса часто бывает: если корпоративный DoD существует, может ли команда сделать свой строже? Да — организация задаёт минимум, команда может усилить, но не ослабить.

12. Продукт разрабатывают четыре Scrum-команды. Сколько должно быть Product Backlog и сколько Product Owner?

A. Четыре бэклога, четыре PO B. Один бэклог, четыре PO C. Один бэклог, один PO D. Четыре бэклога, один PO

Ответ: C. Product Backlog один на продукт, Product Owner — один человек на продукт, независимо от числа команд. Каждая команда при этом имеет свой Sprint Backlog и свою Sprint Goal — они разные. Это база и для вопросов по масштабированию: Nexus строится ровно на этом инварианте, см. Масштабирование Scrum.

13. Что из перечисленного лучше всего описывает Sprint Goal? Выберите один вариант.

A. Список элементов Product Backlog, выбранных на спринт B. Единственная цель спринта, дающая связность и гибкость: она объясняет, зачем спринт нужен, и не меняется в течение спринта C. Обещание Product Owner стейкхолдерам о содержимом релиза D. Метрика, по которой измеряется производительность команды

Ответ: B. Sprint Goal — обязательство Sprint Backlog, единственная цель на спринт, создаваемая на Sprint Planning всей Scrum-командой. Она делает возможными переговоры об объёме: сам объём может меняться, цель — нет. A путает цель со списком (самая частая ошибка в жизни, а не только на экзамене). C превращает её во внешнее обещание. D — попытка приделать к цели измерение производительности, чего Scrum не делает; про злоупотребление метриками — в Эмпиризм и метрики.

14. Какие два утверждения о Scrum-мастере верны? Выберите два.

A. Scrum-мастер отвечает за эффективность Scrum-команды B. Scrum-мастер приоритизирует Product Backlog, когда PO недоступен C. Scrum-мастер — истинный лидер, который служит команде и организации D. Scrum-мастер отвечает за то, чтобы все элементы Sprint Backlog были завершены E. Scrum-мастер проводит performance review для Developers

Ответ: A и C. Guide: «Scrum-мастер отвечает за эффективность Scrum-команды» и «Scrum-мастера — истинные лидеры, которые служат Scrum-команде и более широкой организации». B нарушает границу ответственностей (PO может делегировать работу с бэклогом, но не Scrum-мастеру «по умолчанию», и приоритизация остаётся его подотчётностью). D — Scrum вообще не обещает завершения всех элементов, обещание касается цели спринта. E — линейное управление, не функция Scrum-мастера.

15. Sprint Review закончился, и стейкхолдеры попросили изменить приоритеты в бэклоге. Product Owner согласился. Что происходит дальше?

A. Изменения вносятся в Product Backlog, следующий спринт планируется с учётом новых приоритетов B. Изменения откладываются до следующего квартального планирования C. Текущий спринт отменяется D. Scrum-мастер согласует изменения с руководством

Ответ: A. Sprint Review существует ровно для этого: инспекция инкремента и адаптация Product Backlog. Guide говорит, что бэклог может быть скорректирован для новых возможностей. B противоречит эмпиризму (обратная связь есть — она не применяется). C — отмена спринта возможна только при устаревании цели спринта, а не при изменении приоритетов на будущее. D — лишний согласующий контур.

Если вы ответили верно на 13–15 — вы в хорошей форме. 10–12 — есть систематические пробелы, разберите каждую ошибку по журналу. Меньше 10 — вернитесь к Scrum Guide и статьям трека, экзамен пока рано.

Стратегия на самом экзамене

За сутки до. Прочитать Scrum Guide целиком последний раз. Не решать тесты — они на этом этапе только тревожат. Выспаться: на 45 секундах на вопрос усталость стоит дороже, чем любой недоученный факт.

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

Три прохода. Схема на диаграмме выше: первый проход — все 80 вопросов быстро, спорные помечаются флагом, но ответ ставится всегда (пустой ответ — гарантированно неверный, а вариант «наугад из двух» даёт 50%). Второй проход — только флаги. Третий — сверка двух-трёх фактов по Guide, если время осталось.

Что делать, если завис. Правило 60 секунд: если через минуту вы не сошлись сами с собой, отбросьте варианты, содержащие слова не из лексикона Scrum Guide («менеджер», «утверждает», «отчитывается», «назначает», «комитет»), из оставшихся выберите тот, который повышает прозрачность и оставляет решение у того, кто за него отвечает, — и идите дальше.

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

Если не сдали. Вы увидите процент и разбивку по фокусным областям. Это ценная информация: она показывает, какой блок проседает. Повторная попытка покупается отдельно; разумный интервал — одна-две недели активной работы над слабым блоком, а не «завтра ещё раз». Провал на 80–84% почти всегда означает не пробел в знаниях, а проблему со скоростью и кванторами — тренируйте чтение формулировок.

Что дальше после PSM I

PSM I — это порог входа, а не финиш. Он подтверждает, что вы знаете фреймворк. Он ничего не говорит о том, умеете ли вы фасилитировать сложную ретроспективу, работать с сопротивлением менеджера или помочь команде выстроить Definition of Done в легаси-системе. Именно поэтому PSM II требует практики: там вопросы в формате «вот ситуация на полстраницы, что вы сделаете и почему», и заучивание не помогает.

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

Мини-итог

• PSM I — 80 вопросов за 60 минут, порог 85% (68 из 80), английский, без прокторинга, сертификат бессрочный. Запас — 12 ошибок.
• Экзамен проверяет одно ключевое умение: отличать написанное в Scrum Guide от распространённой практики и от откровенного антипаттерна.
• Обязательный минимум подготовки: Scrum Guide в оригинале четыре раза (один — вслух), Scrum Open до трёх подряд 100% с объяснением каждого ответа, Scrum Glossary.
• Дампы вопросов вредны: значительная часть ответов неверна, большинство собрано до редакции 2020 года.
• Главные ловушки: Scrum-мастер в роли менеджера, эскалация вместо прозрачности, нарушение жёстких правил (длина спринта, отмена спринта, полнота событий), подмена практики правилом, ложная точность в таймбоксах, смешение Done и приёмки.
• Кванторы решают исход: must/should, best/first, choose two, NOT. Половина «глупых» ошибок — здесь.
• Тактика: три прохода, ответ ставится всегда, зависание не дольше 60 секунд, Guide открыт в соседней вкладке, но используется два-три раза.
• Сертификат — побочный продукт. Основная ценность — что вы прочитали первоисточник целиком и теперь видите границу между Scrum и тем, что называют Scrum у вас в компании.

Источники

• Scrum Guide 2020 — первоисточник, 13 страниц
• Scrum Open — бесплатный пробный тест Scrum.org
• Professional Scrum Certifications — актуальные формат, стоимость и условия
• Scrum Glossary — словарь терминов в трактовке экзаменатора
• Nexus Guide и Evidence-Based Management Guide — бесплатные дополнения, по часу чтения
• Ken Schwaber, Jeff Sutherland. Software in 30 Days — контекст, зачем всё это создавалось

Что дальше

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

Первые 90 дней Scrum-мастера в новой команде