PRINCE2 AgileTM

PRINCE2 Agile™ - это система управления проектами основанная на применении методологии PRINCE2. Не смотря на мнение что методология PRINCE2 использует классический метод или водопадный подход (что не совсем так), мы можем использовать принципы Agile которые достаточно хорошо объединяются с основной теорией. Напротив. Добавление принципов agility в проекты PRINCE2, может расширить сферу применения PRINCE2 и увеличить успешность проекта что как следствие увеличит процент доставки до потребителя, прямо с момента внедрения технологии PRINCE2 AgileTM в вашем проекте.

Главным автором PRINCE2 AgileTM является Кейт Ричардс и владельцем лицензии является AXELOS (который так же владеет и PRINCE2). PRINCE2 AgileTM была разработана используя лучшие практики в управлении проектами PRINCE2, также были использованы различные фреймворки, такие как Kanban и Scrum.

Что же осталось и что изменилось

Чтобы рассматривать проект в PRINCE2, необходимо описание базовых принципов; эта концепция перекочевала и в PRINCE2 AgileTM. Для использования других принципов Agile в PRINCE2, PRINCE2 вводит пять моделей поведения, типичных для всех проектов Agile. И вот они:

1. Transparency – Прозрачность – основной элемент этого принципа которые являются частью общих ценностей Agile таких как честность, доверие, целостность и уважение. Прозрачность не является просто гласностью, понимаемой как помещение информации на общую доску прогресса (Kanban Board), а в том чтобы раскрываться и делиться информацией со всеми, как в случае хорошей перспективы, так и плохой. 
2. Collaboration – Сотрудничество – это не просто совместная работа. Вдохновленные, самомотивированные команды, работающие как одно целое. Сотрудничество - это совместное решение любых проблем и принятие общего подхода к поиску оптимального решения. И сотрудничество означает не только внутреннее для команды. Оно также является внешним, главным образом с заинтересованными сторонами, пользователями и представителями бизнеса, чтобы каждый отвечал за успех проекта.
3. Rich communication – Широкая коммуникация - это гораздо больше, чем просто отправка отчетов менеджеру следующего уровня. Широкая коммуникация – это больше об общении лицом к лицу (если команды не локализованы в одном месте допустимо использование технических средств, например, видеокамер и т.п.). Общеизвестно, что более 70% общения невербальное, поэтому преимущество общения лицом к лицу - в быстром и ясном понимании, моментальном решении проблем и т.д. Самыми сильными инструментами и методами широкой коммуникации являются ежедневные встречи с докладами, планирование, обзор и ретроспективные встречи.
4. Self-organization – Самоорганизация - означает доверять команде в организации работы в которой они более компетентны. Если вы должны запланировать что-то – пригласите команду. Чем четче они будут осознавать, что ихний план, тем четче они будут следовать ему. Самоорганизация создает общее взаимоуважение. Поэтому менеджер проекта должен назначить менеджера команды, чтобы иметь возможность сосредоточиться на конечном продукте, и он сделает это лучше если будет доверять своей команде.
5. Exploration – Исследование - это изучение и обратная связь. Для того чтобы делать правильные вещи, необходимо понимать, что такое правильно. Обучение помогает улучшить ваш продукт. Обычно используя эксперименты, прототипы и ошибки, которые помогают понять пользовательские ожидания, вы можете получить быструю обратную связь чтобы уменьшить количество ошибок. Чем быстрее ваша связь с командой – тем быстрее вы сможете достигнуть необходимого прогресса. Чем быстрее команда будет находить “известные неизвестные” и раскрывать “ неизвестные неизвестные”, тем быстрее будет найдено правильное решение.

5 привычек (принципов) которые используются в проектах PRINCE2 Agile

 

5 behaviours (principles) in PRINCE2 Agile projects

Фиксация и гибкость в проектах PRINCE2 Agile

Типичная особенность Agile-проектов заключается в том, что заказчик быстро получает выгоду от проекта, но, вероятно, не получит все, что захочет. Поэтому PRINCE2 AgileTM вводит концепцию фиксации и гибкости.

 

Что же такое фиксация и сгибание?

Time - FIX

Время - фиксируем

