ЗАМЕТКИ

PRINCE2 Agile

 

 Справочники  Теория

 0

ЧТО ТАКОЕ PRINCE2 AGILE?

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

PRINCE2 AGILE ПРЕДНАЗНАЧЕН ТОЛЬКО ДЛЯ ПРОЕКТОВ

PRINCE2 и PRINCE2 Agile подходят только для использования в проектах, в то время как Agile сам по себе можно использовать и для проектов, и для рутинной повседневной работы. Рутинная работа — «бизнес в обычном режиме» (business as usual — BAU) охватывает такие области, как непрерывная разработка продукта, его техническое обслуживание и постоянное совершенствование.

Различие между проектной работой и BAU (см. таблицу 1 и рисунок 1) это важно, поскольку некоторые из гибких методов работы необходимо применять по-разному в зависимости от ситуации, контекста задачи. Поэтому при выполнении какой-либо работы / задачи важно понимать тип выполняемой работы / задачи, чтобы удостовериться в том, что выполнение происходит надлежащим образом.

Характеристики проекта (Project characteristics) Характеристики BAU (BAU characteristics)
Временной (Temporary) Текущий (Ongoing)
Команда создана (Team is created) Сформировавшаяся команда (Stable team)
Трудный (Difficult) Рутина (Routine)
Определенная степень неопределенности (Degree of uncertainty) Определенная степень уверенности (Degree of certainty)

Таблица 1. Различные характеристики между проектом и BAU

Рисунок 1. Разница между проектной работой и BAU

На рисунке 1.1 показаны различные характеристики проектной работы (инвестиционная деятельность) по сравнению с работой BAU (операционная деятельность). В проекте определены этапы предварительной работы до начала любой деятельности по реализации. В нем также есть уровни управления проектом (Project management) и направления проекта (Project direction), чтобы в конечном итоге обеспечить получение правильного результата. К концу проекта, когда проектная команда распускается (или переходит к другой работе), созданный продукт будет введен в эксплуатацию, и с этого момента его можно будет поддерживать и совершенствовать в среде BAU. PRINCE2 Agile можно использовать только с левой стороны пунктирной линии (т.е. для проектов). Agile можно использовать с обеих сторон (т.е. для проектов и для BAU).

Что из себя представляет работа BAU?

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

Что из себя представляет проектная работа?

Проект — это временная работа, когда команда собирается для решения конкретной проблемы / задачи, которые являются настолько сложными, что не могут быть решены в рамках BAU. Это может быть даже набор элементов BAU, решаемых коллективно. Примером проекта может служить создание нового продукта или услуги – может возникнуть необходимость в привлечении многих заинтересованных сторон и существует значительная степень неопределенности. Проектная группа может находиться в разных местах, состав команды может меняться, проект может длиться долго и может быть частью более широкой программы (инвестиционной программы, портфеля проектов).

В среде BAU список работ в той или иной форме имеет приоритет и может быть распределен по временным блокам. По мере выполнения работ существующий продукт постоянно развивается.

Хотя PRINCE2 Agile подходит только для проектов, он использует широкий спектр гибких моделей поведения, концепций, фреймворков и методов, которые также используются в среде BAU.

ЧТО ТАКОЕ AGILE?

При объединении PRINCE2 с Agile важно знать, что такое Agile, в противном случае противоречивое представление об основах методологии затруднит их объединение. Базовое представление о том, как работает методология в целом (см. рисунок 2): использование распределенного по времени и итеративного подхода к разработке программного обеспечения; методы, такие как ежедневные встречи (daily stand-up meetings), спринты (sprints) и истории пользователей (product backlog); использование фреймворка Scrum (см. ниже методы Agile).

Рисунок 2. Базовая структура ‘бэклога’ и ‘спринта’ для доставки программного обеспечения (shippable product)

Базовая структура гибкой разработки программного обеспечения

