СРАВНИТЕЛЬНЫЙ АНАЛИЗ МЕТОДОЛОГИЙ УПРАВЛЕНИЯ IT-ПРОЕКТАМИ МЕТОДОМ АНАЛИЗА ИЕРАРХИЙ - Студенческий научный форум

XIV Международная студенческая научная конференция Студенческий научный форум - 2022

СРАВНИТЕЛЬНЫЙ АНАЛИЗ МЕТОДОЛОГИЙ УПРАВЛЕНИЯ IT-ПРОЕКТАМИ МЕТОДОМ АНАЛИЗА ИЕРАРХИЙ

Чеботарев В.А. 1, Несвоева А.А. 1
1Белгородский государственный национальный исследовательский университет
 Комментарии
Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке "Файлы работы" в формате PDF

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

Waterfall, или каскадная модель, – традиционная методология, которая существует с 1970 года. В ней разработку проекта разбивают на этапы: от анализа системных требований до выпуска продукта.

Каждый шаг – отдельная фаза разработки ПО, и команда должна завершить одну фазу, прежде чем переходить к следующей. В «чистой» реализации Waterfall возвращаться на предыдущий этап запрещено – можно «плыть только по течению», чтобы пройти полный цикл разработки. Пользователи Quora сравнивают эту модель с поездом, который движется от станции к станции и не может повернуть назад.

Изначально автор Waterfall Винстон Ройс (Winston Royce) привел каскадную модель как пример неэффективного способа разработки программного обеспечения, который ведет к ошибкам и выпуску некачественных продуктов. Однако потом в своей статье он довел методологию «до ума», отметив обратные связи и переходы от тестирования к написанию кода и др. [1].

По данным исследования PMI, 12% компаний используют методологию Waterfall на постоянной основе, а 40% респондентов утверждают, что часто к ней обращаются. А по данным LiquidPlanner, каскадную модель используют 25% организаций [2].

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

При выборе этой системы организация быстрее работает, мобильнее, разделяет сотрудников на небольшие команды. Принципы Agile выражают так: разделение задач на небольшие блоки, автономность сотрудников, прозрачность работы, обработка обратной связи от клиентов [3].

Несмотря на то, что многие команды отдают предпочтение либо методологии водопада, либо agile-проектированию, преимущества обоих подходов привели к появлению гибридной методологии, когда этапы планирования и определения требований выполняются согласно методологии водопада, а этапы проектирования, разработки, внедрения и оценки соответствуют гибкому подходу. Данная методология является попыткой применения сильных сторон каждого из основных подходов, а также снижения негативного воздействия слабых сторон. Гибридная методология может хорошо вписаться в сферу информационных технологий за счет того, что на уровне руководства организации проект имеет четко поставленные цели, хорошо документированы, предоставляет возможность мониторинга статуса проекта для предоставления руководству. На этапе выполнения за счет высокого уровня коммуникации между представителями бизнеса и непосредственно исполнителями задачи по проекту глубоко детализированы, понятны разработчикам. Возможность учится «на лету», совершать ошибки и совершенствовать продукт под текущие требования бизнеса одинаково хорошо для разработчиков и бизнеса. Конечно, за все надо платить. Подход предъявляет требования к как к техническому уровню подготовки сотрудников, так и к его персональным качествам [4].

Понятие «scrum» («скрам») впервые появилось в середине 80-х годов ХХ века в работах японских ученых Икуджиро Нонаки и Хиротаки Такеучи, когда они говорили об успехе проектов, в разработке которых участвовали небольшие команды без жесткой специализации. Эти команды они сравнивали с конструкцией схватки (от англ. «scrum») в регби, назначающейся судьей при остановке игры или при нарушении правил [5].

Среди достоинств методологии Scrum выделяется, в первую очередь, ориентированность и адаптивность. Метод позволяет изменять требования к проекту в любое время (пусть и не дает гарантии того, что эти изменения будут реализованы). А такая возможность очень привлекает заказчиков [6].

Благодаря тому, что система работы построена по итерационному принципу (и у каждой итерации есть своя цель), с помощью Scrum-метода можно получать рабочие версии продукта по окончании каждого спринта [7].

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

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

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

Канбан – это система организации для управления задачами в бизнес-процессах. Инструмент позволяет оптимизировать работу команды через разделение объемных этапов на отдельные операции. Цель внедрения Канбан – контроль за рабочим процессом и отслеживание нагрузки специалистов.

С помощью системы Канбан можно гибко планировать задачи, контролировать сроки, повысить эффективность работы и видеть весь процесс наглядно. Метод применим в разных сферах: IT, маркетинге, строительстве. Главное, чтобы в бизнесе можно было выделить этапы и типы работ.

Использование Канбан возможно на разных типах производства. Ограничения накладывает не сфера производства или число специалистов в команде, а способность персонала брать на себя ответственность за организацию рабочего процесса [9].

Метод применяют многие IT-компании, например, Microsoft. Канбан внедряют на промышленных производствах, HR-сервисах, закупках [10].

Рассмотренные выше метрологии управления IT-проектами будут оцениваться по следующим критериям [11]:

бюджет проекта – возможность управления проектами с различными бюджетами (крупный, средний и/или мелкий);

сроки проекта – возможность управления проектами с неопределенными сроками;

сложность – возможность управления проектами с различной сложностью (легкий, средний и/или сложный);

