Цель данной статьи — сравнить общий набор процессов управления проектами, как это определено в своде знаний Management Body of Knowledge (PMBOK) и в методологиях гибкой разработки Agile. PMBOK разработан и сконструирован вокруг пяти групп процессов управления (инициирование, планирование, выполнение, контроль и завершение) и девяти области знаний (управление, интеграция, управление знаниями, управление временем, управление качеством, затратами, персоналом, рисками, закупками). Методологии гибкой разработки и управления проектами основаны на следующих принципах: принимать изменения, сосредотачиваться на ценности клиента, предоставлять клиенту функционал после каждой итерации, обучение и самоорганизация команды.
Цель этого сравнения — выявить проблемы, различия, расхождения в этих методологиях. В результате гибкие методологии не могут быть рассмотрены в полной мере, с традиционной точки зрения управления проектами, так как ряд процессов отсутствует или не описан в явном виде.
Ключевые слова: управление проектами, риски проектов, методологии разработки PMBOK, методологии Agile, Scrum.
Введение
Традиционные методологии разработки программного обеспечения создавались из-за необходимости контролировать крупные проекты, а также трудности с оценкой и управлением. Эти трудности в сфере разработки программного обеспечения существует уже много лет и не все до конца исследованы. Кроме того, большинство специалистов в области информационных технологий находятся под большим давлениям в условиях быстро меняющего рынка ИТ-продуктов.
В результате большое число ИТ-проектов оканчиваются неудачей: примерно 95 % проектов имеют перерасход различных средств в среднем 60–160 %, а превышение сроков в среднем 30–200 %; более 30 % проектов прекращаются, не достигнув завершения. Использование методологий управления проектами позволяет более сбалансировано управлять жизнью ИТ-проекта, что существенно повышению шанс достижения ожидаемых результатов. [1]
Гибкие методологии пытаются преодолеть эти препятствия, изменив подход, используемый для разработки программного обеспечения и управления проектами. Кроме того, гибкая разработка позволяет пользователю продукта менять требования и выпускать части программного обеспечения с рабочим функционалом. Манифест для разработки Agile software был выпущен в феврале 2001 года и состоял из 17 программных процессов и методологии управления. С тех пор ряд методов разработки программного обеспечения стали использовать этот подход. Стали развиваться такие подходы: Extreme Programming (XP), Scrum, Feature-Driven Development (FDD), Adaptive Software Development (ASD) и другие.
Такие методы в основном создавались внутри корпораций экспертами по программным процессам в качестве попыток улучшить существующие процессы компании. Например, XP был создан Kent Beck во время работы над Chrysler Comprehensive проект расчета заработной платы и системы вознаграждений персонала. Результаты его работы были опубликованы в его книге «Extreme Programming Explained» [2].
С другой стороны, более традиционные методы управления проектами зависят от жизненного цикла разработки программного обеспечения: линейное развитие или водопад. Наряду с предсказуемостью они унаследовали детерминистский подход, основанный на разбивке задач. Свод знаний по управлению проектами (PMBOK) разработанный Институтом управления, является лучшим представителем этого подхода [3]. PMBOK формально состоит из 44 проектных процесса, описывающих деятельность на протяжении всего жизненного цикла проекта. Эти 44 процесса организованы в двух осях: пять групп процессов и девять областей знаний, которые будут кратко описаны далее.
Однако даже если гибкие методологии выглядят привлекательно и их использование дает многообещающие результаты есть и критика их применений. В следующем разделе будет представлены некоторые гибкие методы из PMBOK и тогда можно сравнить эти методологии между собой.
Институт управления проектами
Как уже упоминалось ранее в PMBOK, знания по управлению проектами определены с точки зрения технологических групп и областей знаний. Это исследование сосредоточено на областях знаний, поскольку эти области предлагают более точное представление о том, что такое управление проектами, и в то же время они дают общую картину. К таким областям относятся:
- Управление интеграцией проектов описывает процессы и действия, которые объединяют различные аспекты управления проектами.
- Управление проектом включает в себя процессы, которые отвечают за управление областью проекта.
- Управление временем проекта описывает процессы, связанные со своевременным завершением проекта.
- Управление стоимостью проекта, включается в себя процессы, касающиеся стоимости.
- Управление качеством проекта описывает процессы, связанные с обеспечением того, чтобы проект удовлетворял целям, для которых он был выполнен.
- Управление человеческими ресурсами проекта включает в себя все необходимые процессы для организации и управления командой проекта.
- Управление коммуникацией проекта описывает процессы, связанные с механизмами связи проекта, сбору, распространению, хранению и утилизации информации о проекте.
- Управление рисками проекта описывает процессы, связанные с управлением рисками.
- Управление закупками включает все процессы, связанные с приобретением продуктов и услуг, необходимых для завершения проекта.
Agile управление проектом
Целью манифеста Agile Software Development было «выявить лучшие способы разработки программного обеспечения, сделав это и помогать другим делать это». Принципы, на которых он основан, заключаются в следующем:
‒ Индивидуальное взаимодействие над процессами и инструментами.
‒ Рабочее программное обеспечение с полной документацией.
‒ Сотрудничество с клиентами и заключение контрактов.
‒ Реагирование на изменение в соответствии с планом.
Очевидно, манифест не является ориентированным на процессный подход. Как представлено во введении, существует много методов разработки программного обеспечения, которые можно назвать «гибкими». Однако в этой работе выбраны только некоторые из них в качестве наиболее представительных. Среди методов разработки были: Extreme Programming (XP), Scrum и Feature-Driven Development (FDD).
А. Extreme Programming
Экстремальное программирование или XP — это гибкий метод, который появился в проекте в Chrysler Corporation в конце 1990-х годов. Он был разработан Уордом Каннингемом, Кент Бек и Рон Джеффрис. Метод XP основан на четырех значениях:
‒ Связь, основанная на таких практиках, как модульное тестирование, парное программирование, оценка задачи.
‒ Простота, всегда стремиться к простейшему решению.
‒ Обратная связь. Иметь конкретные знание о текуoем состоянии системы.
‒ Уметь, признавать недостатки в системе и предпринимать корректирующие действия.
Б. Scrum
Scrum подход для разработки новых продуктов, который был впервые представлен Takeuchi и Nonaka [4] после наблюдения за небольшими высокопроизводительными командами в разных компаниях. Scrum — это гибкий процесс разработки программного обеспечения, в котором проекты продвигаются через серию месячных итераций, называемых спринт.
Кроме того, серия спринтов в среднем от 6 до 9 может производить выпуск работающего продукта.
В начале проекта его требования заносятся в специальный список известный как Product backlog. Затем, в начале каждого спринта происходит совещание по планированию спринта, в ходе которого владелец продукта определяет приоритетные задачи. В течение каждого дня спринта проводятся ежедневные встречи для обсуждения вопросов проекта. Такие ежедневные собрания помогают значительно развитию команды и коммуникации. В конце спринта команда представляет функциональный продукт на обзор.
В. Feature Driven Development (FDD)
Feature Driven Development (FDD) — это итеративный и инкрементный процесс разработки программного обеспечения. Методология FDD состоит из пяти этапов:
‒ Разработка общей модели.
‒ Создание списка функций.
‒ План по предметной области.
‒ Дизайн по набору функций.
‒ Создание по принципу.
На первом этапе разработки общей модели, выполняется сбор требований. Основная цель — собрать требования и разработать начальную диаграмму классов UML, которая описывает сущности проблемного домена. Вся работа разделена и распределена на небольшие команды, состоящие из разработчиков и пользователей. Эти команды отвечают за части всей модели и за представление своих моделей для рассмотрения и утверждения.
Второй этап FDD — это создание списка функций. Команда разработчиков определяет набор необходимых функций, разложив функциональные возможности системы на предметные области. Каждая предметная область состоит из бизнес-операций.
Третий этап — подготовить план развития проекта. Планирование по предметной области предлагает планирование путем группировки функций. Группировка выполняется в соответствии с функциональными возможностями. Другими факторами, которые необходимо учитывать, являются: загрузка команды разработчиков и сложность реализуемых функций.
Четвертым шагом является «Дизайн по набору функций». Цель этого шага — создать дизайн каждого набора функций. Модель проектирование включает в себя диаграммы последовательности UML.
Пятым шагом является «Создание по принципу» включает в себя выборку из набора функций, определенного на шаге 4 и разработки кода для этих функций и модульного тестирования.
Сравнение PMBOK и Agile методов
Чтобы сравнить представленные методы управления проектами, за основу были взяты процессы PMBOK поскольку они организованы для каждой области знаний. Причины, способствовавшие этому решению, были две:
‒ PMBOK является исчерпывающим перечнем передовой практики в форме процессов, которые могу быть адаптированы к конкретным потребностям
‒ PMBOK хорошо известен и официально документирован по сравнение с представленным в этой работе гибкими методами. Результат этого сравнения представлен в таблице 1.
Таблица 1
Сравнение методологий PMBOK иAgile
|
PMBOK |
Agile methods |
||
|
XP |
Scrum |
FDD |
|
|
Управление интеграцией проектов |
|||
|
Разработка устава проекта Разработка. предварительного отчета по проекту. Разработка плана управление проектами. Мониторинг и управление. Контроль изменений. Закрытие проекта. |
Интеграция программного обеспечения как можно скорее и чаще. Собственность коллективного кода. Измерение скорости проекта. |
Проверка утверждения и финансирование управления на этапе планирования. Сильная процедура управления изменениями. Архитектура системы для поддержки изменений |
Разработка общей модели системы |
|
Управление проектом |
|||
|
Планирование. Определение области. Создание структуры и разбивки работа (WBS). Контроль. |
Истории пользователей. Планирование выпуска. |
Выполнение анализа для построения моделей домена. Разработка по product backlog list. Определение функциональности, которая будет включена в каждую версию продукта |
Выполнение анализа для построения моделей домена. Сборка списка функций. |
|
Управление временем проекта |
|||
|
Последовательность действий. Оценка ресурсов. Продолжительность действий. Разработка расписания и контроль. |
Планирование выпуска. Планирование итераций. |
Определение даты поставки функциональности для каждой версии. Месячные итерации |
Определение последовательности разработки. Назначение классов для разработчиков. |
|
Управление стоимостью проекта |
|||
|
Оценка стоимости. Бюджетирование затрат. Проект контроля затрат. |
Не предусмотрено. |
Оценка стоимости выпуска на этапе планирования. |
Не предусмотрено. |
|
Управление качеством проекта |
|||
|
Планирование качества. Выполнение контроля качества. |
Использование стандартов проекта. Качество основывается на простоте. |
Совещание по рассмотрению проектов. Совещание по планирование спринта. Ежедневные совещания. |
Обзор встреч. Проверка кода и модульные тесты. |
|
Управление рисками |
|||
|
Планирование управления рисками. Идентификация рисков. Анализ качественного риска. Контроль рисков |
Создание прототипа для ограничения риска. |
Первоначальные риски во время планирования. Обзор рисков во время совещаний. |
Не используется |
Заключение
В таблице 1 показано, что гибкие методологии не определяют все аспекты, необходимые для управление проектами в традиционном понятии. Это было частично ожидаемо, поскольку традиционные процессы управления полностью определены в сравнении с гибкими методами, которые считаются «эмпирическими». Однако из этого может заключить следующее. Гибкие методологии делают акцент в следующих областях знаний:
‒ Управление областью действия, т. к. акцент делается на управлении требованиями.
‒ Управление персоналом, поскольку большое внимание уделяется командной работе.
‒ Управление качеством.
‒ Управление рисками не явное.
‒ Управление затратами не является частью гибких методологий.
Это означает, что использование гибких методологий вместе с PMBOK принесет пользу сообществу управления проектами в ИТ области.
Литература:
- В. Г. Ревенко, В. Л. Розалиев, Д. С. Степанищев «Автоматизация управление проектами по Scrum методологии» Международный научно-исследовательский журнал № 5–3(59) С. 98–102.
- K. Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley Professional.
- PMI Institute, A Guide to the Project Management Body of Knowledge, PMI Standard Committee.
- H. Takeuchi and I. Nonaka, The New New Product Development Game, Harvard Business Review
