Исследование влияния применения составляющих элементов гибких методологий на успех ИТ-проекта

Размещено на http://www.allbest.ru/

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ОБРАЗОВАНИЯ

«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Факультет бизнеса и менеджмента

Магистерская диссертация

Исследование влияния применения составляющих элементов гибких методологий на успех ит-проекта

Никулина Татьяна Юрьевна

Москва, 2020 г



Содержание

Введение

Глава 1. Анализ академической литературы на тему гибких методологий

1.1 Обоснование появления гибких методологий

1.2 Развитие понятия «успех проекта» до 2000-х

1.3 Влияние использования гибких методологий на успех проекта

Глава 2. Проведение анкетного опроса и построение регрессионной модели

2.1 Описание методологии исследования

2.2 Описание анкетного опроса

2.3 Построение регрессионной модели

Глава 3. Рекомендации и дальнейшее исследование

3.1 Практические рекомендации

3.2 Практическое применение практики Стэнд-ап

3.3 Дальнейшее исследование

Заключение

Библиография

Приложение



Введение

В настоящее время проектная деятельность в бизнесе расширяется как в количественном, так и в денежном объемах. Вместе с этим процент неуспешных проектов все еще остается высоким, что увеличивает риски экономической деятельности в целом (по данным отчета CHAOS Report, The Standish Group, 2015). Важной составляющей успеха является правильный выбор методологии управления проектом. Именно поэтому еще на этапе инициации необходимо обоснованно выбрать методологию и качественно запланировать методы управления и основные активности.

Одной из ключевых характеристик современного рынка является высокая неопределенность и увеличивающаяся скорость наступления изменений. Рыночные тенденции объясняют одну из главных проблем современных проектов - в процессе реализации проекта меняется и бизнес-среда (рыночная конъюнктура), то есть что мы делаем, и технологии, используемые передовыми компаниями-конкурентами, то есть как мы это делаем. Это приводит к тому, что заказчик не может сформулировать детально и исчерпывающе свои требования на этапе инициации. Специфика текущей ситуации на рынке заставляет менеджера планировать работу таким образом, чтобы была возможность вносить изменения во время реализации проекта, что не представляется возможным в рамках классической модели фиксированного объема, бюджета и сроков.

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

В настоящее время наблюдается активный рост развития гибких методологий. Зарекомендовавшие себя в проектах по разработке программного обеспечения (далее - ПО), их начали использовать в других индустриях - финансовые сервисы, страхование, государственное управление, здравоохранение, тяжелая промышленность и т.д. (по данным отчета The 12th Annual State of Agile Report, 2018). Согласно отчету CHAOS Report (2015), проекты, на которых использовались гибкие методологии, стабильно реализуются успешнее тех, на которых используются традиционные (см. Таблицу 1):

Таблица 1 Кол-во успешных и неуспешных проектов в зависимости от методологии и размера, %

Размер проекта	Метод	Успешный проект, %	Неуспешный проект, %
Проекты всех типов	Agile	39%	9%
	Waterfall	11%	29%
Крупные	Agile	18%	23%
	Waterfall	3%	42%
Средние	Agile	27%	11%
	Waterfall	7%	25%
Мелкие	Agile	58%	4%
	Waterfall	44%	11%

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

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

Целью данной работы является оценка влияния элементов гибких методологий на успех ИТ-проекта. Объектом исследования выступят гибкие методологии, применяемые для управления ИТ-проектами, предметом исследования - особенности применения гибких методологий в управлении ИТ-проектами.

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

Для достижения поставленной цели и проверки гипотезы были поставлены следующие задачи:

Провести анализ академической литературы по теме:

Определить понятие гибкие методологии;

Определить критерии успеха проекта;

Оценить эффективность применения гибких методологий и ограничений применения.

2. Выделить перечень исследуемых элементов гибких методологий.

4. Разработать анкету для проведения опроса.

5. Организовать и провести анкетный опрос.

6. Интерпретировать полученные результаты.

7. Сформировать практические рекомендации по использованию гибких методологий.

8. Определить дальнейшее направление исследования.

Работа составлена из трех частей. В первой части представлен анализ академической литературы:

представлено обоснование появления гибких методологий и освещены проблемы в управлении проектами, которые они призваны решить;

описаны три наиболее популярные на сегодняшний момент гибкие методологии или методы - Scrum, Kanban, XP Programming - и их гибридные варианты, ScrumBan и XP Hybrid Scrum;

представлена динамика развития исследований в определении понятия успех проекта и описан современный взгляд на проблематику;

перечислены работы по изучению критериев и факторов успеха проектов в зависимости от применений гибких методологий.

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



Глава 1. Анализ академической литературы на тему гибких методологий

1.1 Обоснование появления гибких методологий