риски – возможность управления проектами с различными рисками (неконтролируемые, частично контролируемые и/или контролируемые);

местоположение – возможность команде проекта работать удаленно;

документация – необходимость составления подробной документации;

внедряемый продукт – возможность управления проектами с различной степенью готовности (разработка с нуля и/или внедрение готового решения и/или доработка готового решения).

Для сравнительного анализа вышеописанных методологий управления IT-проектами был использован модифицированный метод анализа иерархий [12]. Иерархия выбора методологии, выполненная с использованием СППР «Решение» [13] представлена на рисунке 1.

Рисунок 1 – Иерархия выбора методологии управления IT-проектами

После выполнения декомпозиции проблемы через определение ее компонент и отношений между ними необходимо перейти к этапу сравнения отдельных компонент иерархии [14]. Сравнение критериев представлено на рисунке 2.

Рисунок 2 – Сравнение критериев

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

Отношение согласованности (ОС) равно 3,1%. Считается нормальным, если ОС < 10%. Таким образом, матрицу можно считать согласованной.

Затем необходимо составить матрицы парных сравнений альтернатив по всем критериям. Было составлено семь матриц парных сравнений альтернатив, результаты представлены в таблице 1.

Таблица 1 – Сравнение альтернатив

Методология

Документация

Местоположение

Внедряемый продукт

Бюджет проекта

Сложность

Риски

Сроки проекта

Waterfall

0,032

0,393

0,083

0,059

0,068

0,076

0,056

Agile

0,294

0,129

0,333

0,163

0,300

0,288

0,271

Scrum

0,294

0,043

0,333

0,163

0,300

0,076

0,146

Канбан

0,294

0,043

0,167

0,163

0,033

0,484

0,470

Гибридная

0,085

0,393

0,083

0,451

0,300

0,076

0,056

ОС

0,7%

1,6%

0

0,5%

0,5%

0,4%

1%

Оптимальные по каждому критерию варианты выделены зеленым цветом.

Проведя все сравнения для иерархии, можно перейти к результатам ранжирования методологий управления IT-проектами (рисунок 3).

Рисунок 3 – Приоритетность вариантов решения проблемы

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

СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ

1 Методология разработки Waterfall: что это, как работает и чем отличается от Agile [Электронный ресурс]. – URL: https://skillbox.ru/media/management/waterfall/ (дата обращения 18.12.2021).

2 Кратко о методологиях разработки ПО: Waterfall, Lean и Feature Driven Development [Электронный ресурс]. – URL: https://habr.com/ru/company/it-guild/blog/341932/ (дата обращения 18.12.2021).

3 Что такое Agile: методология, команда, оценка эффективности [Электронный ресурс]. – URL: https://skillbox.ru/media/management/chto_takoe_agile/ (дата обращения 18.12.2021).

4 Как и зачем используется гибридная методология разработки [Электронный ресурс]. – URL: https://www.azoft.ru/blog/hybrid-project-management/ (дата обращения 18.12.2021).

5 SCRUM – эффективный метод управления проектами [Электронный ресурс]. – URL: https://4brain.ru/blog/scrum/ (дата обращения 18.12.2021).

6 Scrum-методология: новый способ поднять эффективность команды [Электронный ресурс]. – URL: https://rdv-it.ru/company/press-center/blog/scrum-metodologiya/ (дата обращения 18.12.2021).

7 Scrum – что это такое, как это работает и в чем преимущества [Электронный ресурс]. – URL: https://skillbox.ru/media/management/chto_takoe_agile/ (дата обращения 18.12.2021).

8 Что такое scrum: преимущества и недостатки [Электронный ресурс]. – URL: https://sendpulse.com/ru/support/glossary/scrum (дата обращения 18.12.2021).

9 Методология Kanban: доски, принципы и возможности управления [Электронный ресурс]. – URL: https://skillbox.ru/media/management/vse_chto_nuzhno_znat_o_kanban/ (дата обращения 18.12.2021).

10 Что такое Канбан и как внедрить методологию в компании [Электронный ресурс]. – URL: https://blog.calltouch.ru/chto-takoe-kanban-i-kak-vnedrit-metodologiyu-v-kompanii/ (дата обращения 18.12.2021).

11 Торосян Елена Константиновна, Тюлькина Анастасия Сергеевна Критерии выбора методологии управления IT-проектами // Петербургский экономический журнал. 2020. №1. URL: https://cyberleninka.ru/article/n/kriterii-vybora-metodologii-upravleniya-it-proektami (дата обращения 18.12.2021).

12 Ломакин В.В., Лифиренко М.В. Алгоритм повышения степени согласованности матрицы парных сравнений при проведении экспертных опросов. [Текст] // Фундаментальные исследования. - 2013. - №11. - С. 1798-1803.

13 Ломакин В. В., Лифиренко М. В. Система поддержки принятия решений с автоматизированными средствами корректировки суждений экспертов // Экономика. Информатика. 2014. №1-1 (172). URL: https://cyberleninka.ru/article/n/sistema-podderzhki-prinyatiya-resheniy-s-avtomatizirovannymi-sredstvami-korrektirovki-suzhdeniy-ekspertov (дата обращения 18.12.2021).

14 Метод анализа иерархий: процедура применения [Электронный ресурс]. – URL: http://vamocenka.ru/metod-analiza-ierarxij-procedura-primeneniya/ (дата обращения 18.12.2021).

Просмотров работы: 65