с 01.01.2018 по 01.01.2020
ФГАОУ ВО «Национальный исследовательский университет “Высшая школа экономики”»
УДК 65 Управление предприятиями. Организация производства, торговли и транспорта
BISAC BUS101000 Project Management
В последнее время в мире наблюдается бурный рост и развитие гибких методологий. Проблема выбора методологии осложняется тем, что каждая из них обладает своими достоинствами и недостатками. При этом исход проекта зависит не только от выбранной методологии, но и от того, что подразумевается под успехом проекта. Вместе с наличием исследований о влиянии гибких методологий на успех проекта, не существует достаточных научных исследований на тему влияния отдельных составляющих элементов — практик — гибких методологий на успех проекта. Целью данной работы является оценка влияния элементов гибких методологий на успех ИТ-проекта. Объектом исследования выступит гибкие методологии, применяемые для управления ИТ-проектами, предметом исследования — особенности применения гибких методологий в управлении ИТ-проектами. В работе показано, что две практики — Стэнд-ап и Канбан-доска — гарантированно вносят вклад в успех проекта при их правильном использовании. При этом другой значимой характеристикой успеха проекта является открытость руководства к использованию гибких методологий по управлению проектом.
менеджмент, эджайл, управление проектами, гибкие методологии, успех проекта, ИТ-проект
Введение
В настоящее время проектная деятельность в бизнесе расширяется как в количественном, так и в денежном объемах. Вместе с этим процент неуспешных проектов все еще остается высоким, что увеличивает риски экономической деятельности в целом (по данным отчета CHAOS Report, The Standish Group, 2015). Важной составляющей успеха является правильный выбор методологии управления проектом. Именно поэтому еще на этапе инициации необходимо обоснованно выбрать методологию и качественно запланировать методы управления и основные активности.
Гибкие методологии активно развиваются. Зарекомендовавшие себя в проектах по разработке программного обеспечения (далее – ПО), их начали использовать в других индустриях – финансовые сервисы, страхование, государственное управление, здравоохранение, тяжелая промышленность и т.д. (по данным отчета The 12th Annual State of Agile Report, VersionOne, 2018). Согласно отчету CHAOS Report (2015), проекты, на которых использовались гибкие методологии, стабильно реализуются успешнее тех, на которых используются традиционные.
Однако следует с осторожностью использовать гибкие методологии, поскольку и они обладают своими недостатками в сравнении с традиционным подходом. Вместе с наличием исследований о влиянии гибких методологий на успех проекта, не существует достаточных научных исследований на тему влияния отдельных составляющих элементов – практик - гибких методологий на успех проекта.
Целью данной работы является оценка влияния элементов гибких методологий на успех ИТ-проекта. Объектом исследования выступят гибкие методологии, применяемые для управления ИТ-проектами, предметом исследования - особенности применения гибких методологий в управлении ИТ-проектами.
Гипотеза данного исследования состоит в следующем: существуют сложившиеся комплексы избирательно вовлеченных элементов гибких методологий, применение которых положительно влияет на успех ИТ-проекта.
Согласно отчету VersionOne за 2018 год, наиболее используемыми гибкими подходами являются Scrum (54%), Гибридные методологии (14%), Scrum/XP Hybrid (10%), ScrumBan (8%), и др. Кроме Scrum, наибольше популярностью обладают гибридные методологии, что в очередной раз подтверждает актуальность исследования влияния не отдельной методологии на успех проекта, а элементов гибких методологий. Тот же список наиболее популярных методологий выявили в своем исследовании Валлон и др. (2018): Scrum - 60%, Kanban - 11%, XP & Scrum – 16%. Далее рассмотрим подробнее каждый из данных подходов и их специфические элементы.
Важно помнить о недостатках или ограничениях метода. Часть из них была описана в статьях Акифа и Маджид (2012) и Турка, Франса и Румпе (2002). Метод не работает эффективно в следующих случаях:
- Продукт тесно связан с legacy-системами или обязан пройти проверку Отдела технического контроля.
- Продукт обладает множеством внешних зависимостей.
- Участники команды обладают узко-специализированными навыками и умениями.
- Команда географически распределена по нескольким локациям.
Kanban
Kanban представляет собой другой метод по управлению проектами разработки. В этом методе фокус заключается в выполнении задач «точно в срок».
Такой эффект достигается за счет правильной приоритизации задач и определения продолжительности каждой задачи в общем потоке (Anderson, 2010). Методология позволяет, с одной стороны, уделить наибольшее внимание задачам с высокой вероятностью появления риска, с другой стороны, - оперативно управлять другими задачами проекта. В универсальном смысле подход Kanban фокусируется на том, чтобы выполнить нужную задачу в необходимый срок с учетом возможностей и квалификации сотрудников и доступности необходимых ресурсов. Проект начинается с разделения объема на так называемые компоненты – части фиксированного объема, сгруппированные по признаку бизнес-ценности (Anderson, 2010).
Авторы выделяют следующие причины возможного неуспешного использования подхода Kanban (Sipper, Bulfin, 2010):
- Нестабильный спрос. Поскольку сроки и объем задач в методе составляются на основе прогнозируемого спроса, при отсутствии корректной информации вся организация работы может оказаться неверной, что приведет к срыву сроков или невыполнения нужного объема.
- Нестабильность времени выполнения задачи.
- Не стандартизированные операции. Как и в описанном выше случае, не унифицированные операции препятствуют планированию сроков и объема выполнения той или иной задачи.
- Сложность обеспечения согласованности между разными этапами продукции/разными отделами. Система Kanban подразумевает возможность быстрой передачи материала между разными этапами жизненного цикла продукта. В случае, когда вся организация не живет по системе Kanban, проект будет испытывать сложности управления временем.
- Неопределенность поставки «вводных» материалов. При отсутствия стабильности подачи необходимых для выполнения проекта данных, материалов или ресурсов, выполнить работу с учетом прогнозируемого спроса не представляется возможным.
- Наличие жестких временных рамок. Несмотря на установку «выполнения работы в срок», подход Kanban не подразумевает наличие сроков для каждой задачи и строгого срока для конечного продукта, поскольку используется прогнозный спрос.
- Низкая коммуникация между участниками или неосведомленность о чужих функциях. Подход строится на том, что ответственные за определенный этап создания продукта эффективно коммуницируют между собой и в случае возникновения внеплановых ситуаций могут совместно принять меры по устранению проблемы.
Экстремальное программирование (Extreme Programming, XP)
В отличие от описанных выше методологий, данная методология предназначена только для проектов по разработке ПО. Целью ее применения является повышение производительности и качества разработки. Запросы на изменения считаются неотъемлемой частью проекта, поэтому система подразумевает итеративный подход.
Методология Экстремального программирования основана на пяти принципах: простота, готовность к критике, коммуникация, уважение и смелость. Правила Экстремального программирования состоят из 29 правил, разделенных на четыре пункта – планирование, управление, тестирование, проектирование и разработка кода. Необходимо отметить, что многие элементы методологии повторяют элементы подхода Scrum, однако процесс реализации проекта отличается.
Несмотря на доказанную эффективность, существует критика некоторых аспектов данного подхода. Существенная часть критики относится к Agile методам в целом, например, требование вовлеченности участников, высокий уровень квалификации каждого разработчика (Boehm, Turner, 2004). К уникальным ограничениям структуры XP можно отнести следующие (Stephens, Rosenberg, 2004):
- Подход ведет к «разрастанию» первоначального объема требований (scope creep), что приводит к невыполнению сроков и/или бюджета проекта.
- Требования к системе представлены в виде автоматических acceptance test (вид тестов для финального тестирования продукта перед запуском), а не в виде специфицированных согласованных документов.
- Разработчики строят свою работу таким образом, чтобы построить программный продукт, покрывающий максимально возможным функционал минимальными усилиями разработчика. При этом код усложнятся и дополняется только в случае не пройденных acceptance test. Этим система напоминает подход code-and-fix, который ведет к большим трудовым затратам, нежели только небольшое изменение функционала по запросу от заказчика после демонстрации, как в методологии Scrum. Иными словами, одна и та же область программного продукта может быть разработана несколько раз, что значительно дольше, чем следование заранее согласованному плану.
- Представитель заказчика может стать «узким горлышком» на проекте. С одной стороны, без должного обучения, он/она будет вынужден/а работать в незнакомой среде, состоящей из разработчиков, обладающих в основном техническими умениями. С другой стороны, есть риск микро-менеджмента команды разработки со стороны представителя бизнеса, при этом квалификации заказчика не будет хватать для эффективного распределения ресурсов и работы по разработке ПО. Более того, требование по постоянному вовлечению в проект конечного пользователя или представителя бизнеса существенно увеличивает издержки проекта.
XP Hybrid Scrum
Подход XP Hybrid Scrum сложно назвать полноценной методологией с учетом имеющейся литературы. В настоящее время система представляет собой набор практик, используемых изначально в методологиях Scrum и XP. Необходимо заметить, что подходы гармонично и эффективно дополняют друг друга, поскольку Scrum – подход к управлению проектом в целом, определяет рамки управления сроками, командой и работами, в то же время XP – система управления разработкой программного продукта.
Не существует согласованной формулы комбинации между практиками Scrum и XP. Один из подходов был предложен Муштаком (2012). Заключается он в том, что общие рамки проекта – церемонии, артефакты, роли – определяются методологией Scrum. В рамках спринта разработка осуществляется по правилам методологии XP: с использованием парного программирования, разработки через тестирование, высокой вовлеченности пользователя, рефакторинга и т.д.
Таблица 1
Список элементов наиболее популярных методологий
|
Методология |
Список элементов |
|
Scrum |
|
|
Scrum |
|
|
Kanban |
|
|
XP |
|
|
Окончание Таблицы 1 |
|
|
XP |
|
|
ScrumBan |
Сортировка оставшихся задач |
|
XP Hybrid Scrum |
Сочетание элементов Scrum и Kanban |
Источник: составлено автором.
Интенсивное развитие изучения того, что стоит включать в понятие успех проекта обусловлено тем, что тема несет не только академическое значение, но и практическую значимость. Чтобы измерить и сравнить эффективность использования той или иной методологии, необходимо определить показатели, по которым будет в итоге оценен вклад в успех проекта. Представляется очевидным, что для этого необходимо понять, что входит в понятие «успех».
Ниже представлено развитие понятия «успех проекта»:
Таблица 2
Критерии успеха проекта, анализ литературы
|
Критерий |
Источник |
|
«Железный треугольник» - срок, бюджет, объем |
Pankratz, Basten, 2014 Chow, Cao, 2008 Agarwal, Rathod, 2006 Kerzner, 2003 Atkinson, 1999 |
|
Удовлетворенность заказчика/пользователя |
Pankratz, Basten, 2014 Baccarini, 1999 Baccarini, Collins, 2004 Shenhar, Dvir, Levy, Maltz, 2001 |
|
Прямое влияние на успех организации |
Castro, Bahli, Farias Filho, 2019 Khan, Turner, Maqsood, 2013 |
|
Удовлетворенность подрядчика |
Pankratz, Basten, 2014 Dvir, Raz, Shenhar, 2003 |
|
Удовлетворение команды |
Martens, Carvalho, 2016 Mir, Pinnington, 2014 Jugdev, Müller, 2005 |
До сих пор авторы не пришли к единому мнению о том, что составляет исчерпывающий список факторов успеха проекта. Более того, большинство работ основаны на теоретических исследованиях, а не на эмпирических (Pankratz, Basten, 2014). Несмотря на то, что единого мнения нет, авторы согласились, что изучать и дополнять эти факторы критично. Определение критерия результата проекта как важного повышает вероятность, что к концу проекта этот критерий будет выполнен (Müller, Turner, 2007). В то же время формально определенный критерий успеха повышает эффективность распределения ресурсов и улучшает результат (Thomas, Fernández, 2008).
Общая модель определения успеха проекта должна предлагать менеджменту руководство по тому, на какие критерии необходимо обратить внимание, чтобы обеспечить успех проекта. Не обоснованно требовательная и обширная система критериев успеха проекта может привести к завышенным ожиданиям со стороны стейкхолдеров, ведущим к конфликту между заказчиком и менеджментом проекта (Hussein, Ahmad, Zidane, 2015).
Методология исследования
В качестве метода исследования были выбраны проведение анкетного опроса и построение регрессионной модели.
Из главных недостатков анкетного опроса можно выделить субъективизацию ответов и несамостоятельное заполнение анкеты. Чтобы нивелировать данные минусы, были предприняты следующие действия:
- Анкета предварительно была опробована как на представителях академической среды, так и практиках, формулировки были уточнены;
- Из-за узкой специфики опроса респонденты были выбраны лично, обязательным условием было наличие практики в области;
- Респондент мог в любой момент получить разъяснение по каждому из пунктов анкеты.
Анкетный опрос
В период октябрь – ноябрь 2019 года было проведен анкетный опрос на тему «Использование гибких методик в управлении ИТ-проектами». Анкета была посвящена поиску влияния отдельных элементов гибких методологий на успех проекта на практических примерах. Одна анкета покрывала один ИТ-проект и состояла из разделов:
- Сведения о респонденте;
- Сведения о компании, для которой осуществлялся проект;
- Сведения о проекте;
- Использование гибких методологий в управлении проектами;
- Успех проекта.
Для участия в анкетировании привлекались эксперты из различных компаний разных отраслей, но обязательно с практикой в ИТ-проектах и гибких методологиях. Вследствие узкой тематики исследования цель по сбору анкет составляла 25-30 штук. Консолидированная статистика по ответам представлена далее.
Количественные результаты анкетного опроса
Характеристика респондента, компании, проекта
По статистике наиболее частый ответ среди респондентов по опыту лет в управлении проектами (далее – УП) составил 2-5 лет (37% ответов), 5-7 лет (27%) и менее 2 лет (23%). Наиболее частая роль среди респондентов – менеджер проекта (50% ответов). Так, в среднем ответы будут представлять мнение руководства проекта со средним опытом работы на 2-4 проектах.
По статистике, описывающей компанию, для которой/в которой осуществлялся ИТ-проект, можно увидеть, что ответы в среднем будут характеризовать компанию
- Российского происхождения;
- Являющейся крупным предприятием;
- Возрастом более 10 лет.
Отрасль компании в большинстве случае представлена финансовым сектором (40% ответов) и ИТ- и телеком- компаниями (27%), что ожидаемо, т.к. ИТ-проекты с использованием гибких методологий начались именно в таких компаниях (Agile Alliance, 2010).
Чтобы оценить уровень открытости к использованию гибких методологий и наличие экспертов в области, что является одним из главных факторов успешного использования гибких методов и методик, респондентам предлагалось выбрать оценку, в большей степени выражающую согласие с приведенными утверждениями (1 – абсолютно не согласен, 2 – не согласен,
3 – затрудняюсь ответить, 4 – согласен, 5 – абсолютно согласен):
- Компания (в том числе руководство) открыто к использованию гибких методологий по УП;
- Компания имеет опыт в использовании гибких методологий, в штате есть эксперты в области гибких методологий.
Средний ответ составил 3,67 и 2,9 соответственно, что говорит о том, что в целом компании в виде руководства начинают осознавать и принимать эффективность новых методологий, в том числе гибких, но в то же время в компании не хватает экспертных знаний для правильного использования гибких методик.
Далее представлена статистика по описанию проекта, в котором использовались гибкие методологии.
Проекты выборки в большей степени характеризуются крупным бюджетом, более 15 млн. руб., небольшой командой в количестве менее 50 человек (44% ответов), что объясняется высокой квалификацией и востребованностью специалистов с одной стороны и спецификой использования гибких методологий, состоящей в организации небольших кросс-функциональных команд, - с другой стороны.
По статистике в 60% случаев команда проекта была распределенной. Чаще всего удаленно работают разработчики и технические специалисты. Современные способы связи позволяют поддерживать эффективную и постоянную коммуникацию и привлекать экспертов из разных регионов. Длительность проекта в 60% случаев составила 1 год, что характерно для ИТ-проекта средней сложности (Reddy, 2016).
Использование элементов гибких методологий
Респондентам предлагалось выбрать гибкие методики, которые были использованы на проекта.
Наиболее часто используемые методики - Бэклог, Стэнд-ап, Пользовательские истории, Спринт, Канбан-доска и Ретроспектива - будут использованы в дальнейшем для построения регрессионной модели.
Фокус-группе, состоящей из 7 экспертов в области УП предлагалось определить пары гибких методик, наиболее часто используемых вместе в УП. Далее респондентам предлагалось выбрать пары, которые были использованы на описываемом проекта. Наиболее часто используемые пары, а именно ТОП-4 из 12, пересекаются с наиболее популярными отдельно используемыми гибкими методиками.
Успех проекта
Один из разделов опроса состоял в оценке успеха проекта, в управлении которым использовались гибкие методики. Респондентам предлагалось сначала выбрать характеристики успеха проекта, входящие в официальные критерии успеха, а потом оценить все по 5-ти балльной шкале Лайкерта с обозначениями: 1 – абсолютно не согласен, 2 – не согласен, 3 – затрудняюсь ответить, 4 – согласен, 5 – абсолютно согласен. Наиболее популярными критериями оказались параметры «проектного треугольника» - срок, бюджет и объем/качество. При построении регрессионной модели каждому из критериев будут присвоены веса в соответствии с частотой их использования при официальной оценке успеха проекта.
В заключение хотелось бы обратить внимание на то, что целью данной работы не стояло доказательство использования гибких методологий в целом. Цель исследования - показать, существуют ли сложившиеся комплексы элементов гибких методологий, гарантированно влияющих на успех ИТ-проекта, и оценить их. В такую группу вошли Стэнд-ап и Канбан-доска. Данные элементы успешно могут быть применены на любом ИТ-проекте и при этом не требуют профессиональных глубоких знаний в области гибких методологий.
Кроме этого, был обнаружен другой значимый фактор, влияющий на успех проекта, а именно открытость компании (в т.ч. руководства) к использованию гибких методологий по УП. Данный результат подтверждает теоретическая основа гибких методологий: Agile – культура, прежде всего.
Таким образом, цели и задачи данного исследования были выполнены, было найдено и оценено в количественном виде влияние использование техник Стэнд-ап и Канбан-доска на консолидированный показатель успеха проекта.
В заключение хотелось бы отметить, что для успешной адаптации и составления своей методики, состоящей из разных гибких элементов, необходима накопленная экспертиза и соответствующий технический и социальный ландшафт и климат в компании.
Гибридные методологии
Далее будут описаны гибридные методологии ScrumBan и XP Hybrid, показавшие свою эффективность и используемые в той же мере, как и другие гибкие методологии.
ScrumBan
Подход ScrumBan представляет собой гибкую методологию управления проектами, основанную на подходах Scrum и Kanban. От «переходной» методологии ScrumBan был развит до полноценного подхода.
1. Agarwal, N., Rathod, U. Defining “success” for software projects: An exploratory revelation // International Journal of Project Management. 2006. Vol. 24 (4). P. 58-70.
2. Akif, R., Majeed, H. Issues and Challenges in Scrum Implementation // International Journal of Scientific & Engineering Research. 2012. Vol. 3 (8).
3. Anderson, D. Kanban-Successful Evolutionary Change for Your Technology Business - WA: David J. Anderson & Associates Inc, Seattle, 2010.
4. Atkinson, R. Project management Cost time and quality, two best guesses and a phenomenon, it’s time to accept other success criteria // International Journal of Project Management. 1999. Vol. 17 (6). P. 337-342.
5. Baccarini, D. The logical framework method for defining project success // Project Management Journal. 1999. Vol. 30 (4). P. 25-32.
6. Baccarini, D., Collins, A. The concept of project success - what 150 Australian project managers think // Australian Institute of Project Management (AIPM) Conference: Perth 2004, 10-12th October, 2004.
7. Boehm, B., Turner, R. Balancing Agility and Discipline: A Guide for the Perplexed // Boston, MA: Addison-Wesley, 2004.
8. Castro, M.S., Bahli, B.; Farias Filho, J. R. et al. A contemporary vision of project success criteria. [Электронный ресурс]: Brazilian Journal of Operations & Production Management. 2019. Vol. 16 (1). P. 66-77. URL: https://bjopm.emnuvens.com.br/bjopm/article/view/723 (дата обращения: 01.04.2019).
9. СHAOS Report. [Электронный ресурс]: The Standish Group International, Inc. 2015. URL: https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf (дата обращения: 01.04.2019).
10. Chow, T., Cao, D.B. A survey study of critical success factors in agile software projects // The Journal of Systems and Software. 2008. Vol. 81. P. 961-971.
11. Dvir, D., Raz, T., Shenhar, A. An empirical analysis of the relationship between project planning and project success. International Journal of Project Management. 2003. Vol. 21 (2). P. 89-95.
12. Hussein, B. A., Ahmad, S. B. S., Zidane, Y. J. T. Problems Associated with Defining Project Success // Procedia Computer Science. 2015. Vol. 64. P. 940-947.
13. Kerzner, H. Project Management: A Systems Approach To Planning, Scheduling, And Controlling [Электронный ресурс]: John Wiley & Sons, Inc., 2003 URL: https://books.mec.biz/tmp/books/55F1OL4WQC7HL2OBCGHS.pdf (дата обращения: 01.04.2019).
14. Khan, K., Turner, J. R., Maqsood, T. Factors that influence the success of public sector projects in Pakistan // In Proceedings of IRNOP 2013 Conference. 2013. P. 1-25.
15. Martens, M. L., Carvalho, M. M. Sustainability and Success Variables in the Project Management Context: An Expert Panel // Project Management Journal. 2016. Vol. 47 (6). P. 24-43.
16. Mir, F. A., Pinnington, A. H. Exploring the value of project management: Linking Project Management Performance and Project Success // International Journal of Project Management. 2014. Vol. 2 (2). P. 202-217.
17. Müller, R., Jugdev, K. Critical success factors in projects: Pinto, Slevin, and Prescott - the elucidation of project success // International Journal of Managing Projects in Business. 2012. Vol. 5 (4). P. 757-775.
18. Müller, R., Turner, R. The Influence of Project Managers on Project Success Criteria and Project Success by Project Type // European Management Journal. 2007. Vol. 25 (4). P. 298-309.
19. Mushtaq Z., Rizwan Jameel Qureshi Novel, M. Hybrid Model: Integrating Scrum and XP [Электронный ресурс]: International Journal of Information Technology and Computer Science. 2012. Vol. 6. P. 39-44. URL: http://www.mecs-press.org/ (дата обращения: 01.04.2019).
20. Pankratz, O., Basten, D. Ladder to success - eliciting project managers’ perceptions of IS project success criteria // International Journal of Information Systems and Project Management. 2014. Vol. 2 (2). P. 5-24.
21. Scrumtrek - кейсы выполнения проектов с использованием гибких методологий [Электронный ресурс]: ScrumTrek. URL: https://scrumtrek.ru/ (дата обращения: 01.04.2019).
22. Shenhar, A. J., Dvir, D., Levy, O., Maltz, A. C. Project success: A multidimensional strategic concept // Long Range Planning, 2001. Vol. 34 (6). P. 699-725.
23. Sipper, D., Bulfin, R.L. Variations of the kanban system: Literature review and classification // International Journal of Production Economics. 2010. Vol. 125(1). P. 13-21.
24. Stephens, M., Rosenberg, D. The irony of extreme programming. - MA: Dr Dobbs journal. Apress L.P. 2004.
25. The 13th Annual State of Agile Report. [Электронный ресурс]: CollabNet VersionOne. 2019. URL: https://explore.versionone.com/state-of-agile/13th-annual-state-of-agile-report (дата обращения: 01.04.2019).
26. Thomas, G. Fernández, W. Success in IT projects: A matter of definition? // International Journal of Project Management. 2008. Vol. 26 (7). P. 733-742.
27. Turk, D., France, R., Rumpe, B. Limitations of Agile Software Processes // Proceedings of the Third International Conference on Extreme Programming and Flexible Processes in Software Engineering. .2002.
28. Vallon, R., José da Silva Estácioc, B., Prikladnickic, R., Grechenigb, T. Systematic literature review on agile practices in global software development // Information and Software Technology. 2018. Vol. 96. P. 161-180.
29. Официальный сайт Atlassian [Электронный ресурс]: URL: https://www.atlassian.com/company (дата обращения: 10.05.2020).
30. Официальный сайт Collab.Net [Электронный ресурс]: URL: https://www.collab.net/ (дата обращения: 10.05.2020).
31. Официальный сайт Microsoft [Электронный ресурс]: URL: https://azure.microsoft.com/en-us/services/devops/server/ (дата обращения: 10.05.2020).