При описании «гибкости» проектов авторы разделяют подходы на традиционные, классические («тяжелые») и гибкие («легкие») (Highsmith, 2010; Vallona, 2018). Традиционные методологии основываются на линейном подходе. В этом случае план представляет собой отдельный этап, а реализация проекта осуществляется по схеме планирование - реализация - завершение. Гибкие методологии, в свою очередь, используют итеративный подход и разработаны таким образом, чтобы легко принимать возникающие изменения. Вместо единого этапа планирования используется планирование «по необходимости». Это позволяет команде приспосабливаться к условиям высокой неопределенности и возможности появления изменений.

Для понимания того, какие проблемы в управлении проектом должна решить гибкая методология по сравнению с традиционной, представляется очевидным изучить предпосылки появления и историю развития гибких методологий. Хальгрен и Мааинен-Ольсон (2005) отмечают, что в проектах чаще всего рано или поздно возникают «девиации» - ситуации, которые приводят к отклонению от изначального плана из-за изменений разного характера и размера. Задачей менеджера проекта является запланировать ресурсы на эти отклонения и разработать подход по работе с ними. В интервью, проведенном Кольером и Варреном (2010) с 31 менеджером проекта из 10 отраслей, было выявлено, что традиционные подходы не работают в быстроменяющейся среде потому что не могут справиться с тремя типами изменений в проекте - 1) цели, 2) материалы, ресурсы, техники и инструменты, 3) взаимосвязь с другими продуктами, сервисами и проектами.

В 1970 году У.У. Ройс публикует статью «Managing the Development of Large Software Systems». Из работы была ошибочно выведена каскадная модель разработки ПО . Согласно статье, успешный проект состоял из 7 фаз (см. Рисунок 1):

Рис. 1. Фазы проекта согласно «каскадной модели». Источник: составлено автором.

Разработчик не может перейти к следующей фазе, не завершив предыдущую. Так увеличивается прозрачность процесса и его эффективность (A Guide to the Project Management Body of Knowledge - Third Edition, 2004). Однако, в рамках проекта с высоким уровнем неопределенности и большим объемом, качественно проработать каждую фазу за один раз не представляется возможным.

Кьюсумано и Селби (1997) в работе, описывающей подход к разработке продуктов Microsoft, отмечают, что «Водопад» (одна из каскадных методологий) постепенно теряет популярность, потому что компании, как правило, создают лучшие продукты, если у них есть возможность изменять спецификации и дизайн, получать отзывы от клиентов и постоянно тестировать отдельные компоненты по мере развития продуктов.

В том числе по этой причине в следующее, четвертое издание PMBOK было принято решение добавить альтернативный итеративный метод управления проектом (A Guide to the Project Management Body of Knowledge - Fourth Edition, 2008). Необходимо отметить, что в действительности в своей работе У.У. Ройс (1970) писал о том, что «каскад» необходимо пройти несколько раз для полного покрытия требований и прохождения тестирования, но изначально этому тезису не было уделено должное внимание.

Первыми гибкими методологиями считаются те, которые основаны на принципе итеративности, например rolling wave. Так, суть подхода Rolling Wave planning заключается в том, что планирование происходит на протяжении всего проекта (A Guide to the Project Management Body of Knowledge - Fifth Edition, 2013). В начале проекта общий объем разбивается на компоненты, описываются максимально подробно. Далее составляется детальное планирование расписания на первые этапы проекта (например, на две фазы из четырех), для остальных фаз - на верхнем уровне. По мере приближения к третьей и четвертым волнам, планирование корректируется и детализируется. С одной стороны, такая работа позволяет начать активности по проекту, не дожидаясь всех деталей проекта. С другой стороны, при таком подходе объем проекта должен быть точно определен, иначе присутствует высокий риск неконтролируемого увеличения объема проекта.

Позднее знания об итеративных подходах были соединены 17 независимыми практиками в одном источнике - Agile-манифесте (далее - Манифест). Это была первая попытка задокументировать знания о гибких методологиях, поэтому датой создания Agile принято считать 11-13 февраля 2001 года - дата создания Манифеста в электронном виде. Согласно данному сборнику правил и принципов, разработка по методологии Agile должна соответствовать следующим условиям (Manifesto for Agile Software Development, 2001):

Люди и взаимодействие важнее процессов и инструментов.

Работающий продукт важнее исчерпывающей документации.

Сотрудничество с заказчиком важнее согласования условий контракта.

Готовность к изменениям важнее следования первоначальному плану.

Техники Agile сконструированы таким образом, чтобы использовать минимум документации для поддержания гибкости процесса и быстроты реакции на окружающую среду в сравнении с традиционным подходом. Важно отметить, что Манифест не устанавливает четкие правила управления проектом, как это делают методологии, в нем отсутствуют такие описания, как например, управление процессом, способ планирования, основные роли и документы. Но в то же время Манифест предлагает 12 принципов, на которых должен быть основан конкретный подход к управлению проектом. Так, 17 экспертов - авторов Манифеста - объединили и унифицировали общие правила, используемые в отдельных уже используемых типах гибкой методологии.

