Scrum guide через PMBoK: взгляд PMP

Статья будет полезна тем, кто думает о сертификации в отношении популярного Agile framework - Scrum, а также тем, кто пытается разобраться в модных течениях, ищет пути усовершенствования привычных подходов: classic или agile.

Меньше двух месяцев назад мною защищён статус Project management professional (PMP) Project management institute (PMI). По итогам приключения написана статья и инициирован волонтёрский проект PMI Moscow «Ретроспектива сертификации», лидером которого и являюсь.

Но, несмотря на 7 лет исполнения роли Product owner (startup и внутренний заказчик), мне не удалось познать 100% успеха гибких методологий – командных провалов было достаточно. Непонимание причин общих неудач приводит к повтору и личных ошибок. Кроме того, анонс изменения главной книги PMI говорит о переходе на принципы, что ближе к гибким методологиям. Это тенденция - большей гибкости не избежать.

Переключился на книгу, которая получена бесплатно в PMI.org после оплаты членства и шла довеском к PMBoK 6th edition: Agile practice guide. Имея опыт знакомства с литературой международного института, которая, скорее информирует чем учит, решил не тратить времени на чтение сухого текста: быстро пролистал 200 страниц и купил курс Joseph Philips "PMI-ACP". При покупке руководствовался пользой курса по classic project management, который использовал при подготовке к PMP. Но вот новый продукт Joseph Philips показался поверхностным и свёрстанным на скорую руку: по окончанию уверенности в знаниях не ощущалось. Сама сертификация Agile Certified Practitioner (PMI-ACP) по результатам проверки частоты упоминания на сайте hh.ru оказалась крайне непопулярной: 74 PMI-ACP vs 4285 PMP vs 1424 PSM vs 117 PSPO.

Приемлемых вопросников для подготовки к 3-х часовому экзамену PMI-ACP в интернете не нашлось. Зная, насколько элементы сертификационного тестирования изощрённы, бесконтрольно рисковать четырьмя сотнями у.е. не хотелось. Последней каплей в пользу отказа сертификации PMI-ACP стал бизнес завтрак PMI Moscow, где понял, что Kanban гораздо глубже в инструментарии, чем того требует знать книга PMI.

Выбор в пользу изучения Scrum framework сделан по следующим причинам:

• Личный опыт участия в инкрементальной поставке продукта в роли Product owner. Наверное, самым запоминающимся стал опыт 5-и летней давности, когда своими руками закрывал детище - marketplace юридических услуг (аналог популярной западной бизнес модели). Было много сожалений о распущенной команде, для результативного выхода из деструктивных воспоминаний требовалась работа над своими ошибками. Кроме того, обширный опыт подсказывал о существовании конфликта интересов между Product owner и Scrum master. Хочется развиваться больше в достижении долгосрочных целей так как "срочное" съедает "важное", делать правильные вещи мне видится важнее, чем делать правильно.
• Многогранный опыт работы со стороны бизнеса. Проекты провели меня сквозь 9 отраслей. Довелось поработать в маркетинге, PR, GR, юридическом блоке, финансах, продажах, на производстве, IT и даже были проекты в науке. Всё это активы в том числе в виде hard skills. Думаю, что Product owner с большей вероятностью сможет это монетизировать, нежели Scrum master.
  
• Возможность сертификации в условиях пандемии. В апреле 2020 года, сидя запертым в Москве, выбирал между Kanban, Lean и Scrum. Выбор пал в пользу последнего: в сравнении с классикой оффлайн курсов Scrum Alliance, на Scrum.org (детище Кена Швабера) экзамен дистанционный.
  
• Качество усвоения материала. В жизни проходил множество тренингов, «проглатывал» книги и видео. Но то качество «врастания» знаний, которое постиг, готовясь самостоятельно к сертификации PMP, не встречал. Поэтому формат сертификации Scrum Alliance, где приходится платить порядка 1000 у.е. и практически "автоматом" получить сертификат, казался излишне облегчённым: получить медаль без подвига не хотелось. Иные сомнения отсеяны благодаря найденным статьям:

o Сравнение сертификаций по Scrum: ICAgile, Scrum Alliance, Scrum.org

o Где и с какими усилиями получить сертификат Scrum master?

