Сравнение процессов разработки программного обеспечения по методологиям PMBOK и Agile | Статья в журнале «Молодой ученый»

Отправьте статью сегодня! Журнал выйдет 30 ноября, печатный экземпляр отправим 4 декабря.

Опубликовать статью в журнале

Авторы: ,

Рубрика: Информационные технологии

Опубликовано в Молодой учёный №17 (203) апрель 2018 г.

Дата публикации: 25.04.2018

Статья просмотрена: 872 раза

Библиографическое описание:

Ревенко В. Г., Джабраилов Ш. В. Сравнение процессов разработки программного обеспечения по методологиям PMBOK и Agile // Молодой ученый. — 2018. — №17. — С. 33-37. — URL https://moluch.ru/archive/203/49684/ (дата обращения: 17.11.2019).



Цель данной статьи — сравнить общий набор процессов управления проектами, как это определено в своде знаний 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, знания по управлению проектами определены с точки зрения технологических групп и областей знаний. Это исследование сосредоточено на областях знаний, поскольку эти области предлагают более точное представление о том, что такое управление проектами, и в то же время они дают общую картину. К таким областям относятся:

  1. Управление интеграцией проектов описывает процессы и действия, которые объединяют различные аспекты управления проектами.
  2. Управление проектом включает в себя процессы, которые отвечают за управление областью проекта.
  3. Управление временем проекта описывает процессы, связанные со своевременным завершением проекта.
  4. Управление стоимостью проекта, включается в себя процессы, касающиеся стоимости.
  5. Управление качеством проекта описывает процессы, связанные с обеспечением того, чтобы проект удовлетворял целям, для которых он был выполнен.
  6. Управление человеческими ресурсами проекта включает в себя все необходимые процессы для организации и управления командой проекта.
  7. Управление коммуникацией проекта описывает процессы, связанные с механизмами связи проекта, сбору, распространению, хранению и утилизации информации о проекте.
  8. Управление рисками проекта описывает процессы, связанные с управлением рисками.
  9. Управление закупками включает все процессы, связанные с приобретением продуктов и услуг, необходимых для завершения проекта.

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 принесет пользу сообществу управления проектами в ИТ области.

Литература:

  1. В. Г. Ревенко, В. Л. Розалиев, Д. С. Степанищев «Автоматизация управление проектами по Scrum методологии» Международный научно-исследовательский журнал № 5–3(59) С. 98–102.
  2. K. Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley Professional.
  3. PMI Institute, A Guide to the Project Management Body of Knowledge, PMI Standard Committee.
  4. H. Takeuchi and I. Nonaka, The New New Product Development Game, Harvard Business Review
Основные термины (генерируются автоматически): PMBOK, FDD, программное обеспечение, проект, управление проектами, область знаний, процесс, UML, Управление качеством, Управление рисками.


Похожие статьи

Модель системы Управления Проектами | Статья в журнале...

проектный менеджмент, проект, Казахстан, управление проектами, PMBOK, IPMA, PMI, национальный стандарт, проектное управление, область управления. Обзор методов управления проектными рисками.

Программное обеспечение системы менеджмента качества

программное обеспечение, система менеджмента качества, софтвер.

Дефекты программного обеспечения системы управления...

Исследования в области обеспечения безопасности и качества выпускаемой продукции — признак развитой цивилизации.

Организация процедуры управления рисками процессов СМК

В статье рассмотрено понятие риска и процесс управления рисками в системе менеджмента качества, сравнительная таблица методов оценки рисков. Деятельность по управлению рисками помогает повысить результативность и эффективность процессов СМК, а...

Использование программных средств управления...

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

Разработка автоматизированной обучающей системы управления...

Свод знаний по управлению проектами PMBoK (Project Management Body of Knowledge) представляет собой сумму профессиональных знаний по управлению проектами.

Опыт внедрения системы управления проектами в российских...

2. Адаптация модели регламента управления проектами ктребования банка с учётом его особенностей функционирования и методологии управления проектами PMBoK

Разработка объектно-ориентированной модели процесса...

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

Управление рисками; – Обеспечение качества; – Выдача отчета о результатах

Управление IT-проектами | Статья в журнале «Молодой ученый»

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

С-480. Ройс У. Управление проектами по созданию программного обеспечения. М.: Лори, 2014.

Управление человеческими ресурсами IT-проектa

Управление командой проекта [2]. Рис. 1. Основные этапы процесса Управления человеческими

Стандарт ANSI PMI PMBOK, Глава 2. Управление человеческими ресурсами про-екта (Project

Ройс У. Управление проектами по созданию программного обеспечения.

Похожие статьи

Модель системы Управления Проектами | Статья в журнале...

проектный менеджмент, проект, Казахстан, управление проектами, PMBOK, IPMA, PMI, национальный стандарт, проектное управление, область управления. Обзор методов управления проектными рисками.

Программное обеспечение системы менеджмента качества

программное обеспечение, система менеджмента качества, софтвер.

Дефекты программного обеспечения системы управления...

Исследования в области обеспечения безопасности и качества выпускаемой продукции — признак развитой цивилизации.

Организация процедуры управления рисками процессов СМК

В статье рассмотрено понятие риска и процесс управления рисками в системе менеджмента качества, сравнительная таблица методов оценки рисков. Деятельность по управлению рисками помогает повысить результативность и эффективность процессов СМК, а...

Использование программных средств управления...

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

Разработка автоматизированной обучающей системы управления...

Свод знаний по управлению проектами PMBoK (Project Management Body of Knowledge) представляет собой сумму профессиональных знаний по управлению проектами.

Опыт внедрения системы управления проектами в российских...

2. Адаптация модели регламента управления проектами ктребования банка с учётом его особенностей функционирования и методологии управления проектами PMBoK

Разработка объектно-ориентированной модели процесса...

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

Управление рисками; – Обеспечение качества; – Выдача отчета о результатах

Управление IT-проектами | Статья в журнале «Молодой ученый»

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

С-480. Ройс У. Управление проектами по созданию программного обеспечения. М.: Лори, 2014.

Управление человеческими ресурсами IT-проектa

Управление командой проекта [2]. Рис. 1. Основные этапы процесса Управления человеческими

Стандарт ANSI PMI PMBOK, Глава 2. Управление человеческими ресурсами про-екта (Project

Ройс У. Управление проектами по созданию программного обеспечения.

Задать вопрос