Для управления процессом с высоким уровнем неопределенности было разработано множество гибких методологий и методик, каждая из которых продолжает или дополняет другую, такие как: Scrum, Экстремальное программирование (XP - Extreme Programming), Бережливая разработка программного обеспечения (Lean Software Development), Разработка, управляемая функциональностью (FDD - feature driven development), Kanban, Адаптивная разработка (ASD) и др. (Highsmith, 2002). Далее будут подробно описаны самые используемые из них c целью отбора наиболее популярных элементов гибких методологий.

Гибкие методологии были созданы с целью передачи части управленческой власти от проектного менеджера команде проекта. Так, команды будут вовлечены в проект с этапа самоорганизации и смогут во время проекта перепланировать выполнение задач. Такой подход повышает продуктивность, позволяет сотрудникам учиться, применять инновации и повышает уровень удовлетворенности своей работой (Smite, Moe, Agerfalk, 2010). В традиционных методологиях по типу «водопада» работа управляется менеджерами, что создает жесткую иерархию и разделение ролей в команде (Moe, Khang, 2008).

Согласно отчету VersionOne за 2018 год, наиболее используемыми гибкими подходами являются Scrum (54%), Гибридные методологии (14%), Scrum/XP Hybrid (10%), ScrumBan (8%), и др. Кроме Scrum, наибольше популярностью обладают гибридные методологии, что в очередной раз подтверждает актуальность исследования влияния не отдельной методологии на успех проекта, а элементов гибких методологий. Тот же список наиболее популярных методологий выявили в своем исследовании Валлон и др. (2018): Scrum - 60%, Kanban - 11%, XP & Scrum - 16%. Далее рассмотрим подробнее каждый из данных подходов и их специфические элементы.

Описание гибких методологий

Scrum

Scrum - метод управления проектами, основанный на принципах Agile. Изначально Scrum был разработан для отраслей, связанных с разработкой ПО, однако в последнее десятилетие подход успешно применяется в других областях и индустриях (Wykowski, Wykowska, 2018).

История Scrum

Метод был впервые представлен Хиротака Такеши и Икудзиро Нонака в статье The New Product Development Game в журнале Harvard Business Review в 1986. Авторы описывают Scrum как систему управления проектом по разработке нового коммерческого продукта, которая позволяет повысить скорость и гибкость процесса реализации. Термин «Scrum» авторы берут из спортивной игры в регби. Правила игры устроены таким образом, что команда состоит из игроков с различной уникальной ролью, иначе говоря, создается кроссфункциональная команда. Благодаря высокой эффективности коммуникации между игроками, уникальности умений каждого и объединению в команду единомышленников, работающих над одним продуктом, процесс «игры» (в нашем случае речь идет об управлении проектами), становится максимально быстрым и гибким.

Описание Scrum

Scrum изначально был описан в большей степени как структура для управление проектами, а не как отдельная методология с подробно описанным процессом. Таким образом, Scrum можно использовать на многих проектах с итеративными или инкрементальными фазами. Кен Швабер, Майк Бидл и Джефф Сазерленд внесли наибольший вклад в развитие данной методологии (Schwaber, Beedle, 2002; Sutherland, 2014). За последнее десятилетие Scrum получил наибольшую популярность по сравнению с другими методологиями, т.к. вместе с лаконичностью и простотой предлагаемых правил, методология успешно сотрудничает с другими методологиями, как гибкими, так и классическими.

Ключевыми факторами, необходимыми для успешного использования Scrum, являются:

Прозрачность - процесс должен быть полностью доступен для всех участников проекта;

Независимое обследование - скрам-мастеры должны часто обследовать артефакты спринта, чтобы предупреждать проблемы и риски в проекте;

Адаптивность - поскольку независимый наблюдатель будет находить «серые зоны», не проанализированные и не включенные в объем работ на первом этапе, процесс должен быть гибким и сами команды должны гибко подходить к принятию таких запросов на изменение.

К основополагающим правилам метода можно отнести (Kniberg, Skarin, 2010):

Разделение организации на небольшие, кросс-функциональные и самоорганизующиеся команды;

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

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

Оптимизация плана релиза и уточнение приоритетов со стейкхолдерами по результатам прошлых итераций;

Оптимизация процесса путем проведения ретроспективы - церемонии, при которой команда обсуждает аспекты, связанные с работой внутри команды, а именно: эффективность взаимодействия, выявленные проблемы в коммуникации и пути их улучшения.

Процесс реализации части Бэклога в рамках спринтов изображен на Рис. 2:

Рис.2. Процесс разработки по методологии Scrum. Источник: составлено автором.

Ограничения Scrum

С одной стороны, подход Scrum выигрывает перед другими методологиями за счет своих преимуществ, описанных выше. Однако, важно помнить о недостатках или ограничениях метода. Часть из них была описана в статьях Акифа и Маджид (2012) и Турка, Франса и Румпе (2002). Метод не работает эффективно в следующих случаях:

Продукт тесно связан с legacy-системами или обязан пройти проверку Отдела технического контроля. В Scrum методе часть продукта должна быть реализована и протестирована полностью в рамках одной итерации. Если продукт подразумевает длительное информационное или техническое тестирование, применение классических методологий будет более оправдано.

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

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