Недопустимо использование дополнительного времени для реализации проекта. С учетом этого фактора (проект должен быть завершен ранее) поскольку мы переносим компоненты «следует» и «может» на остаток времени.

Cost - FIX

Цена - фиксирована

Цена – фиксирована - Проект не может стоить больше чем оговоренный бюджет.  Опять же, если большинство компонентов поставляются с более низкой стоимостью, то дополнительный бюджет может быть использован для компонент «следует» и «может».

 

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

Quality FIX and FLEX-Качество: Фиксация и Гибкость

Уровень качества защищен, но ясно, что не все критерии качества (продукты) и критерии приемлемости (проектный продукт) имеют одинаковое значение для клиента, поэтому они могут быть приоритетными. Необходимо зафиксировать существенные ожидания качества клиента, но допускать гибкость для критериев приемлемости.

Scope – FIX and FLEX - Область применения: Фиксация и Гибкость

Фиксация и Гибкость. Не все в проекте представляет равный интерес для заказчика. Существует нулевое отклонение от основного продукта - фиксация, но другие продукты которые имеют не основной приоритет могут не включаться в поставку.

Risk - FIX or FLEX

Риски - Фиксация или Гибкость

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

Benefit - FIX or FLEX - Преимущества - Фиксация или Гибкость

Фиксация или Гибкость отсчитывается от нулевого уровня, на котором проект может считаться полностью “минимально работоспособным” как бизнес кейс. Гибкость может быть интегрирована в проект в зоне выше “минимальной работоспособности” чтобы добавить ему дополнительные преимущества.

 

Fix and Flex principle in PRINCE2 Agile projects. Time and cost is FIX.

Концепция Фиксации и Гибкости в PRINCE2 Agile

Существует 5 целей для дальнейшего объяснения концепции фиксации и гибкости.

 

Цель

Пояснение

1

Be on time and hit deadlines - Доставка вовремя и в срок

Своевременная доставка и фиксация кратчайших сроков имеет много существенных преимуществ

2

Protect the level of quality-Защита уровня качества

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

3

Embrace change-Охватите изменения

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

4

Keep team stable and not add people to a team to try to go faster-Используйте целостную команду и не добавляйте новых людей для прибавления скорости работы. 

Сохранение стабильной команды в краткосрочной перспективе устраняет желание нанять новых людей в команду, чтобы ускорить работу. На самом деле это, скорее всего, будет иметь ничтожный эффект или вообще окажется не эффективным.

5

Accept that the customer does not need everything-Признайте что заказчику не нужно все

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

 

Agilometer and Cynefin-Агилометры и «Цинефин»

Прежде чем руководитель проекта начнет проект, он должен понять, насколько сложна среда и какие риски существуют при реализации Agile-подхода.

Cynefin - «Цинефин»

Структура Цинефин была создана Дэвидом Сноуденом для измерения уровня сложности проекта. Это система принятия решений, которая была разработана, чтобы помочь понять и определить, какой уровень сложности существует в любой конкретной ситуации или среде.

Она определяет пять зависимостей:   

Obvious – Очевидное - там, где отношения очевидны и обычно используется «лучшая практика».

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

Complex – Комплексный подход – там, где связи могут быть поняты только в ретроспективе и обращены к «новой практике», которая может стимулировать переход на новые методы работы.

Chaotic – Хаотический – где нет никаких видимых закономерностей или метода работы, разрабатывается новый метод.

Disorder – Беспорядок – с неизвестными отношениями.

Cynefin (Kinevin) framework to verify the environment in PRINCE2 Agile projects

Agilometer - Агилометр

Задача Agilometer - оценить различные области риска проекта с наилучшей точностью при применении Agile-управления проектами. Каждый аспект рассмотрения проекта отличается в той или иной форме благодаря таким факторам, как уровень доверия между клиентом и поставщиком, используемая технология или уровень неопределенности.

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

Чтобы наилучшим образом приспособить PRINCE2®, важно оценить, в каком контексте существует проект в отношении окружающей среды и рабочих отношений. Для достижения этой цели в PRINCE2 AgileTM есть инструмент оценки под названием Agilometer, который позволяет ответить на вопрос «Насколько применим Agile в этом проекте»?

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

 