o Советы студентов по получению сертификации PSPO

o PSPO vs CSPO

o Как сдать экзамен PSM 1, PSPO 1?

Начал искать дистанционные курсы и нашёл на Udemy - молодой программист Valentin Despa разместил несколько: как для Professional Scrum Master, так и для Professional Scrum Product Owner. Забегая вперёд, курс PSPO-1 оказался достаточным и необходимым вложением денег, времени для прохождения экзамена.

Многие, услышав характеристику разработки в стиле «полный Agile», свяжут ситуацию с хаосом, безответственностью и неприкасаемым творчеством программистов. Честно признаюсь, что и у меня были сомнения: «Стоит ли тратить время на изучение сбора принципов, который стал нарицательным»?
После углубленного изучения Scrum, понял, что негативный опыт - это скорее не про "красивый Agile", а про некомпетентность в лучшем случае или про норму российской ментальности в худшем:

• Бездумное применение Agile там, где возможен классический подход. Часто слова в пользу прогрессивных подходов, отдающих бирюзой – это хайп современности, повышающий стоимость высшего звена управления и снимающий моральную ответственность с тех, кто деньги достаёт из чужого кошелька: «Лес рубят – щепки летят» или «Я художник – я так вижу!». Всякому инструменту своё место: как Product owner как-то попался на том, что product backlog кончался быстрее, чем пополнялся взвешенными требованиями. При том что команда сидела на зарплате, простой вёл к потерям акционерного капитала. Считал эту ситуацию своим просчётом – медленно работал. Героически компенсировал ночёвками на работе, подкидывая в топку разработки больше дров. Команда радостно отчитывалась о высокой производительности, однако при попытках релиза росла гора «костылей» и всеобщей неудовлетворённости проектом. Клиент сервиса отдалялся дальше и дальше: отсутствием стандартов качества инкремента и, как следствие, бесконечной перекройкой архитектуры IT решения, команда оправдывала раздутый размер, качественный и количественный состав. При разборе полётов сторона разработки ссылалась на отсутствие конкретики в требованиях на год вперёд развития сервиса. В наше время множество типовых элементов IT решений стало для конечного потребителя крайне желательными, их легко выявить: анализ конкурентов, Kano калькулятор, бизнес моделирование и пр. Но если знать, при каких отсутствующих удобствах клиент откажется от сервиса, зачем тут «полный Agile»? И зачем команда, которая не признаёт работу классического подхода? Тогда я был совсем «зелёным», а команда разработки – «продвинутой», ответов на вопросы не находилось.
• Вера в то, что все хотят стать «быстрее, выше, сильнее» или в коллективное сознательное.

Сотрудник, нанятый на проектную деятельность, скорее не заинтересован в её окончании. Далеко не всем нужна гонка, появление нового вызова. Преимущества и недостатки организационных структур описываются в самом начале PMBoK 6th Edition. Минус проектной, типа Scrum team - страх членов команды за будущее, ведь придётся иcкать другой проект или даже другую работу. По опыту, желание получить самосознательную команду наталкивалось на следующие вариации ситуаций:
o Нанимаем гуру: усложняет задачу, раздувает штат или не даёт нанять никого достойного, делает полную зависимость решений от своего непререкаемого опыта;
o Нанимаем «вчерашних» студентов или почти: самоконтроль не встроен опытом ошибок. В итоге от Agile поглаживаний переходим к жёстким срокам, микроменеджменту, перепроверке результатов и норме выработки;
o Ищем что-то среднее и упираемся в потолок знаний человека, отвечающего за персонал: найм, адаптация, развитие.

Видится, что решение задачи о воспитании самоорганизующихся команд лежит в плоскости human resources (talent matching), корпоративной культуры и осознаваемых индивидуумом мотивов, ценностей. При этом личные мотивы не только придётся выявить извне, но и подать человеку «как пальто» - а вот это уже искусство. Такие HR-BP редки и в богатых компаниях, которые могут себе позволить дорогие кадры. Может ли себе это позволить средний и малый бизнес, хватит ли у владельца качеств интеграции и построения системы одновременно?