Команда географически распределена по нескольким локациям. Scrum подход подразумевает тесную коммуникацию и постоянное взаимодействие между участниками. Последние достижения в инструментах управления проектами помогли сократить негативное влияние данного барьера (например, создание ПО, позволяющее создать онлайн-доску со Scrum-задачами). Однако, авторы Манифеста утверждают, что общение лицом к лицу по-прежнему наиболее применимо для данного подхода.

Kanban

Kanban представляет собой другой метод по управлению проектами разработки. В этом методе фокус заключается в выполнении задач «точно в срок».

История Kanban

Впервые метод был применен на фабрике «Тойота» в 1962 году и является одной из подсистем производственной системы «Тойоты» (Toyota Production System). Таичи Оно, инженер, разработал Kanban для увеличения производительности на заводе по сборке автомобилей. Название системы управления происходит от системы организации на доске карточек, фиксирующих перемещение продукции на заводе. При этом каждая карточка была сигналом, сколько и какого материала требуется на следующей стадии или в следующем отделе. Система позволила эффективнее контролировать процесс сборки автомобилей, избежать простоев или недостатка материалов на каждом этапе, сократить жизненный цикл реализации продукта и удешевить процесс сборки при сохранении того же уровня итогового качества.

Описание Kanban

Такой эффект достигается за счет правильной приоритизации задач и определения продолжительности каждой задачи в общем потоке (Anderson, 2010). Методология позволяет, с одной стороны, уделить наибольшее внимание задачам с высокой вероятностью появления риска, с другой стороны, - оперативно управлять другими задачами проекта. В универсальном смысле подход Kanban фокусируется на том, чтобы выполнить нужную задачу в необходимый срок с учетом возможностей и квалификации сотрудников и доступности необходимых ресурсов. Проект начинается с разделения объема на так называемые компоненты - части фиксированного объема, сгруппированные по признаку бизнес-ценности (Anderson, 2010).

Принципы Kanban заключаются в следующем:

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

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

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

Увеличение «пропускной способности» команды происходит за счет увеличения эффективности взаимодействия. На регулярных встречах происходит анализ состояния доски, вычисления средней скорости выполнений задачи и обсуждаются пути увеличения этой скорости. По итогам встреч каждый участник понимает, как можно быстрее и эффективнее выполнить свой пул задач.

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

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

Ограничения Kanban

Авторы выделяют следующие причины возможного неуспешного использования подхода Kanban (Sipper, Bulfin, 2010):

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

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

Не стандартизированные операции. Как и в описанном выше случае, не унифицированные операции препятствуют планированию сроков и объема выполнения той или иной задачи.

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

Неопределенность поставки «вводных» материалов. При отсутствия стабильности подачи необходимых для выполнения проекта данных, материалов или ресурсов, выполнить работу с учетом прогнозируемого спроса не представляется возможным.

Наличие жестких временных рамок. Несмотря на установку «выполнения работы в срок», подход Kanban не подразумевает наличие сроков для каждой задачи и строгого срока для конечного продукта, поскольку используется прогнозный спрос.

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

Экстремальное программирование (Extreme Programming, XP)

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

История XP

История методологии начинается с Кента Бека, Уорда Каннингема и Мартина Фаулера (Кент, 2002). Команда была нанята с целью оптимизации процесса разработки в проекте по оплате труда в компании Chrysler Comprehensive Compensation System (C3). Продукт поставлялся не вовремя и низкого качества, нужны были срочные изменения управления проектом. Нововведение в системе управления началось с того, что вместо установленного срока объединения и загрузки кода раз в три недели команде разработчиков было предложено самим определить дату обновления, исходя из потребностей проекта.

Описание XP

Методология Экстремального программирования основана на пяти принципах: простота, готовность к критике, коммуникация, уважение и смелость. Правила Экстремального программирования состоят из 29 правил, разделенных на четыре пункта - планирование, управление, тестирование, проектирование и разработка кода. Необходимо отметить, что многие элементы методологии повторяют элементы подхода Scrum, однако процесс реализации проекта отличается.

Для целей работы представляется полезным изучить основные 12 практик Экстремального программирования, разделенные на четыре блока:

Короткий цикл получения обратной связи:

Игра в планирование;

Парное программирование;

Разработка через тестирование;

Быстрая обратная связь;

Непрерывный процесс разработки:

Непрерывная интеграция;

Рефакторинг;

Небольшие, но частые релизы;

Разделяемое всеми понимание:

Стандарты написания кода;

Коллективное владение кодом;

Простой дизайн;

Системная метафора.

Благополучие разработчика:

Фиксированный рабочий день, отсутствие переработок.

Процесс разработки по методологии изображен на Рисунке 3:

Рис. 3. Процесс управления проектом по методологии XP. Источник: Don Wells, 2000.

Ограничения XP

