Привет всем, хотел рассказать о материалах при подготовке к сертификации PSM II от Scrum.org. Буду очень рад, если поделитесь своим опытом тоже :)
Sidenote: если вы апологет движения "сертификаты потеряли свою ценность" — я с вами соглашусь. И в отношении PSM I всё довольно просто — сертификация говорит что вы понимаете как работает фреймворк в общих чертах. В PSM II уже идёт работа с набранным в бою опытом применения скрама, потому она (сертификация) серьёзнее. Но ничего сверхъестественного в этом экзамене тоже нет. Кстати, сейчас в мире 6793 PSM II обладателей.
Подготовка к PSM II
Как писал Denis Salnikov, хорошо будет пройти Scrum.org open assesments перед сдачей несколько раз на 100%
- PSPO open — потому что там бывают вопросы, чтоб вы понимали как коучить PO и как идёт работа с ценностью. (кстати говоря, если вы дошли до PSM II, вы вполне можете сдать PSPO не мучаясь, что я и сделал).
- PSM — потому что это должно отскакивать на зубок. Ценности, роли, события, артефакты.
- PAL-E — чтобы через призму коучинга понимать менеджмент, и некоторые метрики, взрослость компании.
- PSK open — чтобы понимать основы работы с потоком.
- Nexus open — базовые основы пусть не самого популярного, но официального scrum.org решения для масштабирования.
Какие-то другие тесты надо проходить осторожно. В интернете довольно много подготовительных тестов: некоторые из них несколько PMBoK уклона, что норм для PMI-ACP, но другие прям адово извращают саму суть скрама, вводят какие-то новые роли, занимаются всяческим саботажем того, что вы практикуете к моменту подготовки к PSM II — берегите себя.
Коучинг, книжки, тренерство
Lyssa Adkins: Coaching Agile Teams — довольно лёгкая и универсальная книга небольших рецептов, затрагивающая роль agile coach / scrum master'a как фасилитатора, коуча, учителя. Прекрасно ложится на ваш персональный опыт, дополняя его.
Есть небольшой раздел по конфликтам, тоже описано довольно просто. Кстати говоря, хорошо (я бы сказал отлично) идёт с тренингами 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 scrum master, это брошюрка от Барри Овериима о том, какие роли играет (может играть) scrum-мастер — это прям кладезь косвенных ответов на вопросы в PSM II и в целом в вашей саморефлексирующейся scrum-мастер-карьере. Так как понимание того, кем является SM бывает правильное и неправильное. И при неправильном раскладе, ожидают от SM совсем не того, о чем написано в гайде.
Serious Scrum blog — коллективный блог от корифеев индустрии, с прояснениями нетривиальных ситуаций и разбором многих пониманий.
Actionable Agile Metrics — просто хорошо почитать про метрики книжку.
Тренинги — хотя бы на каком-то базовом уровне вы должны лично прощупать роль scrum-мастера как тренера на уровне команд, специалистов, или целой организации. Ведете ли вы воркшоп по визуализации потока, или сессию по парному дебаггингу у девопсов, или в течении нескольких часов рассказываете про основы скрама — не важно. Важно, что у вас копится опыт бытовых примеров проявления ценностей, поведения команд в разных условиях, и ускоряется цикл обратной связи.
Cynefin
Важно быть знакомой (-ым) с фрейворком Дейва Сноудена для принятия решений в разных типах систем. Серебряных пуль не бывает.
Long Story Short: есть алгоритм принятия решений в зависимости от запутанности системы. И разложил (всё еще раскладывает) по полочкам валлиец Дейв Сноуден. Когда допетрите более менее до основ, очень советую поискать его категоризацию внутри хаотичного квадранта. Это прям еще один микромир внутри :)
Чуть подробнее тут (статейка) и тут (видео от самого Сноудена)
Technical Excellency Foundations
Довольно обширная тема, тесно переплетающаяся Continuous Improvement -> инженерные практики, которые помогают выстраивать процессы и распределять знания более эффективно. Парное программирование, моббинг (mobbing), TDD, работа с техническим долгом — это всё в этом разделе.
- Сюда входит очень много блогов (самого Kent Beck, например),
- Scrum & XP from the Trenches Книберга (за простые и жизненные примеры),
- Extreme Programming Explored (норм, но не пушка),
- Мартина Фоулера книжки, если чуть более техническое,
- Uncle Bob со своими книжками, аля Agile Development, где он связывает практику с Agile-принципами.
Возможно, такое количество литературы и не нужно. По факту, нужно понимать те или иные подходы (пусть и неглубоко) с точки зрения того, что они глубоко наследуют сами принципы Agile-манифеста. Опять же, необязательно знать все детали, надо понимать Agile-ценности, лежащие в основе.
DevOps
Нужно понимать mindset, понимать что автоматизация и упаковывание рутинных вещей в шаблоны, которые не зависят от потенциальной косолапости — это фактор митигации риска. Понимать что такое (да и к вашему опыту в IT это точно уже известно, если вы решили на PSM II придя из айти отрасли сдать) Continuous Delivery, Deployment, вот это всё.
Хочется заметить, что зачастую в организациях DevOps это специалист. Не забываем что это про mindset. И всегда связываем это с кросс-функциональностью в рамках команды. DevOps mindset у разработчиков (не зря же Dev+Ops) учит новому, формирует полезный опыт, позволяет команде покрывать весь бизнес-процесс для доставки клиенту целиком. Отдельные DevOps команды это скорее скатывание в функциональные колодцы (и компонентный отдел). Лучше встройте таких специалистов в каждую команду, или прокачивайте экспертизу у самой команды разработки.
^^ в целом как и с любой инженерной практикой, надо просто видеть исток самих принципов гибкого мышления, и эпирицизма. Не нужно много допетривать: любая итеративность, если потом делаются выводы и ситуация исправляется — всегда хорошо. Любая автоматизация рутины, с защитой от дурака — хорошо. Чем раньше видим проблемы — тем лучше.
Вот тут читайте и понимайте насколько близко всё к манифесту.
Evidence-Based Management
В последнее время вполне оформившаяся тема — Доказательный Менеджмент.
На самом деле, скорее всего глубоких вопросов тут ждать не стоит, от scrum.org недавно относительно только вышел гайд по теме. Но, это работа с метриками и пониманием положения компании на рынке. Если вы проходили от ICAgile тренинги по Business Agility, или просто коучите / знакомы с темой, покажется всё довольно простым и логичным. По сути этот топик пытается ответить на вопросы как правильнее измерить улучшение результатов команды, скорость доставки, и увязать это с рыночными нишами и потенциально упущенной выгодой.
Maturity-модели
PALe maturity canvas конкретно зубрить точно не надо, не тот калибр. Но, к моменту сдачи PSM II / A-CSM круто в общих чертах понимать Maturity-модели (KMM, Scrum Maturity Model, Agile Leadership Maturity). Это поможет вам же сделать маппинг вашей организации на уровень взрослости. Всегда приятно порефлексировать :) Если знакомы со спиральной динамикой — она тоже хорошо дополняет понимание уровней гибкости и выживаемости компаний.
Kanban-практики
Kanban for Scrum Teams (тут вот в позапрошлом году гайд подоспел), ну или в моём случае KMP II помог (спасибо Пикулеву и Пименову). Понимание принципов работы с потоком, смысла ограничений на работу в прогрессе, ценности завершения работ, вреда 100% утилизации.
Наметился тренд вовсю использовать системный подход, в канбане он чуть ли не в основе лежит, в скраме он менее явный (ибо в скраме как во фреймворке такие конкретные вещи не регламентируются). Так вот системное мышление, системный подход, теория ограничений, теория очередней (системы массового обслуживания, помним такое?), проблемы локальной оптимизации.
Ах, да. Канбан еще знакомит более формально с такими метриками как 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 понять проще всего, потому что этот тот же скрам, с небольшими масштабируемыми дополнениями.
SAFe — хотя бы посмотреть базовые видео с объяснениями, потому что это самый популярный Enterprise Agile фреймворк в мире.
LeSS / LeSS Huge — потому что это ощутимо более легковесный чем SAFe, но при этом намного более популярный (чем Nexus) и интуитивный фреймворк без миллиона ролей и с теми же ценностями, что и в простом Scrum.
DaD (Disciplined Agile Delivery) — если вы живете в PMBoK мире :)
Заметочка: масштабировать, судя по nexus, можно если у вас 2 или больше команд.
У меня большого опыта с масштабированием нет, поэтому больше не напишу.
Вдогонку, что не менее важно
Опыт и только опыт: приципы понимания и формирования Цели Спринта (Sprint Goal), Definition of Done, понимания что имеют ввиду когда говорят Definition of Ready (хоть это и неофициальный термин). Как работать с командой, чтобы сформировать эти вспомогательные для прозрачности артефактов сущности.
Туда же и относятся события скрама, зачем и как фасилитировать, кого можно звать, какой ивент даёт формальную возможность адаптироваться для тех или иных вещей.
Понимание способов упорядивания задач в Бэклоге. Именно упорядочивания (начиная с 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'a.
Это проходит хорошо, весело и довольно продуктивно, потому что при хорошем тренере вы процентов 70-80 итак будете обсуждать практику и кейсы. Но тренинг сам по себе не является обязательным шагом к экзамену, главное — опыт и сам экзамен.
Сам экзамен
Страница для покупки попытки: https://www.scrum.org/professional-scrum-master-ii-certification
Цена, время, проходной балл всё те же: $250, 90 min, 85%.
Про сам процесс сдачи хорошо написано у Дениса Сальникова (aka Agile Expat).
Времени более чем достаточно, тест с 2018 стал несколько легче, в итоге сам я сдал с одной ошибкой:
Фух, надеюсь кому-то это поможет :) Удачи и стойкости! Повторяю что ничего прям-таки сложного в этом экзамене нет.