PMBoK 6th edition содержит описание процесса о развитии персонала, но инструментов и взаимосвязей с иными блоками знаний в своде недостаточно, писал об этом в одной из статей. Много ли этому вопросу уделено внимания, к примеру, в том же Scrum guide? Об этом позднее.
Забегая вперёд, скажу, что при подготовке к PSPO-1, нашёл «три таблетки», применяя которые вроде как живущая без кнута команда преобразиться в осознанных личностей. Встретилось это решение в одном из симуляторов экзаменационных вопросов: дай людям самим оценить сроки работы, убери звания (титулы) и пусть всем будут просты для восприятия принципы работы.

• Agile дешевле не Agile (где должна быть запятая?). Понадобилась интеграция нетиповой 1С под управлением франчайзера с типовой 1С франчайзи, не адаптированной под вид деятельности компании. Пол года бумажек и мучительных потугов силами внештатных разработчиков, которые шли параллельными командами. Делали по waterfall, три месяца эксплуатации и система встала, не выдержав нагрузки данными и внешними обработками. Пришли к пониманию неизбежности людей в штате: год ожиданий с профессиональными само мотивируемыми специалистами достойной квалификации и зарплатами выше рынка. Никаких бумажек и «почти Kanban». Как итог – тотальная зависимость от команды разработки, которой терять работу не хочется. Пересчитали зарплату в деньги – лучше бы шли по waterfall и сторонней поддержке.

Много критики в отношении неповоротливости waterfall, часто слышно, что дух Agile скорее мёртв, чем жив. Видится важным стремиться к продуктивности в балансе инструментов, а не подгонять болезнь под лекарство.

Плотное 4-х месячное обучение на сертификацию Project management professional (PMI) дало позитивные плоды, в т.ч. благодаря Rita Mulcahy’s book. В этой книге удалось почерпнуть советы, которые во многом сформировали стратегию подготовки:

• Надо понимать, подо что имеет смысл применять инструменты, профессиональное владение которыми подтверждает сертификация.

  В отношении PMBoK и PMP перевод цитаты из книги PMP® Exam Prep System, Ninth Edition by Rita Mulcahy: «Экзамен тестирует руководителя проекта, который понимает ценность инструментов и методов управления проектами и знает, как адаптировать их к большому проекту. Таким образом, полезно предположить, если не указано иное, что руководитель проекта работает над большим проектом, в котором участвуют более 200 человек из многих стран, потребуется по крайней мере один год, чтобы завершить его, никогда не было сделано раньше в организации и имеет бюджет в размере 10 миллионов долларов или более.». Неизменный Agile манифест: «Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим.". Scrum guide: «Скрам применялся для разработки программного обеспечения, оборудования, встроенного программного обеспечения, автономных транспортных средств и микробиологических исследований. Скрам доказал свою особую эффективность в итеративной и инкрементальной передаче знаний. Он широко используется в работе над продуктами, услугами и в управлении организациями.»

  Даже если Agile – это больше про ИТ, как пишут авторы неменяющегося манифеста, то ничего не мешает применить элементы Scrum для иных задач.

• Надо чётко осознавать мотивацию. В Rita’s book перечню часто встречающихся ошибок организации проектной деятельности посвящено особое место. Потребность эти ошибки не совершать в будущем - стимул к профессиональному развитию (page.2 Rita Mulcahy’s book 9th edition):

  · Провал сроков и перерасход бюджета

  · Нереалистичное расписание

  · Чрезмерные изменения в содержание проекта или расписание

  · Коммуникационные проблемы и усиление конфликтности

  · Упущение времени ближе к концу проекта

  · Неудовлетворительное качество

  · Низкий моральный дух

  · Неуверенность членов команды в том, что нужно делать

  · Чрезмерные переделки и сверхурочные работы

  · Слишком много встреч по проектам

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

  Мне знакомы ситуации, описанные выше: PMP и Scrum сертификация поднимают требования к знаниям, ответы со временем приходят. Речь идёт не о бездумном применении написанного в книжках, а о взвешенном решении в нужном моменте.
  В проекте PMI Moscow «Ретроспектива сертификации», можно посмотреть мотивы на сертификацию PMP статус PMI. Нет разницы в сертифицирующем органе, мотивы актуальны и для Scrum. Из наиболее популярных выделяются следующие (см. жирный шрифт на картинке):