Agilometer in PRINCE2 Agile projects

  1. 1.     Flexibility of what is delivered - Гибкость поставляемого продукта

    Клиенты понимают, что не все перечисленное вначале проекта будет готово, что могут появиться изменения, и эти изменения должны быть включены в проект. Клиент знаком с методами приоритизации (например, MoSCoW) и готов активно участвовать в определении приоритетов продуктов (пользовательская концепция).

    2.     Level of collaboration - Уровень сотрудничества

    Команда «настроена»; Приносила отличные результаты в прошлом; Нет «неразрешенных» конфликтов; Члены команды принимают положительную критику и соглашаются с тем, что они допускают ошибки; Люди работают быстро, эффективно и помогают друг другу; И они используются для работы в партнерской среде между клиентом и поставщиком.

    3.     Ease of communication - Простота коммуникации

    Коммуникации происходят в простой и неформальной обстановке между всеми участниками процесса; Люди привыкли к личному общению; И вовлекаются в работу с прототипами и моделями. Существует высокий уровень видимости прогресса; Планы и результаты (в основном, с помощью доски прогресса, журнала проблем и рисков); Люди располагают или, по крайней мере, имеют высокий уровень технологии визуальной коммуникации. Формальная связь и отчетность ограничены.

    4.     Ability to work iteratively and deliver incrementally - Возможность поэтапной работы и доставки результатов

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

    5.     Advantageous environmental conditions - Благоприятные условия рабочей среды

    Общая рабочая среда очень сопутствует в работе с помощью Agile-концепции. Над проектом работают штатные сотрудники; У них есть соответствующие навыки; и команда стабильная и опытная. Любые внешние участники комфортно работают в гибком режиме, при использовании инструментов Agile коммерческая и договорная среда гибко объединяются  для эффективной работы.

    6.     Acceptance of Agile - Применение Agile

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

Процессы в PRINCE2 Agile

Поскольку мы работаем с гибкостью, нет необходимости в очень большом предварительном планировании. Кроме того, проектная документация не требует подробного описания. По-видимому, полезно приспособить эту работу и собрать процессы запуска и инициализации (этот метод объединения очевидно применялся еще в проектах PRINCE2®, например для мелких или обязательных проектов, где решение по поводу продолжения проекта на данном этапе бесполезни с точки зрения пустой траты времени, так как проект однозначно должен быть продолжен).

Процессы PRINCE2 Agile не требуют глобальных корректировок.

PRINCE2 Agile processes do not need very much changed.

 

Как показано выше, использование концепции гибкости лучше всего отражается на уровне доставки продукта, меньше на уровне управления проектом и, вероятно, меньше всего на уровне управления. Это не означает, что группы разработчиков обязаны использовать Agile, а верхушка проекта работает со стандартным PRINCE2®. Это означает, что у менеджеров проектов и членов Совета проектов нет необходимости иметь такие глубокие знания Agile, и им не нужно принимать все решения исключительно на основе Agile, хотя низкая гибкость может вызвать большие риски в реализации проекта.

Основные отличия относительно стандарта PRINCE2® будут в процессе управления доставкой конечного продукта. Основная разница заключается в понимании нового подхода относительно использования времени и того факта что команды должны быть укомплектованы таким образом, чтобы одна или несколько команд могли обеспечить комфортную совместную работу. Они будут принимать рабочие пакеты в начале каждого этапа таким образом разделяя работу на короткие спринты. Результатом каждого спринта может быть продукт или его часть которая имеет ценность для клиента. Такой результат можно назвать «релизом», но стоит понимать что не всякий спринт будет давать нам новый релиз.

Managing product delivery process in PRINCE2 Agile projects

Рабочий пакет затем разбивается на спринты. В Scrum длина спринта фиксирована. В Kanban это «поток», который фиксирован. Когда команда отправляет все, что определено в рабочем пакете, они могут принять другой рабочий пакет.

Организация // Структура

PRINCE2® определяет восемь ролей команды управления проектами, четыре из которых не являются обязательными. В проектах на базе Agile эти роли также используются, но также имеются и дополнительные роли, которых нет в PRINCE2®.