Несмотря на доказанную эффективность, существует критика некоторых аспектов данного подхода. Существенная часть критики относится к Agile методам в целом, например, требование вовлеченности участников, высокий уровень квалификации каждого разработчика (Boehm, Turner, 2004). К уникальным ограничениям структуры XP можно отнести следующие (Stephens, Rosenberg, 2004):

Подход ведет к «разрастанию» первоначального объема требований (scope creep), что приводит к невыполнению сроков и/или бюджета проекта.

Требования к системе представлены в виде автоматических acceptance test (вид тестов для финального тестирования продукта перед запуском), а не в виде специфицированных согласованных документов.

Ввиду коротких итераций и необходимости иметь работающий функционал по истечению срока, разработчики строят свою работу таким образом, чтобы построить программный продукт, покрывающий максимально возможным функционал минимальными усилиями разработчика. При этом код усложнятся и дополняется только в случае не пройденных acceptance test. Этим система напоминает подход code-and-fix, который ведет к большим трудовым затратам, нежели только небольшое изменение функционала по запросу от заказчика после демонстрации, как в методологии Scrum. Иными словами, одна и та же область программного продукта может быть разработана несколько раз, что значительно дольше, чем следование заранее согласованному плану.

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

Гибридные методологии

Далее будут описаны гибридные методологии ScrumBan и XP Hybrid, показавшие свою эффективность и используемые в той же мере, как и другие гибкие методологии.

ScrumBan

Подход ScrumBan представляет собой гибкую методологию управления проектами, основанную на подходах Scrum и Kanban. Изначально система была выработана как переходная между Scrum и Kanban для команд, работающих по Scrum и желающих освоить концепты методологий Lean и Kanban (Ladas, 2009). От «переходной» методологии ScrumBan был развит до полноценного подхода. Согласно концепции, команда, работающая по методы Scrum, использует Kanban техники для регулярной оценки эффективности своей деятельности и постоянного увеличения производительности. Пример визуализации процесса изображен на Рисунке 4:

Рис. 4. Пример Kanban-доски для гибридной модели. Источник: составлено автором

К основным правилам методологии относятся (Reddy, 2016):

Короткие итерации продолжительностью в несколько недель, не более трех.

Планирование осуществляется по требованию на основании того, сколько позиций на доске задач находятся в статусе «Сделать».

Приоритизация задач проходит каждую сессию планирования.

Планирование «по корзинам» (Bucket size planning) подразумевает наличие трех видов задач:

Долгосрочные (1 год) посвящены стратегическим целям компании, например, запуск нового продукта, освоение нового рынка и т.д.;

Среднесрочные (6 месяцев) включают в себя те долгосрочные задачи или проекты, по которым уже составлен подробный план;

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

Для детального планирования используется Канбан-доска со статусами «Сделать», «В работе» и «Выполнено». При необходимости статус «В работе» может быть разделен на более мелкие подэтапы. Как и в методологии Kanban, статус «В работе» имеет ограничение по количеству задач.

Нет жестких требований к составу команды проекта, при этом, в отличие от системы Scrum, команды могут быть менее кросс-функциональными.

Задачи назначаются не руководителем команды и не менеджером проекта, а самой командой. Каждый участник выбирает, какую задачу он возьмет из списка «Сделать». Такой подход гарантирует, что участники будут равномерно загружены и процесс будет проходить ровно и эффективно. Однако, такой принцип работает только в случае сильной вовлеченности каждого участника команды и отсутствия «проблемы безбилетника».

«Заморозка функций» (Feature freeze) проходит за некоторое время до наступления дедлайна проекта. Это означает, что никакие дополнительные функции не могут быть разработаны или никакие дополнительные отдельные бизнес-процессы не могут быть взяты в работу. Доработки осуществляются только по не законченным задачам.

Сортировка оставшихся задач (Triage) осуществляется после «заморозки функций». На этом этапе проектный менеджер решает, какие задачи должны быть завершены в первую очередь, а по каким работа может быть не завершена. Это гарантирует, что наиболее важные и необходимые элементы будут завершены к сроку.

XP Hybrid Scrum

Подход XP Hybrid Scrum сложно назвать полноценной методологией с учетом имеющейся литературы. В настоящее время система представляет собой набор практик, используемых изначально в методологиях Scrum и XP. Необходимо заметить, что подходы гармонично и эффективно дополняют друг друга, поскольку Scrum - подход к управлению проектом в целом, определяет рамки управления сроками, командой и работами, в то же время XP - система управления разработкой программного продукта.

Не существует согласованной формулы комбинации между практиками Scrum и XP. Один из подходов был предложен Муштаком (2012). Заключается он в том, что общие рамки проекта - церемонии, артефакты, роли - определяются методологией Scrum. В рамках спринта разработка осуществляется по правилам методологии XP: с использованием парного программирования, разработки через тестирование, высокой вовлеченности пользователя, рефакторинга и т.д. Такой метод позволяет, с одной стороны, преодолеть «слабые места» метода XP, а именно: управление проектом средних и крупных размеров, недостаток практик менеджмента (фокус на процессе разработки) и зависимость от отзыва пользователя, что повышает риск неудачи проекта. С другой стороны, данный подход решает проблему применения «чистого» Scrum - процесс разработки недостаточно детально организован и не учитываются специфические черты программного продукта.