• Своевременность экзамена - решающее значение. Если обучение растянуть надолго, то велик шанс выгореть эмоционально. А если ещё дольше, то и актуальность знаний может вовсе пропасть, к примеру, в январе 2021 года поменяются экзаменационные билеты на статус PMP. На PMP у ушло чуть более 4 мес. плотного обучения, почти без выходных, на PSPO-1 - примерно пол месяца неторопливого обучения, но в соответствии с советами, изложенными в этой статье.
• Каждая ошибка – это повод для роста, поэтому при прорешивании вопросов для сдачи экзамена, надо вести дневник причин таковых. В книге Риты Мулкахи рекомендуется завести таблицу со столбцами: № вопроса по порядку, причина неправильного ответа, причина повторного неправильного ответа. При подготовке к PMP я ошибки разделял по областям знаний и группам процессов, при подготовке к PSPO-1 был применён тот же инструмент. Выводы получились интересные. Подробности в следующем разделе этой статьи.

Теперь немного сопоставления PSPO-1 и PMP:

1. Обучающий контент. На сдачу PMP потребовалось вычитать примерно 1500 страниц, просмотреть более 50 часов видео и прорешать не менее 2000 вопросов (из которых 1000 уникальных). На PSPO-1 уникальных вопросов насчитал порядка 300, прошёл по 3 раза каждый, страниц для изучения менее 100, видео для просмотра - 7,5 часов.
   Только продолжительная работа в иностранной компании, применяющей классический проектный подход спасает от необходимости изучения множества учебных материалов при подготовке к PMP. Обычно как минимум набор такой: Rita Mulcahy’s book, PMBoK как справочник, какой-то ресурс с вопросами, похожими на экзаменационные, краткосрочные курсы (но это уже опционально). В отношении Scrum.org (PSPO-1) достаточно было окончить курс Валентина, а остальное следовало из его рекомендаций: разобрать Scrum Guide по предложениям, ознакомиться с глоссарием, прорешать максимум вопросов на assessment, на сайте Михаила Лапшина, вопросы курса довести до отсутствия ошибок, а так же почитать Evidence Based Management и Scrum Nexus.
2. Сложность вопросов. PMP экзамен: вопросы либо ситуационные, либо с формулами, 4 варианта ответа – один верный. В отношении PSPO-1 встретилось не менее половины неситуационных, много тех, ответы на которые надо было знать заранее, исходя из принятой составителями Scrum трактовки. При сдаче экзамена на роль в Scrum не придётся знать ни одной формулы, единственное, пришлось уделить внимание примерам ключевых показателей ценности продукта в EVM. Scrum.org не ограничивает ответ 4-мя вариантами, до 8, возможен выбор множества без понимания сколько верных, а так же вопросы типа «правда / ложь».
   То, что объединяет вопросы на статус PMP и PSPO-1 это:
   o Кандидата пытаются запутать в ситуационных вопросах: у Риты этому посвящена отдельная глава, соответствующие рекомендации есть и в курсе Валентина;
   o Ровно как на статус PMP может встретиться что из Agile (некоторые кандидаты находят до 10% таких), так и сдавая на Product owner, увидел какое-то количество вопросов на знание роли Scrum master;
   o В экзаменационных вопросах PMP гарантированно встретятся те, которые не освещены в PMBoK. Ровно как и на PSPO-1 придётся готовиться не только по Scrum guide – см. перечень источников знаний выше. Забегая вперёд, PSPO-1 только через текстовые материалы не защитить, нужна рука, набитая на вопросах.
   