Наиболее значительным изменением является внедрение команд по разработке проектов в рамках проекта и, возможно, других основных ролей Scrum, Product Owner и Scrum Master. Перечисленные выше роли работают над управлением процессом доставки продукта, который является «наиболее гибким» процессом в PRINCE2®, в то время как другие обязательные роли должны быть менее «гибкими».

Управляющий совет проекта

Как я уже описывал в предыдущих главах и как указано в PRINCE2 AgileTM, Цели (с учетом того что заказчик не нуждается во всех из них), участники управляющего совета проекта в особенности управляющие пользователи должны понимать:

  • Концепцию фиксирования и гибкости

  • Смысл концепции приоритетизации и как она используется в проекте

  • Должен признать, что первоначальное описание проекта (или видение продукта) будет в некоторой степени неопределенным

  • Эти несогласованные продукты должны быть изменены без их разрешения

  • Так что если команда не доставила все оговоренное – это не будет провалом

  • Пользователь обязан регулярно взаимодействовать с разработчиками

  • Проектная документация будет менее строгой

  • Стоит также учитывать что большинство отчетов и сообщений будут предоставляться в устной или визуальной форме

Менеджер проекта

Концепция с использованием менеджеров проекта не предпочитаема в Agile-подходе так как большинство стандартов не признают его. Команда Agile предпочитает наставлять и тренировать, а не быть направляемой внешним менеджером. Тем не менее, в PRINCE2 AgileTM эта роль является обязательной, но должна обладать определенным уровнем гибкого поведения, в основном является дополнительной / наставнической. Прежде всего, руководитель проекта должен признать, что команды разработчиков и члены команды составляют значительную часть проекта и что они самонаправлены и мотивированы. Он может все же разрешить работу в концепции рабочих пакетов, но их содержание должно обсуждаться и согласовываться с командой.

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

Менеджер команды

Поскольку эта роль не является обязательной в PRINCE2® то соответственно не является обязательной и в PRINCE2 AgileTM, но причины отсутствия этой роли могут быть совершенно другие. В небольшом проекте PRINCE2® менеджер проекта управляет командой, поэтому нет никакой необходимости в посреднике. В PRINCE2 AgileTM это также может иметь место, но также и потому, что команды самоорганизованы и самомотивированы.

Руководитель проекта и команда проекта

В общем случае, существует три варианта того, как менеджер проекта может работать с командой разработчиков:

  • Оставить роли в команде такими какие они есть. То есть у команды нету явного лидера и руководитель проекта вполне способен общаться с более чем одним участником рабочей группы. В таком случае вся команда несет ответственность за проделанную работу.

  • Один человек из команды отвечает за связь с Менеджером проекта. Это может быть кто-нибудь из команды разработчиков или даже мастер Scrum.

  • Ответственность за связь с Менеджером проекта несет руководитель Team Manager. Лучшей практикой является подход, при котором менеджер команды активно участвует в процессе и облегчает самоорганизацию команды. В этом случае Team Manager отвечает за результат команды, но не обязательно работает в команде разработчиков или создает продукт.

Мастер Scrum

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

Собственник продукта Product Owner

Эта роль характеризуется как голос потребителя. Это означает, что он представляет интерес клиента в команде. Одним из узких мест признанных в  концепции PRINCE2 AgileTM в том что один человек – это достаточно мало для учета всех потребностей потребителя. Там PRINCE2 AgileTM заявляет о более широком представлении клиента в группах разработчиков. Его главная обязанность заключается в том, чтобы определить приоритетность отставания продукта, определить критерии принятия и выполнения и принять истории пользователей в конце процесса. AgileTM не принципиален к тому, как должна выглядеть команда проекта. Существует только одно требование о том, что руководитель проекта должен быть определен исходя из концепции PRINCE2®, а самопровозглашенная и самомотивированная команда(ы) должны строиться по принципу PRINCE2 AgileTM.

Роль руководителя команды может принимать независимое лицо или команда, а роль Scrum Master не обязательно должна исполняться независимым лицом, это может быть например менеджер проекта или менеджер команды. Роль Владельца Продукта может быть выполнена путем презентации клиента в команде службой обеспечения качества или какой-либо другой заинтересованной стороной.