В этом разделе были представлены основные элементы наиболее популярных гибких методологий. Следующий раздел будет посвящен изучению вопроса о том, что входит в понятие проектного успеха.

В качестве итога можно определить список элементов, присущих наиболее популярным гибким методологиям (см. Таблицу 2):



Таблица 2 Список элементов наиболее популярных методологий

Методология	Список элементов
Scrum	Бэклог проекта Пользовательские истории Спринт Стэнд-ап Планирование спринта
Scrum	Рефайнмент сессия Оценка ПИ в очках Scrum-роли Ретроспектива
Kanban	Канбан-доска Ограничение по количеству задач на одной стадии Определение объема работы и ожиданий в начале проекта
XP	Игра в планирование Парное программирование Разработка через тестирование Быстрая обратная связь Непрерывная интеграция Рефакторинг Небольшие, но частые релизы Стандарты написания кода Коллективное владение кодом
Окончание Таблицы 2
XP	Простой дизайн Системная метафора Фиксированный рабочий день, отсутствие переработок.
ScrumBan	Короткие итерации (1-2 нед.) Планирование по требованию Планирование «по корзинам» «Заморозка функций» Сортировка оставшихся задач
XP Hybrid Scrum	Сочетание элементов Scrum и Kanban

Интенсивное развитие изучения того, что стоит включать в понятие успех проекта обусловлено тем, что тема несет не только академическое значение, но и практическую значимость. Чтобы измерить и сравнить эффективность использования той или иной методологии, необходимо определить показатели, по которым будет в итоге оценен вклад в успех проекта. Представляется очевидным, что для этого необходимо понять, что входит в понятие «успех».

В литературе существует множество интерпретаций данного определения, ведущее к различным используемым индикаторам успеха. При этом ученые до сих пор не пришли к консенсусу о том, как измерять успех проекта (Albert, Balve, Spang, 2017). Известно, что в проектах разных типов будут разные наиболее важные критерии успеха (Alami, 2016; Chang, Chih, Chew, Pisarski, 2013, Baccarini, Collins, 2004). Критерии успеха могут варьироваться в зависимости от типа проекта, его сложности, фазы жизненного цикла, индустрии, национальности, организационной структуры (Mьller, Jugdev, 2012; Mьller, Turner, 2007). Также стоит отметить, что разные стейкхолдеры имеют разное представление и ожидание относительно успешности проекта, поскольку могут обладать разным видением критериев успеха и результативности (Davis, 2014, 2017).

1.2 Развитие понятия «успех проекта» до 2000-х

Традиционный подход к изучению успеха проекта фокусируется на том, что проект должен быть выполнен в установленном качестве и/или объеме, в планируемый срок и в рамках запланированного бюджета, т.е. в рамках «проектного треугольника», или «железного треугольника». (Atkinson, 1999; Kerzner, 2003). Однако, в период 1980-1990-х годов акцент в исследовательских работах был на развитие системы или схемы успеха проекта с включением не только осязаемых параметров, но и не осязаемых, более сложно поддающихся вычислению (Mьller, Jugdev, 2012). В это время ограниченное академическое понятие успеха проекта не соответствовало корпоративной реальности, с которыми сталкивались проектные менеджеры. В анализ были включены показатели таких измерений, как удовлетворенность клиента и долгосрочные результаты проекта (Baccarini, 1999; Shenhar, Dvir, Levy, Maltz, 2001). Так, цели и результаты проекта должны поддерживать стратегические цели компании. Шенар и др. (2001) пишут, что теперь проектные менеджеры становятся новыми стратегическими лидерами, кто должен нести полную ответственность за результаты проекта. Есть несколько примеров проектов в ИТ- и других индустриях, в которых цели проекта были достигнуты, однако в долгосрочном периоде проект привел к крупным потерям в контексте всей организации (Alami, 2016). Иными словами, успешный менеджмент может привести к успеху проекта, однако, проект может провалиться вне зависимости от проектного менеджмента (Ika, 2009).

В период 1999-2000-х в анализ были включены такие понятия, как вклад в бизнес стратегию и развитие личностное, команды и организации в целом (Jugdev, Mьller, 2005).

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

Современное понятие «успех проекта»

Важно отметить, что в периоде с 2001 до 2005 критерии успеха проекта определялись на теоретическом уровне и малое количество теорий было проверено на практике (Shenhar, Dvir, Levy, Maltz, 2001; Сollins, Baccarini, 2004; Diallo, Thuillier, 2004). После 2015 года большинство сформированных систем определения успеха проекта, подтвержденных эмпирическими данными, строилось в определенном концепте. Это говорит о том, что проекты должны быть изучены в контексте (Castro, Bahli, Farias Filho, 2019; Ika, 2009).