Новые функции (features) для продукта хранятся в приоритетном списке, который называется product backlog. Список может состоять из историй пользователей (user stories), которые структурированы таким образом, чтобы описать, кому нужна эта функция и почему. Команда, которая будет разрабатывать функции, решает, какие элементы из списка невыполненных работ по продукту они могут создать за период, обычно составляющий от двух до четырех недель (который называется спринтом). Работа, которую, по мнению команды, она может выполнить в ходе спринта, хранится в списке, называемом «Список невыполненных работ спринта» (Sprint backlog). Каждый день на протяжении всего спринта проводится совещание для оценки прогресса. В конце спринта должны быть созданы новые функции, и они могут быть запущены в эксплуатацию. Результаты (т.е. новые функции) рассматриваются вместе с тем, как команда работала над достижением этих результатов.

Базовая структура гибкой разработки может существовать в рамках общего подхода Agile, который включает в себя видение (vision), дорожную карту продукта (product roadmap), которая представляет собой план того, как продукт будет развиваться и серию выпусков (releases), см. рисунок 3.

Рисунок 3. Спринты могут существовать в более широком контексте

Наиболее известные Agile методы (подходы)

Методы Описание
ASD (Adaptive Software Development) Итеративный процесс разработки. Подход подчёркивает адаптивность к изменяющимся требованиям и среде, фокусируется на непрерывном обучении. Для эффективной реализации методологии ASD используются специализированные инструменты и техники, которые помогают управлять проектами, сотрудничать и контролировать версии (JIRA, Trello, Slack).
Crystal Итеративный метод разработки. Это подход, при котором проект разбивается на небольшие, управляемые фрагменты (итерации) и работающее программное обеспечение поставляется через регулярные промежутки времени. Такой подход позволяет командам часто получать обратную связь от пользователей и заинтересованных сторон и адаптировать планы и приоритеты. Методология была представлена в середине 1990-х годов Алистером Кокберном и представляет собой семейство подходов, каждый из которых обозначен определённым цветом (например, Crystal Clear, Crystal Yellow, Crystal Orange). Акцент делается на работающий продукт и результат, документация используется только в той мере, в какой она необходима для успешной разработки.
DAD (Disciplined Agile Delivery) Гибридный подход к гибкой разработке IT-решений. Он ориентирован на обучение и в первую очередь учитывает человеческий фактор. Цель — полностью описать жизненный цикл разработки программного обеспечения, начиная с момента инициации проекта, заканчивая запуском продукта и его использованием конечными пользователями. Опирается на стратегии из различных областей: гибкого моделирования, экстремального программирования, канбана, бережливой разработки программного обеспечения и других. Позволяет командам адаптировать процессы в зависимости от сложности проекта. Интегрирует осведомлённость о предприятии, чтобы команды работали в рамках более широкой организационной структуры и соответствовали стратегическим целям. Жизненный цикл проекта в методологии DAD включает три основные фазы: 1) инициация — формирование команды, исследование области проекта, получение финансирования; 2) конструирование — команды работают над разработкой и тестированием решения; 3) переход — фокусируется на развёртывании и деятельности после доставки.
DevOps Подход к организации процессов разработки и эксплуатации программного обеспечения, направленный на сокращение времени между изменением кода и его внедрением в продуктивную среду. Название происходит от сочетания слов Development (разработка) и Operations (эксплуатация). Главная идея DevOps — объединение разработчиков, тестировщиков, системных администраторов и других участников команды в единое рабочее пространство. Это позволяет ускорить цикл поставки, повысить стабильность систем и быстрее реагировать на изменения в бизнес-требованиях.
DSDM (Dynamic Systems Development Method) / AgilePM Основная цель DSDM — сдать готовый проект вовремя и уложиться в бюджет, при этом регулируя изменения требований к проекту во время его разработки. AgilePM (Agile Project Management) — это методология управления проектами, основанная на DSDM. Она позволяет решать распространённые проблемы проектов, такие как поздняя доставка, перекос в стоимости или несоответствие конечного продукта целям.
FDD (feature-driven development) Итеративная методология разработки программного обеспечения, одна из гибких методологий (Agile). Основная идея — разбить проект на небольшие, управляемые части — «функциональные характеристики» (features) — и разрабатывать их последовательно.
Kanban Cистема управления проектами, основанная на принципе разделения объёма работы на конкретные задачи. Основная идея — визуализация этапов проекта на специальной доске. Каждая задача представлена карточкой, которая содержит название, приоритетность и сроки выполнения. Карточки перемещаются по доске от одного этапа к другому по мере выполнения задач.
Lean Это система управления, ориентированная на повышение эффективности процессов за счёт устранения потерь, вовлечения сотрудников и постоянного улучшения. Основная цель — создание максимальной ценности для клиента при минимальных затратах ресурсов.
Lean Startup Методология разработки новых продуктов, основанная на цикле Build-Measure-Learn («Создать-Измерить-Обучиться»). Суть — постоянное тестирование гипотез и итеративная разработка продукта на основе обратной связи от пользователей. В центре внимания — не продукт как таковой, а процесс его поиска: быстро, гибко и с оглядкой на клиента.
SAFe (Scaled Agile Framework) Фреймворк для масштабирования гибких подходов в крупных компаниях. Он объединяет практики из мира Agile, бережливого производства и системного мышления. Цель SAFe — координировать работу множества команд, обеспечивая согласованность между оперативными задачами и стратегическими целями компании. Фреймворк особенно полезен, когда над проектом трудятся от 50 человек и больше.SAFe включает четыре основных уровня: 1) Уровень команды (Team Level) — базовый уровень, где Agile-команды используют Scrum, Kanban или комбинированный подход для создания и поставки ценности; 2) Уровень программы (Program Level) — координирует работу нескольких команд через «Поезд Agile-релизов» (Agile Release Train, ART), синхронизируя их усилия для создания единого решения; 3) Уровень крупного решения (Large Solution Level) — обеспечивает координацию нескольких «Поездов Agile-релизов» при разработке сложных систем, требующих взаимодействия многих команд; 4) Уровень портфеля (Portfolio Level) — связывает операционную деятельность со стратегическими целями организации через управление портфелем ценностных потоков. Каждый уровень имеет свои специфические роли, церемонии и артефакты, но все они интегрированы в единую систему, обеспечивающую согласованную работу организации.
Scrum Методология гибкого управления проектами из семейства Agile. Изначально разрабатывалась для управления проектами в сфере IT, но сегодня её применяют и в других направлениях — от маркетинга и социальных медиа до издательского дела. Работа по Scrum строится на принципе спринтов — коротких циклов (итераций), в течение которых создаётся часть продукта. Обычно продолжительность одного спринта — от двух до трёх недель. По завершении каждого спринта команда демонстрирует промежуточный результат — рабочую версию продукта или новую его функцию, которую можно использовать, несмотря на то, что она ещё не окончательная. Результат каждой итерации обсуждают с заказчиком — если его всё устраивает, приступают к следующей. Обычно в начале проекта у команды нет представления о том, как будет выглядеть продукт в самом конце, — требования могут меняться в ходе разработки.
XP (eXtreme Programming) Методология разработки программного обеспечения, основанная на принципах гибкости, улучшения качества и ускоренного реагирования на изменения. Название «экстремальное» связано с тем, что уже существующие практики довели до предела. Название пошло из математики от слова «экстремум» — так обозначается максимальное или минимальное значение на графике функции. Цель методики XP — справиться с постоянно меняющимися требованиями к программному продукту и повысить качество разработки. XP хорошо подходит для сложных и неопределённых проектов. Некоторые особенности методологии: 1) Парное программирование. Подход, при котором два разработчика сидят за одним компьютером или созваниваются по видеосвязи. Один печатает код, второй следит за логикой и подсказывает; 2) Разработка через тестирование. Тесты разрабатываются до написания самого кода. Это способствует ясной формулировке требований и обеспечивает функционирование кода в соответствии с замыслом; 3) Свободный доступ к коду. Каждый участник команды имеет возможность просматривать и редактировать код. Это создаёт атмосферу совместной ответственности и способствует обмену информацией. Методология XP применима только в области разработки программного обеспечения и не может быть использована в другом бизнесе или повседневной жизни.

[RU] Комментирование закрыто. [EN] Comments are closed.