Гибридное управление проектами: обзор руководства PM2 – Agile

Самая суть

Руководство PM²-Agile расширяет классическое проектное управление темой гибкости (agile). У Еврокомиссии есть свой Центр передового опыта в области проектного управления, сокращенно — CoEPM². Они разработали традиционный набор из 3 стандартов управления проектами, программами и портфелями, а затем выпустили дополнение PM²-Agile.

В издании PM²-Agile предложена модель для построения гибридного подхода, т.е. подхода, включающего использование как классических, так и гибких методов. Для сравнения, в американском руководстве PMI PMBOK Guide 7 есть все те же самые элементы, но представлены немного в другой группировке.

Блоки модели описаны с разной степенью детализации. Какие-то весьма обзорные – например, техники и инструменты описаны простым перечислением. А какие-то вещи описаны очень детально – например, церемонии. Эта неоднородность создает ощущение несбалансированности руководства. Трудно дать оценку — это прикладная вещь или теоретическая?

Предложен способ гибридизации по уровням управления — классический подход «сверху», а гибкий «снизу», если пользоваться классификацией Павла Алферова. По такому же пути пошли разработчики Prince 2 Agile, Парацельс ПиЭм и ряд других.

Образ мышления PM²-Agile

Разработчики немного переформулировали 12 принципов из agile-манифеста. Смысл корректировок в расширении сферы действия agile на другие сферы:

• Не только разработка ПО. Авторы используют термин «решение» (solution) вместо «программное обеспечение» (software)
• Ориентация взаимодействия не только на клиентов (customers), но и на все множество заинтересованных сторон (stakeholders). Такой целостный взгляд характерен для классического проектного управления. Меня всегда коробило от идеи, что на клиенте «свет клином сошелся».
• Контекст всего проекта. Рассматривается подход к организации проекта как цельного мероприятия, вместо описания работы команды разработки, как это сделано в Scrum.
• Интеграция с подходом Lean. Эта же идея встречается в фреймворках масштабирования, например, в SAFe. Ценности Lean и Agile очень близки.

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

Дополнительно предполагается, что участники проекта будут разделять и ряд общих принципов из классического проектного подхода. Авторы указали их слишком много, что мне показалось перебором. Даже 12 принципов из PMI PMBOK Guide 7 мне кажется избыточным, учитывая, что они добавляются к 12 принципам аджайл манифеста.

Кто участвует в проекте и чем занимается

Ролевая модель полностью идентична модели из классического руководства этих же авторов за одним исключением. Появляется agile-команда на нижнем уровне, на уровне производства продукта.

К сожалению, ролевые модели в разных стандартах сильно различаются – что в классическом, что в гибком подходе. Сравните, к примеру, с ролевой моделью из британского Prince2 – сразу ясно, что ничего не ясно 😊. Я сравниваю с ролевой моделью Prince2, т.к. ролевая модель у американцев в PMBOK описана еще хуже, на мой взгляд.

Дам несколько комментариев по обозначенным в PM² ролям, чтобы как-то сориентировать в этом многообразии:

• Выделены традиционные уровни управления, которые совпадают с таковыми и в Prince2
• На высшем уровне (governing) работает орган управления, который отвечает за достижение стратегических целей. Чаще всего это коллегиальный орган, например, проектный комитет. На этом уровне проект рассматривается в контексте других альтернатив, фокус внимания направлен на выбор лучшей альтернативы из возможных.
• Следующий уровень – руководство (directing) проектом. Здесь внимание направлено на достижение успеха проекта, на достижение поставленных бизнес-целей. Каждая такая достигнутая бизнес-цель вносит свой вклад в достижение более крупных стратегических целей, в которых заинтересован вышестоящий уровень. В логике PM²-Agile в проекте есть две стороны – заказчика и исполнителя. И от каждой стороны должен быть представитель, кто будет работать на этом уровне – Владелец проекта (сторона заказчика проекта) и Поставщик решения (сторона исполнителя). Обратите внимание, что в Prince2 выделена еще одна сторона – представитель от бизнеса (Executive). Логика в выделении конкретных ролей на этом уровне такая – кто значительно может повлиять на успех всей инициативы и заинтересован в таком влиянии, тот и должен иметь право голоса.
• Уровень управления (managing) проектом. Здесь внимание направлено на создание и запуск в использование продуктов проекта. Это работа руководителя проекта, но кроме него на этом уровне могут «обитать» и другие представители. Например, в PM²-Agile здесь выделена роль Бизнес-менеджера, своего рода «Руководитель проекта от бизнеса». Но роль «Руководителя проекта» здесь не совсем обычная. Agile-культура подразумевает децентрализованное принятие решений и коллаборацию, поэтому от проектного менеджера ожидается больший уровень делегирования полномочий, в частности – координатору agile-команды и несколько большей командной игры.
• Уровень производства (performing или delivery). Здесь идет работа по непосредственному созданию продуктов проекта. Делают эту работу команда проекта, в том числе agile-команды и представители пользователей. Состав agile-команды почти полностью повторяет Скрам-команду. Исключение – явно выделена роль архитектора, что напоминает SAFe. Другой нюанс – роль координатора команды в отличие от «чистого» скрам-мастера, нагружена задачами тим-лида, т.е. он выступает как подотчетное лицо перед проектным менеджером.
• Орган координации (steering). Строго говоря, это не отдельный уровень, а механизм координации усилий разных ролей и разных уровней. Ключевые роли исполняют люди, а люди могут пренебрегать интересами одних лиц в пользу других. Чтобы решения по проекту были хорошо продуманны и сбалансированы, создают координационный комитет, который в PM²-Agile включает уровни руководства и управления, а также ключевых представителей тех заинтересованных сторон, чей голос должен быть услышан

Как разбить проект на этапы

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

Такой же способ сочетания можно встретить в Prince2 Agile, Парацэльм ПМ Андрея Малахова и ряде других. Можно сказать, что итерации как бы маскируются от внешних наблюдателей, которые могут и не знать, что разработка ведется по agile-практикам. Сама agile-разработка в руководстве PM²-Agile, несмотря на использование других терминов и мелких отличий, это обычный Scrum.

Какие создавать документы

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

Артефакты стратегического уровня:

• Бизнес-кейс – классический стратегический документ, обосновывающий существование проекта
• Устав проекта – высокоуровневое описание проекта с целями, результатами, контрольными точками и ключевыми ролями
• Архитектурная концепция – технический документ с высокоуровневым описанием архитектуры решения и его интеграции в общий технологический ландшафт
• Операционная модель – технический документ с описанием среды эксплуатации решения и способов поставки обновлений

Артефакты аджайл-уровня:

• План управления разработкой – аналог классического плана управления проектом только в отношении процесса производства продукта. Документ описывает выбранные технологии, например, среды разработки, использование TDD, CI/CD, способы контроля качества и т.п.
• План разработки – перечень задач, который управляется в аджайл-стиле. Включает продуктовый бэклог и бэклог итерации, план тестирования (аналог классической ПМИ), внедрения и план релиза. Как и в классическом проектном управлении, в аджайл тоже есть задачи и сроки, только имеют другую форму.

Координационные артефакты

• Статус-отчет разработки – сведения о статусе работы аджайл-команды. Содержит обычные аджайл-метрики и визуальные элементы: скорость команды, диаграммы сгорания итерации и релиза. Выступает как составная часть отчета о статусе проекта
• Журналы проекта – как и в классическом проекте, аджайл-команда должна отслеживать риски и проблемы, изменения, поручения
• Отчет о прогрессе проекта – общий отчет о здоровье проекта для заинтересованных сторон. Как правило, более высокоуровневый, нежели отчет о статусе проекта, но охватывает все аспекты проекта, включая актуализацию документов проекта, ключевые достижения, изменения в перечне участников и т.п.

Какие темы важны для рассмотрения

Традиционное разделение проекта на различные «проекции», которые в разных стандартах могут называться областями знаний, доменами, темами или аспектами. Но логика именно этого стандарта мне совсем не понравилась. Проекций получилось слишком много. В одном руководстве объединили и вопросы управления, и вопросы технического производства. Мне кажется более наглядным их разделение.

Lean UX. В рамках этой темы команда фокусируется на быстрой разработке прототипов и непрерывном обучении через эксперименты. Инструментально – это территория дизайн-мышления, который отлично сочетается как с гибким, так и классическим подходом к управлению.

Планирование. Эта тема полностью идентична домену «Планирование» в PMI PMBOK Guide 7. Здесь ничего отличительного я не увидел. Фокус внимания на планировании как полезном действии, нежели плане, как артефакте, который быстро устаревает.