Чтобы преодолеть рамки классического «треугольника» проекта, исследователи популяризировали и развивали теории, фокусирующиеся на выгоде, который проект принес стейкхолдерам и организации. Успех проекта может быть измерен его эффективностью и результативностью (Castro, Bahli, Farias Filho, 2019). Выполнение сроков, бюджета и объема показывают эффективность проекта, в то время как результативность может быть измерена с помощью бенефитов для стейкхолдеров и организации. О важности данных измерений писал еще Аткинсон (1999), один из первых исследователей, занимающихся концепцией успеха проекта. Выводы исследования не имели эмпирического обоснования, однако уже было готово объяснение того, почему некоторые проекты, выполненные в срок и в рамках бюджета заканчивались неудачей, в то же время как другие - законченные с опозданием и перерасходом средств - могли в итоге быть признаны успешными (Serrador, Turner, 2015).

Несмотря на то, что большинство измерений проекта в той или иной степени затрагивает измерения проекта, связанные с временем, объемом и бюджетом, одним из наиболее важных критериев успеха проекта является выполнение ожиданий заказчика (Baccarini, Collins, 2004). Баккарини (1999) разделяет успех проекта на два измерения - успех проектного менеджера (срок, бюджет, объем) и успех продукта - эффект от результата проекта. Он предлагает новую структуру, в которой есть исходные и итоговые данные для успеха управления проектом и цели - для успеха продукта проекта.

Шенар (2001) группирует показатели проекта по четырем измерениям: 1) эффективность проекта, 2) влияние на заказчика, 3) прямой эффект на успех организации, 4) стратегическая ценность. Выбор параметров успеха проекта зависит от типа проекта. Для проектов с низким уровнем неопределенности, где важна эффективность, успех в большей степени определяется временем и бюджетом. Когда уровень неопределенности высокий и низкая результативность в краткосрочном периоде может быть компенсирована долгосрочными бенефитами, другие критерии успеха окажутся релевантными. Структура, предложенная автором, была эмпирически проверена и использована в последующих работах (Castro, Bahli, Farias Filho, 2019).

Другая концепция была предложена в работе Диалло и Туилльера (2004). Авторы разделили критерии успеха на три измерения: 1) профиль, вероятность получение дополнительного финансирования, полученный результат и репутация, 2) бюджет, сроки и цели, 3) длительность, вклад, удовлетворенность. Авторы попытались вывести универсальное правило, которое проверили и подтвердили на нескольких проектах, отличающихся по секторам и уровню завершенности, в странах Африки.

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

Начиная с 2005 года, фокус в академической литературе меняется с теоретических работ по определению успеха проекта на эмпирические работы, изучающие критерии успеха в контексте определенного проектного типа. Необходимо отметить, что разные авторы в своих работах использовали разные понятия «тип проекта» в зависимости от его длительности, отрасли, уровня завершенности и т.д. Мое и Канг (2008) тестируют новую модель определения успеха проекта в контексте международных проектов по недвижимости, компилируют различные критерии успеха для разных стадий жизненного цикла проекта и корректируют критерии на индивидуальные особенности секторов и свойств заказчика. Аль-Тмиими и др. (2011) тестируют концепцию успеха проекта в зависимости от успеха менеджмента, проекта и рынка для строительных проектов в Малайзии.

В недавнем исследовании Кан и др. (2013) развивают и успешно проверяют модель факторов успеха проектов публичного сектора в Пакистане с учетом анализа академической литературы за последние 40 лет. Их модель предлагает баланс между «жесткими» и «мягкими» факторами и критериями успеха проекта. В итоге авторы используют следующие измерения:

1) Эффективность проекта, 2) Бенефиты для организации, 3) Вклад проекта, 4) Удовлетворенность заказчика, и 5) Будущий потенциал.

В количественном исследовании Панкратц и Бастен (2014) провели интервью с 11 менеджерами, занимающимися внедрением информационных систем. Авторы выделили восемь критериев успеха проекта: 1) Соответствие бюджету, 2) Соответствие срокам, 3) Выполнение требований по функциональности, 4) Выполнение бизнес-требований, 5) Эффективность проекта, 6) Удовлетворенность заказчика, 7) Удовлетворенность подрядчика, 8) Использование заказчиком конечного продукта.

Мир и Пиннингтон (2014) адаптировали модель Шенар и др. (2001), добавив в модель новое измерение - влияние на команду. Далее авторы протестировали модель на проектноорниентированных организациях в Арабских Эмиратах. Эта структура была использована в работе Мартенса и Карвало (2016) с включением нового критерия - устойчивости.