3. Процедура экзамена. 80 вопросов и 45 секунд в среднем на ответ на Scrum.org против 200 вопросов и 72 секунды PMI. Joseph Philips в своём курсе заявляет о динамической оценке результата PMP: тебе не показывают результат в процентах, невидимые баллы начисляются по сложности вопроса, которая динамична согласно общей статистике ответов в базе данных PMI. К примеру, если на вопрос все отвечают положительно, то он больше в выдаче скорее не появится, если вопрос сложный (многие дают неверный ответ) – начислят больше баллов. На сдачу PSPO-1 необходимо набрать 85% правильных ответов и выше: 1 ответ = 1 балл, соответственно ошибиться можно 12 раз. Пройдя прилежно курс Valentin Vespa, показалось, что не менее 30% экзаменационных вопросов уже где-то видел с незначительными модификациями. Процедуру оффлайн сдачи PMP люди сравнивают с досмотром в аэропорту Израиля – так работает независимый центр тестирования Person Vue. И это в дополнение к процессу подачи заявки на экзамен и её одобрения. Сейчас в связи с пандемией возможен онлайн экзамен на статус PMP, но, у меня он вызывает больше опасений, нежели личное присутствие в центре тестирования: на тебя смотрят на камеру и, если оператору что-то не понравится (посторонний звук, эффект чужого присутствия или связь «моргнёт»), тестирование может прерваться с печальным результатом и потерей порядка 200 у.е. на пересдачу. Экзамен PSPO-1 полностью повторяет assessment, в т.ч. интерфейс с задержкой на 2-3 секунды при перелистывании вопросов и отсутствии какого-либо внешнего контроля за тестируемым.
   Единственное, что объединяет PMP и PSPO-1 – это то, что рассчитывать только на русский язык не приходится: в PMI перевод терминов хромает, в Scrum.org рекомендуют использовать плагин Google, качество перевода которого печальное.
   

Дополнительные советы/выводы по процедуре обучения:

• Активное сопоставление изучаемого материала с реальностью необходимо:
  · Перепросмотр старых ошибок: в этой статье см. раздел «Нотки сомнений о пользе Agile», в части PMP писал отдельную статью)
  · Немедленное внедрение изученного. Параллельно этому курсу я учился на администрирование Jira на Coursera – давно хотел понять все возможности ПО: «баловался» с одним из волонтёрских проектов PMI Moscow
  · На особо сложные для запоминания аспекты Scrum рисовал понятные мне картинки и вешал их на доску рядом с кроватью. Важнее рисовать, а не подбирать - так запоминать эффективнее. Для выбора иконок помогла статья на Хабре, делюсь репозиторием с авторскими исходниками (заимствованы из The Noun Project) а так же самими картинками, может кому помогут:

• Количество найденных ошибок в ходе предварительного тестирования на PSPO-1 после изучения всех учебных материалов было сопоставимо с количеством, которое допустил при подготовке к PMP – примерно 4%. При подготовке к PMP пришлось проштудировать порядка 1500 страниц в двух книгах, то в Scrum guide и пр. сопутствующих текстовых материалах (см. выше по тексту) не наберётся и 100. Если учесть, что качество поглощения учебного контента только возросла после испытания PMI, то вывод такой: Scrum только через официальные текстовые материалы не передаётся. Поэтому, если Вы давно в теме и можете цитировать Agile манифест или Scrum guide, нацельтесь на сертификат – новое для самосовершенствования скорее всего найдётся. От необходимости поиска ментора спасли ошибки на эмуляторах реального тестирования и их подробный разбор.
• Сертификат PMP требует значительных усилий при подготовке на протяжении от 4-х до 6 мес. и более. Бывают, что кандидаты откладывают сдачу из-за пиковых нагрузок на работе. В отношении Scrum PSPO-1 вложил примерно по 1,5 часа в день. Поэтому если хотите, но не можете найти 1,5 часа в день, замерьте время в социальных сетях и перечитайте пункты выше о мотивации.
  

Как уже упомянул выше, решил подойти к обучению на PSPO-1 так же, как и к обучению на PMP. В частности, необходимо обнаруженные пробелы в знаниях в ходе тестирования аккуратно занести в какую-то систему координат. Чтобы не тратить время на «новый велосипед», начал использовал те же координаты, что и в PMBoK: по горизонтали группы процессов от инициации до закрытия, по вертикали – области знаний от интеграции до управления заинтересованными сторонами (stakeholders). Подробнее – см. другую статью, раздел «Натаскивание на вопросы».

Единственная модификация, к которой прибег – это ввёл две дополнительные категории обнаруженных ошибок: ответ не встречается в Scrum Guide (17 из 42) и требуется дополнительное изыскание (всего 1 отметка – в отношении EVM: метрики продукта).
Пользуясь таблицей, пришлось выполнить ещё одну работу – находить ответ на ошибку в Scrum guide и почти каждое предложение 20 страниц разбивать по процессам PMBoK. На фоне структурированных в PMBoK входов и выходов Scrum guide по структуре похож на интервью: «А теперь поговорим о событиях, а теперь об артефактах и т.д.». В рамках одного абзаца могут быть описаны как критерии качества работы, так порядок выполнения изменений, продолжительность мероприятий. В принципе, это не плохо, тоже есть своя логика:

Scrum guide в большей части разобран на процессы PMBoK 6th Edition. Если найду решение с возможностью опубликовать результаты исследования без нарушения авторских прав Scrum.org и будет внешний запрос – файлик выложу в свободный доступ.
Ниже некоторые выводы по итогам проведения работы по сопоставлению тезисов и процессов:

• Scrum часто ассоциируют со спасением от неповоротливости classic project management. В Интернете много статей в контексте Waterfall VS Agile. Споры часто заканчиваются на казуистике понятий, так и не добравшись до сути: фреймфорк, метод, процесс и т.п. Для меня Scrum framework вписался в процессы PMBoK: ничего нового не изобретено, только обнажились массово клонируемые недостатки classic project management - обратите внимание на рисунке выше в отношении обнаруженных пробелов знаний. Больше всего ошибок случилось в областях управления содержанием (см. артефакты Scrum), ресурсами (Scrum team: roles), управления качеством (Definition of Done – DoD и Definition of Ready - DoR) управления коммуникациями (Scrum events в частности). Случились эти ошибки от того, что выученные в PMBoK процессы обрели чёткие границы и другие названия. Уж лучше пусть с границами, чем вообще менеджеры не будут знать о существовании важных процессов при управлении проектами. К выводам, что в Scrum нет ничего нового и чаще это хайп на новизну, пришёл ни я один.

Если вдруг случится, что кто-то будет проявлять деструктивную критику, помните, что тем самым человек обнажает свою цель, которая лежит в плоскости его интересов – этим просто надо научиться пользоваться. Поэтому, если Вы ни к classic, ни к Agile - пусть критика станет поводом для роста.

• Scrum guide по большей части затрагивает группы процессов планирования, которые заключаются в описании ролей, планировании качества, стандартных мероприятиях в проекте (каждый спринт как отдельный проект: Planning, Daily Scrum, Sprint, Review, Retrospective), некоторые аспекты коммуникаций. Работу по соотнесению всего текста монумента фреймворка с PMBoK пока не закончил, но в качестве примера можно выделить в процессах контроля:

  o Управление изменениями. 4.6 Perform integrated change control

  - Требования в рамках Product baklog никогда не останавливают своё изменение

  - Никаких изменений, которые могут быть ущемить достижение цели Спринта

  - Руководитель продукта может пойти на компромисс в части состава Спринта

  o Контроль расписания. 6.6 Control schedule

  · Дневной Скрам проводится в целях контроля продвижения к цели Спринта

  · Скрам мастер убеждается в том, что Sprint review состоялось

  o Контроль качества. 8.3 Control quality

  · Никаких компромиссов по качеству

Стоит отметить, что процессам контроля в Scrum guide уделено в разы меньше внимания, чем процессам планирования. Всё базируется на самостоятельных и мотивированных членов Scrum team и если в жизни это не так, то проект приходит в «абсолютный Agile» в негативном смысле этого выражения.
Вопреки «Agile = Welcome changes», Scrum guide не полностью открыт изменениям, в частности в Sprint backlog изменения возможны только по согласованию с командой разработчиков, и, если изменения не пойдут в ущерб цели спринта. Такого нет в PMBoK и, видимо, это то, что придаёт больше комфорта для сотрудников в гибкой среде. Scrum, как мне кажется, своим существованием снизил вероятность совершения частых ошибок Waterfall, задав рамки процессам:

В помощь для чтения условной схемы:

· PO – Project owner, DT – Development Team, DTm – DT member

· Issue log используется для фиксации запросов на изменения

· Процессы Collect requirements и Create WBS в своём результате чем-то схожи с описанием User stories