Координация и отчетность. Точка зрения измерений, отчетности и коммуникаций. Тоже достаточно типовая тема (сравните «Управление коммуникациями» в прежних версиях PMBOK). Смысл такого ракурса простой – добиться согласованности в выполнении и поддержании адекватных ожиданий. Каких-то фишек не обнаружил, все типично для этой темы.

Требования. Управление требованиями выделено в отдельную тему, что в целом разумно, т.к. в этой области много нюансов – их лучше рассматривать отдельно. Предусмотрено, что требования могут быть организованы в виде продуктового бэклога и иметь изменчивую природу. В PMBOK 6 и 7 соответственно управление требованиями было «вшито» в область «Управление содержанием» или в домен «Поставка».

Оценка и приоритезация. Обычно в других стандартах этот аспект проекта не выделяется как отдельная «проекция», но в этом руководстве пошли на такой шаг. В основном, это реверанс в сторону agile-практик по оценке и приоритезации. Техника относительной оценки и планирования посредством оценки скорости (velocity) действительно требует детального рассмотрения.

Риски. Традиционный разрез про неопределенность. На мой взгляд разработчики руководства смотрят через розовые очки на способность agile-практик снижать риски. Тот факт, что команда МОЖЕТ рассматривать риски при планировании итерации, ежедневных стендапах, обзорах и ретроспективах вовсе не означает, что они это будут делать. И даже если будут, то почти наверняка только в отношении продуктовых и технологических рисков. Но я сильно сомневаюсь, что они будут рассматривать внешние риски или риски самой организации, если не поставить специальный процесс для этого. В общем, признавая способность agile-практик эффективно снижать продуктовые и технологические риски, я бы не отбрасывал классический процесс управления рисками.

Качество. Традиционный срез проекта, полностью идентичный тому, как это описывалось всегда в PMBOK. Акцент на качество процесса и качество продукта. Ключевые факторы успеха в достижении качество – сотрудничество, частная обратная связь.

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

Архитектура. Срез архитектуры решения. Основная мысль из аджайл – непрерывное уточнение архитектуры, что логично связано с выбранным подходом к разработке (см. тему «эволюция и развитие»).

Комплаенс и безопасность. Любопытный срез проекта, который обычно не выделяется как отдельная тема. Например, в PMBOK 6 это относится к факторам среды, которые нужно учитывать при выполнении проекта. Факторы среды – входные параметры многих управленческих процессов PMBOK 6. Название темы говорит само за себя – нужно в рамках проекта учитывать требования существующих политик.

Разработка. Еще один технический, а не управленческий срез проекта. Из всего множества технических практик взяли только три: непрерывная сборка, test driven development, эволюционная разработка. Их ведь намного больше! Да и первые две далеко не всегда применяются. В общем, странное решение о выделении такой «проекции».

Управление конфигурацией программного продукта. Еще один технический срез. Причем, авторы сами себе противоречат. Они обозначили область применения стандарта как универсальную (т.е. не только ИТ), а целую тему проекта выделили под исключительно узкий ИТ-вопрос. Есть же обычное конфигурационное управление в проектах. Не так уж важно, строите вы дом или создаете программку – у вас в любом случае множество артефактов, между которыми нужно поддерживать целостность.

Тестирование. Опять чисто технический срез проекта, который по сути своей дублирует управленческий срез «Качество». Причем, опять же, разработчики на время забыли, что хотели сделать руководство универсальным – описывается исключительно практика тестирования ПО.

Внедрение. Важный срез проект, считаю хорошей идеей выделить и рассмотреть его отдельно. Но, по существу, в руководстве PM²-Agile ничего не описано. Сказано лишь, что все важные аспекты нужно описать в артефакте «Операционная модель». А дальше идет отсылка на основной классический стандарт PM².

Какие нужны встречи

В аджайл-практиках принято основные встречи вшивать в состав практики. Их могут называть церемониями, каденциями или просто встречами. В руководстве PM²-Agile выделяют несколько ключевых церемоний, собранные в 2 группы – координационные и для получения обратной связи. Новизны в них нет – это обычные мероприятия Скрама. Однако, формат описания заслуживает внимания – подробный, практичный, хорошо структурированный.

Планирование итерации. Назначение – поддерживать концентрацию команды разработки на цели итерации. По сути, мало отличается от скрамовского планирования спринта, но описано более подробно. Это немного выбивается из общего стиля руководства, которое, в целом, довольно абстрактно, но здесь довольно много конкретики. Например, описана техника голосования «5 пальцев».