До сих пор авторы не пришли к единому мнению о том, что составляет исчерпывающий список факторов успеха проекта. Более того, большинство работ основаны на теоретических исследованиях, а не на эмпирических (Pankratz, Basten, 2014). Несмотря на то, что единого мнения нет, авторы согласились, что изучать и дополнять эти факторы критично. Кан и др. (2013) пишут, что в зависимости от того, что сама организация понимает под успехом проекта, зависит успешность проектов. Определение критерия результата проекта как важного повышает вероятность, что к концу проекта этот критерий будет выполнен (Mьller, Turner, 2007). В то же время формально определенный критерий успеха повышает эффективность распределения ресурсов и улучшает результат (Thomas, Fernбndez, 2008). Анализ проектного успеха также привносит ценность в управление знаниями в проектной деятельности компании (Todoroviж, Petroviж, Mihiж, Obradoviж, Bushuyev, 2015). Именно по этой причине исследователи стремятся разработать теоретический концепт, который впоследствии предложит наиболее полезные улучшения для методологии управления проектом. Такой анализ позволяет понять, как, например, личность менеджера (Hassan, Bashir, Abbas, 2017), трансформационное лидерство (Mazur, Pisarski, 2015), удовлетворенность работой и доверие (Rezvani, Chang, Wiewiora, Ashkanasy, Jordan, Zolin, 2016) влияют на успех проекта. Кроме этого, исследования в области помогает понять, что стоит за провалом проекта (Alami, 2016; Chow, Cao, 2008).

Общая модель определения успеха проекта должна предлагать менеджменту руководство по тому, на какие критерии необходимо обратить внимание, чтобы обеспечить успех проекта. Наличие разных подходов ведет к несогласованности анализов и может привести к противоположным результатам (Albert, Balve, Spang, 2017). Кроме того, не обоснованно требовательная и обширная система критериев успеха проекта может привести к завышенным ожиданиям со стороны стейкхолдеров, ведущим к конфликту между заказчиком и менеджментом проекта (Hussein, Ahmad, Zidane, 2015).

1.3 Влияние использования гибких методологий на успех проекта

Представляется очевидным, что при наличии такого количества разных подходов в менеджменте для определения критериев успеха проекта, для анализа влияния гибких методологий подход необходимо специфицировать на основании релевантной академической литературы. Изначально гибкие методологии применялись в проектах по разработке программных продуктов. По этой причине влияние использования методологии на успех проекта в этой отрасли наиболее подробно изучено. Однако даже в рамках одной отрасли существует широкая вариативность в определении успеха проекта по разработки ПО (Agarwal, Rathod, 2006).

Для дальнейшего анализа необходимо выявить, на какие характеристики успеха проекта обращали внимание авторы, когда исследовали влияние гибких методологий на успех проекта. В первую очередь, основу критериев успеха проекта составляет «проектный треугольник» (Agarwal, Rathod, 2006; Chow, Cao, 2008).

Работа Чой и Чао (2008) является одной из основополагающих работ в определении критериев успеха проекта в проектах по разработке ПО с использованием гибких методологий. В работе авторы исследовали как факторы успеха, так и факторы провала проекта. Авторы определили 19 факторов провала и 36 факторов успеха. Успех проекта определяется по четырем измерениям: объем (выполнение всех требований проекта, время (сдача проекта вовремя), стоимость (соблюдение рамок бюджета и плана) и качество (например, удовлетворительный конечный продукт или результат проекта). Факторы провала сгруппированы так же по четырем категориям: организация, люди, процесс и технология.

При использовании гибких методологий оказывается критичным как управление результативностью (performance management), так и ориентация на взаимоотношения в команде и социальный контекст. Согласно Шефиду и Лематье (2013), практики, используемые при разработке ПО, должны совпадать с методологией менеджмента и процессами управления в компании (управление проектами, бизнес-анализ, бизнес-процессы, выстраивание ИТ) на разных уровнях (разработка ПО, проект, программа и т.д.) (Sheffield, Lemйtayer, 2013). Авторы используют для этого трех-уровневую иерархическую модель - техническая, организационная и внешняя части.

Шефид и Лематье (2013) выделили следующие факторы успеха проекта, связанные с окружением проекта: организационная культура (консервативная или предпринимательская), стабильность организации и индекс дистанции власти. Среди факторов окружения проекта авторы выделяют гибкость, поддерживаемая топ-менеджментом компании, уровень предпринимательства и склонность к риску. Таким образом, факторы отражают корпоративную культуру организации. Проектный фактор, выраженный в усилении проектной команды, включает в себя уровень гибкости заказчика, близкое сотрудническое с заказчиком и полномочия, предполагаемые процедурой.

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

Станкович и др. (2013) своем исследовании выявили три фактора, влияющие на успех проекта, - определение процесса в проекте, природа проекта, тип проекта.

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

В данной главе были описаны и проанализированы наиболее популярные гибкие методологии и их составляющие - Scrum, Kanban, XP. Детальное описание подходов и рассмотрение ограничений применения того или иного метода позволит более критично провести практическое исследование и даст теоретическую «почву» для объяснения полученных результатов.

За последние двадцать лет теория исследования влияния гибких методологий активно развивается благодаря накопленному практическому опыту. При этом в теории до сих пор присутствуют некоторые нераскрытые области, а именно: существуют ли «универсальные» элементы гибких методологий, гарантированно увеличивающие вероятность успеха проекта, от чего зависит эффективность применения гибких методологий и есть ли характеристики проекта, которые не могут сосуществовать с гибкими методологиями.

...