Привет всем. Хочу рассказать о материалах для подготовки к сертификации PSM II от Scrum.org. Буду рад, если поделитесь своим опытом тоже :)
Sidenote: если вы апологет движения «сертификаты потеряли свою ценность» — я с вами соглашусь. В отношении PSM I всё довольно просто: сертификация говорит, что вы в общих чертах понимаете, как работает фреймворк. В PSM II уже идёт работа с набранным в бою опытом применения Scrum, поэтому она серьёзнее. Ничего сверхъестественного в этом экзамене тоже нет. Кстати, сейчас в мире 6793 обладателя PSM II.
Подготовка к PSM II
Как писал Denis Salnikov, перед сдачей полезно несколько раз пройти Scrum.org open assessments на 100%:
- PSPO open — там бывают вопросы, которые помогают понять, как коучить PO и как идёт работа с ценностью. Кстати, если вы дошли до PSM II, PSPO вполне можно сдать без мучений, что я и сделал.
- PSM — ценности, роли, события и артефакты должны отскакивать от зубов.
- PAL-E — чтобы через призму коучинга понимать менеджмент, некоторые метрики и взрослость компании.
- PSK open — чтобы понимать основы работы с потоком.
- Nexus open — базовые основы официального решения Scrum.org для масштабирования: пусть не самого популярного, полезного для понимания подхода Scrum.org.
К другим тестам стоит относиться осторожно. В интернете много подготовительных тестов: часть из них с уклоном в PMBoK, что нормально для PMI-ACP, другие извращают саму суть Scrum, вводят новые роли и занимаются саботажем того, что вы практикуете к моменту подготовки к PSM II. Берегите себя.
Коучинг, книжки, тренерство
Lyssa Adkins: Coaching Agile Teams — довольно лёгкая и универсальная книга небольших рецептов, затрагивающая роль agile coach / Scrum Master как фасилитатора, коуча и учителя. Она хорошо ложится на персональный опыт и дополняет его.
Есть небольшой раздел по конфликтам, тоже описанный довольно просто. Книга хорошо — я бы сказал, отлично — идёт вместе с тренингами ICAgile: ATF (Agile Team Facilitator) и ICAgile: ACC (Certified Agile Coaching). Во многих отзывах кричат про воду в книге. На самом деле это работающие рецепты в контексте опыта. Без опыта читается действительно довольно водно.
Gunther Verheyen’s Scrum Pocket Guide — must-книжка, к которой время от времени возвращаешься после прочтения. Она хорошо раскладывает Agile-принципы, Scrum-события, роли и артефакты. Для сдачи PSM II обязательно понимать Scrum Values и Agile Principles. Ещё у вас от зубов должно отскакивать, какие есть события и кто на них приходит, хоть ночью разбуди. Короче, карманный справочник на все случаи жизни.
Путь Scrum-мастера за авторством Зузанны Шоховой. Перевод МИФ нормальный, лучше всё же читать в оригинале :) Векторы развития SM, разные ипостаси SM, сервис Scrum-мастера для организации — всё это тут.
8 ролей Scrum-мастера (8 Stances of a Scrum Master, брошюрка от Барри Оверима) — о том, какие роли играет или может играть Scrum-мастер. Это кладезь косвенных ответов на вопросы в PSM II и в целом в вашей саморефлексирующей Scrum-мастер-карьере. Понимание того, кем является SM, бывает правильным и неправильным. При неправильном раскладе от SM ждут совсем не того, о чём написано в гайде.
Serious Scrum blog — коллективный блог от корифеев индустрии с прояснениями нетривиальных ситуаций и разбором разных пониманий.
Actionable Agile Metrics — просто хорошая книжка про метрики.
Тренинги — как минимум на базовом уровне нужно лично прощупать роль Scrum-мастера как тренера на уровне команд, специалистов или целой организации. Ведёте ли вы воркшоп по визуализации потока, сессию по парному дебаггингу у DevOps или в течение нескольких часов рассказываете про основы Scrum — неважно. Важно, что у вас копится опыт бытовых примеров проявления ценностей и поведения команд в разных условиях, а цикл обратной связи ускоряется.
Cynefin
Важно быть знакомой или знакомым с фреймворком Дейва Сноудена для принятия решений в разных типах систем. Серебряных пуль не бывает.
Long story short: есть алгоритм принятия решений в зависимости от запутанности системы. Разложил — и всё ещё раскладывает — по полочкам его валлиец Дейв Сноуден. Когда более-менее допетрите до основ, очень советую поискать его категоризацию внутри хаотичного квадранта. Это ещё один микромир внутри :)
Чуть подробнее — тут, в статье, и тут, в видео от самого Сноудена.
Technical Excellence Foundations
Довольно обширная тема, тесно переплетающая Continuous Improvement и инженерные практики, которые помогают эффективнее выстраивать процессы и распределять знания. Парное программирование, моббинг (mobbing), TDD, работа с техническим долгом — всё это в этом разделе.
- Сюда входит много блогов, например блог Kent Beck.
- Scrum & XP from the Trenches Книберга — за простые и жизненные примеры.
- Extreme Programming Explored — норм, не пушка.
- Книги Мартина Фоулера — если нужно что-то чуть более техническое.
- Книги Uncle Bob, вроде Agile Development, где он связывает практику с Agile-принципами.
Возможно, такое количество литературы не нужно. По факту нужно понимать те или иные подходы — пусть и неглубоко — с точки зрения того, что они наследуют принципы Agile-манифеста. Необязательно знать все детали, важно понимать Agile-ценности, лежащие в основе.
DevOps
Нужно понимать mindset: автоматизация и упаковывание рутинных вещей в шаблоны, которые меньше зависят от потенциальной косолапости, — фактор митигации риска. Нужно понимать, что такое Continuous Delivery и Deployment. К вашему опыту в IT это наверняка уже известно, если вы решили сдавать PSM II, придя из айти-отрасли.
Хочется заметить, что зачастую в организациях DevOps — это специалист. Не забываем, что речь про mindset. И всегда связываем его с кросс-функциональностью команды. DevOps mindset у разработчиков — не зря же Dev + Ops — учит новому, формирует полезный опыт, позволяет команде покрывать весь бизнес-процесс доставки клиенту целиком. Отдельные DevOps-команды — скорее скатывание в функциональные колодцы и компонентные отделы. Лучше встройте таких специалистов в каждую команду или прокачивайте экспертизу у самой команды разработки.
В целом, как и с любой инженерной практикой, нужно просто видеть исток принципов гибкого мышления и эмпиризма. Не нужно много допетривать: любая итеративность, если затем делаются выводы и ситуация исправляется, — хорошо. Любая автоматизация рутины с защитой от дурака — хорошо. Чем раньше видим проблемы, тем лучше.
Вот тут читайте и понимайте, насколько всё близко к манифесту.
Evidence-Based Management
В последнее время вполне оформившаяся тема — доказательный менеджмент.
На самом деле, скорее всего, глубоких вопросов тут ждать не стоит: гайд по теме у Scrum.org вышел относительно недавно. Это работа с метриками и пониманием положения компании на рынке. Если вы проходили тренинги ICAgile по Business Agility или просто коучите / знакомы с темой, всё покажется довольно простым и логичным. По сути, этот топик пытается ответить на вопросы, как правильнее измерить улучшение результатов команды и скорость доставки, а затем увязать это с рыночными нишами и потенциально упущенной выгодой.
Maturity-модели
PAL-E maturity canvas конкретно зубрить точно не надо, не тот калибр. К моменту сдачи PSM II / A-CSM круто в общих чертах понимать maturity-модели: KMM, Scrum Maturity Model, Agile Leadership Maturity. Это поможет вам же сделать маппинг вашей организации на уровень взрослости. Всегда приятно порефлексировать :) Если знакомы со спиральной динамикой — она тоже хорошо дополняет понимание уровней гибкости и выживаемости компаний.
Kanban-практики
Kanban for Scrum Teams — тут вот в позапрошлом году гайд подоспел. В моём случае ещё помог KMP II — спасибо Пикулеву и Пименову. Важно понимать принципы работы с потоком, смысл ограничений на работу в прогрессе, ценность завершения работ и вред 100% утилизации.
Наметился тренд вовсю использовать системный подход. В Kanban он чуть ли не в основе лежит, в Scrum менее явный, потому что Scrum как фреймворк такие конкретные вещи не регламентирует. Речь про системное мышление, системный подход, теорию ограничений, теорию очередей — системы массового обслуживания, помним такое? — и проблемы локальной оптимизации.
Ах да. Kanban ещё знакомит более формально с такими метриками, как Cycle Time, Lead Time, CFD, Spectral Analysis Chart. На практике многие команды довольствуются только своими burndown и молятся только на них, безальтернативно. Важно расширять используемые графики и инструменты.
Если вы играли в featureban / get kanban / changeban — кстати, ребята из reg.ru (Артур Нек) и setronica (Женя Степченко) шикарно проводят игры, если зарулите в Новосибушку, — многие термины и графики для вас знакомы.
Масштабируемые фреймворки: LeSS, SAFe, Nexus и DaD для некоторых :)
Nexus Guide как минимум и материалы по нему от самого Scrum.org. В целом Nexus понять проще всего, потому что это тот же Scrum с небольшими масштабируемыми дополнениями.
SAFe — как минимум посмотреть базовые видео с объяснениями, потому что это самый популярный Enterprise Agile-фреймворк в мире.
LeSS / LeSS Huge — ощутимо более легковесный, чем SAFe, при этом намного более популярный, чем Nexus, и интуитивный фреймворк без миллиона ролей и с теми же ценностями, что и в простом Scrum.
DaD (Disciplined Agile Delivery) — если вы живёте в PMBoK-мире :)
Заметочка: масштабировать, судя по Nexus, можно, если у вас две или больше команд.
У меня большого опыта с масштабированием нет, поэтому больше не напишу.
Вдогонку, что не менее важно
Опыт и только опыт: принципы понимания и формирования Цели Спринта (Sprint Goal), Definition of Done, понимания, что имеют в виду, когда говорят Definition of Ready — пусть это и неофициальный термин. А ещё то, как работать с командой, чтобы сформировать эти вспомогательные для прозрачности артефактов сущности.
Туда же относятся события Scrum: зачем и как фасилитировать, кого можно звать, какой ивент даёт формальную возможность адаптироваться для тех или иных вещей.
Понимание способов упорядочивания задач в бэклоге. Именно упорядочивания — начиная с Scrum Guide 2017, — а не приоритизации, как раньше. Можно приоритизировать по ценности, затем столкнуться с блокерами и перетасовать задачи в соответствии с разблокировкой следующей самой ценной задачи. Поэтому именно упорядочивание (ordering), а не приоритизация.
Про путь с сертифицированным тренингом: сдавать экзамен всё равно надо, тренинг необязательный
Если вам не хватает систематизации знаний или вы просто хотите пообщаться с тренером по куче кейсов и понетворкать — велкам.
По сути, тренинг к PSM II — Professional Scrum Master II / A-CSM, если вы любите Scrum Alliance, — это систематизация того, с чем вы и так скорее всего столкнулись в работе. Если:
- у вас года два опыта работы Scrum-мастером;
- у вас есть опыт работы с конфликтами;
- у вас есть опыт фасилитации Agile-мероприятий и встреч;
- вы умеете объяснять практически, как проявляются и в чём выражаются Agile-принципы и Scrum Values.
Соответственно, вы вспоминаете через призму своего опыта весь Scrum Guide, попутно чуть сильнее затрагивая метрики, Evidence-Based Management, коучинг и фасилитацию, работу с конфликтами, правильные и неправильные образы Scrum-мастера, а также масштабируемые фреймворки. В случае хорошего тренера вы ещё поизучаете и поприменяете Liberating Structures, а заодно погрузитесь в основы Kanban.
Это проходит хорошо, весело и довольно продуктивно, потому что при хорошем тренере вы процентов 70–80 и так будете обсуждать практику и кейсы. Тренинг сам по себе не является обязательным шагом к экзамену, главное — опыт и сам экзамен.
Сам экзамен
Страница для покупки попытки: https://www.scrum.org/professional-scrum-master-ii-certification
Цена, время, проходной балл всё те же: $250, 90 min, 85%.
Про сам процесс сдачи хорошо написано у Дениса Сальникова (aka Agile Expat).
Времени более чем достаточно, тест с 2018 стал несколько легче, в итоге сам я сдал с одной ошибкой:
Фух, надеюсь, кому-то это поможет :) Удачи и стойкости! Повторяю: ничего прям-таки сложного в этом экзамене нет.
Английская версия у меня в бложике.
Источник: Habr, «Опыт подготовки к сертификации Professional Scrum Master II (Scrum.org)».