Ежедневный стендап. Назначение – согласованность действий команды и ранняя диагностика проблем. Я не нашел существенных отличий от стандартного Daily Scrum. Как и планирование итерации, эта церемония описана довольно подробно, что придает практичности этому стандарту.

Планирование релиза. Назначение – поддерживать согласованность продуктового бэклога со стратегией организации, с изменениями окружения и потребностей. Аналог мероприятия «Обзор бэклога» в Скраме. Опять же описано достаточно подробно. Хорошо проработан вопрос с техническими элементами бэклога, чего явно не хватало в Скраме. И есть выделенная роль – Архитектор, кто отслеживает эти элементы и способен объяснить Владельцу продукта их важность. Также мне понравилось наименование церемонии – оно имеет целевую направленность, а не просто «пересмотр бэклога» как в Скраме.

Обзор итерации. Назначение – получить обратную связь, понять, попали ли в ожидания созданной функциональностью. Аналог «обзора спринта» в Скраме. Описано подробно, практично.

Ретро. Назначение – выработать меры по улучшению процесса. Описана классическая ретроспектива, как в Скраме. 

Инструменты и техники

Инструменты и техники описаны обзорно в виде простого перечисления. По сути, это ссылки для дальнейшего их изучения. Но в такой форме подачи ничего не понятно – к чему они относятся, для кого они важны, на каких этапах, как они связаны друг с другом. В этом плане в PMI PMBOK Guide 7 применимость различных методов достаточно удобно проиллюстрирована в табличных формах:

В рассматриваемом руководстве описаны следующие приемы:

• Оценка командной работы по модели Патрика Ленсиони. Это отсылка к известной книжке «Пять пороков команды»
• Самоорганизованные команды. В аджайл-практиках минимальная организационная единица – это команда, которая сама организуют свою работу без выделенного менеджера. При этом вполне допускается наличие коуча или координатора команды, который будет помогать процессу самоорганизации
• Дизайн-блоки. Сессии работы на принципах дизайн-мышления. Команда встречается с заинтересованными сторонами, разрабатывает прототипы и получает обратную связь. Отлично, что здесь происходит объединение дизайн-мышления и производства, т.к. если смотреть на мир только глазами Скрама, то может показаться, что любую гипотезу нужно проверять только через продуктовый инкремент. Хотя во многих случаях быстрее и дешевле это сделать на прототипах.
• Фичи и истории. Основная функциональность решения описывается набором фичей, которые потом декомпозируются на истории. Это обычная для аджайл практика.
• Декомпозиция историй. Крупные истории могут не вмещаться в одну итерацию. Кроме того, чем меньше по размеру история, тем проще ее оценить и реализовать. Обычная практика – декомпозировать крупные истории на более мелкие.
• Критерии готовности (DoD). Соглашение команды разработки о том, что считать готовым рабочим элементом бэклога. Помогает лучше понимать задачу и удерживать качество на приемлемом уровне
• Покер планирования. Прием относительной оценки элементов бэклога, организованной в игровой форме покера. Хорошо описан во множестве источников, здесь его нет смысла подробно описывать
• Канбан-метод. Применение канбан-метода для оптимизации процесса разработки. Кратко описана идея вытягивающей система по сравнению с проталкивающей. Опять же, лучше читать первоисточники.
• Диаграммы сгорания. На практике применяют диаграммы для отслеживания итерации и для отслеживания релиза.
• Test-Driven Development. Инженерная практика в области разработки ПО (не применяется в других отраслях). Идея в том, чтобы писать сначала тесты, а потом программный код под тесты так, чтобы тест выполнялся. Как следствие, код будет хорошо покрыт тестами, а также высоки шансы, что в коде не будет ничего лишнего.
• Парное программирование. Инженерная практика из набора XP (экстремальное программирование). Суть в том, что в разработке принимают участие 2 разработчика – один пишет код, а другой выступает в роли «штурмана». Это позволяет уйти от монопольного знания кода только одним разработчиком, а также быстро находить ошибки. Правда, в руководстве авторы попытались предусмотреть более универсальное использование этой идеи, но я лично на практике такого не видел. Но в теории, можно применять и дизайне, и в тестировании.

Приложения

В приложениях из полезного перечислены:

• Материалы для чтения – известные хорошие книги
• Глоссарий терминов

Полезные ссылки

• Скачать руководство PM2-Agile