· Треугольник Cone of uncertainty не просто так разделён на две части - начинается за пределами Product backlog и заканчивается за пределами Sprint backlog: в Scrum важнее не соответствие позиции Product backlog требованиям DoR, а коллаборация, в ходе которой команда начнёт понимать, что от неё хотят. Точность в определении срока, цены на уровне задачи члену команды мало кому интересна – управление негативным риском в этой части снижено до размера минимальной ошибки (длина спринта) и принято всеми, управление позитивным риском в Scrum находится в зоне ответственности Product owner, он ведь value maximizer.

· Project scope statement – это по сути то, чего ждут от хорошего Product owner.

• Разделение классического Project manager. Разработчики Scrum theory на опыте убедились, что удовлетворить заинтересованные лица, одновременно проконтролировав членов команды практически невозможно - общение занимает до 90% времени Project manager. Так родилась обособленная роль Product owner, которой собой представляет единственный центр ответственности за успех продукта от лица всех заинтересованных лиц. Лидер проекта оформился стилем servant leader и стал играющим тренером. А команда разработчиков (Development team) наконец-то приняла на себя ответственность, которая ранее лежала на том, кто указывал что делать. Ну или так задумывалось.
• Странные понятия. Достаточно странным показалось, что product vision не регламентировано в Scrum guide, при этом подразумевается. В PMBoK Руководитель проекта обязан соотнести проект со стратегическим горизонтом (см. треугольник талантов Project manager), этот аспект встречается в экзаменационных вопросах. В Scrum guide члены команды не являются заинтересованными лицами, в отличие от PMBoK. Видимо, у теоретиков Scrum есть нерушимая вера в эффективность правил работы в гибкой среде, поэтому рассматривать проектных коллег как заинтересованных лиц не стоит (см. PMBoK – Team charter, 9.1 Plan resource management).
  
• Идеология. Показалось полезным выделение 5 ценностей Scrum: к примеру, мужество признать, что какая-то функция не интересна потребителю, тем самым притормозить излишнее украшательство. А также сделать фокус на том, что приносит ценность продукту для конечного клиента. Как лозунг – это замечательно, но на практике неудовлетворённый заказчик может «голосовать ногами».
  
• Scrum неоднозначен, показалось, не несёт в своих постулатах дух гибкости. Он пропагандирует адаптивность, при этом можно найти множество аргументов несоответствия этому. Больше всего показалось несоответствующими гибкости необходимость учить положения (определения) Scrum и их характеристики, такие как: обязательная последовательность событий и их формат, временные рамки событий, чем Scrum master помогает Product owner и пр. Возникают вопросы: «А как же люди, которые важнее процессов»? или «Зачем быть гибким, если экзамен учит делать Scrum?». Для меня надежда на разумность, сопряжённая с коммерческой выгодой сертифицирующего органа блещет в анонсе PMBoK 7th Edition, который основан на принципах и PMI Disciplined Agile.
  

Не смотря на то, что Scrum guide во многом дублирует PMBoK, в процессе обучения для себя отметил следующее:

1. В PMBoK пришлось ознакомиться со многими стилями лидерства, но то, что есть framework, который сосредоточен только на одном из них – это замечательно: servant leadership при столь многократном почитании обрастает множеством инструментов, которым нужно поучиться и тем, кто имеет сертификацию PMP.
2. Характеристики, которыми обрамлены Scrum events и Scrum artifacts с одной стороны ограничивают и могут быть применены с вредом для проекта и продукта, с другой требуют, чтобы на них обратили внимание и дают одно из решений. А применение правильного инструмента в правильном моменте – это одно из свойств работы профессионала.
   
3. Разделение классического Руководителя проектов на Product owner и Scrum master, что широко и эффективно применяется в мире, доказывает лишь наличие часто повторяемых ошибок в проектном управлении, когда роли размыты, ответственность не определена, коммуникации нарушены и всё это прикрыто переработками, документами и процессами, не приносящими реальную ценность.
   

Надеюсь, что статья для полезна и если Вы адепт Scrum, то увидите для себя что-то новое в classic project management и сертификации PMP (PMI). Если же Вы приверженец классического подхода по управлению проектами, то, надеюсь, что статья приведёт к тому, чтобы задуматься: «А все ли аспекты проектов, которыми Вы руководите выстроены идеально, можно ли что-то заимствовать из гибких методологий?»

И даже если «всё новое – это хорошо забытое старое», то «повторение – мать учения»! Хорошей всем учёбы и удачи на экзаменах!