Файл: Управление проектом внедрения специализированного программного обеспечения в Банк.docx

1.4.2 Анализ применимости моделей жизненного цикла в банковской сфере

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

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

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

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

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

---

---

Глава II. «Гибкие» методологии управления IT-проектами

2.1. Описание и принципы «гибких» методологий управления IT-проектами

Как было упомянуто ранее, теория «гибких» методологий появилась после осознания преимуществ итеративной и спиральной моделей жизненного цикла по сравнению с традиционной водопадной моделью. В феврале 2001 года состоялась встреча создателей методологии сочетающих в себе основные принципы итеративной и спиральной модели. На этой встрече было решено назвать такие методологии общим словом «гибкие» (agile). «Гибкая» методология – это итеративный процесс, использующий уникальные практики для получения нового функционала программного обеспечения каждые 1-4 недели (Rubio, 2008).

Тогда же в 2001 году были созданы два основополагающих документа: «Манифест гибких методологий разработки» и «Принципы гибкой разработки». В первом из них четко прописаны высокоуровневые ценности, которым уделяется внимание в процессе управления IT-проектом:

«Люди и взаимодействиеважнее процессов и инструментов
Работающий продуктважнее исчерпывающей документации
Сотрудничество с заказчикомважнее согласования условий контракта
Готовность к изменениямважнее следования первоначальному плану» [39].

Первая ценность говорит о том, что вне зависимости от того, какими бы важными процессы и инструменты ни были, успех проекта зависит, в первую очередь, от вовлеченных в этот проект людей, т.е. в «гибких» методологиях очень важным является человеческий фактор, а именно возможность организации эффективной коммуникации, легкость преодоления конфликтов и так далее. Вторая ценность вовсе не исключает документацию, наоборот, она упрощает возможность взаимодействия и сотрудничества, а также налаживает процесс передачи знаний, однако эффективное взаимодействие между людьми намного лучше сказывается на проекте, нежели хорошо описанная документация без взаимодействий внутри команды. Третья ценность подразумевает, что непрерывное общение между заказчиком и командой разработчиков является более целесообразной стратегией, нежели «война» сторон за правильную трактовку ранее подписанного контракта. «Современная практика реализации проектов, как правило, сопровождается затяжными переговорами между участниками. Разумеется, переговоры – один из важнейших элементов деловой практики. Но зачастую они превращаются в игру с нулевой суммой: одна из сторон пытается обеспечить собственные интересы за счет другой стороны» [14, с. 88]. «Гибкие» методологии противопоставляют такой «борьбе» диалог между разработчиками и заказчиками. Такой подход позволяет выигрывать двум сторонам общими усилиями. Последняя четвертая ценность призывает команду проекта быть постоянно готовыми к изменениям. Ни один IT-проект не может заранее быть спроектирован целиком и полностью, со всеми учтенными нюансами. «Гибкие» методологии не отрицают необходимость досрочного планирования, они лишь допускают

---

внесение корректировок в течение времени, отведенного для реализации IT-проекта.

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

Гэри Чин в своей книге «Agile Project Management: How to Succeed in the Face of Changing Project Requirements» (Chin, 2004) более детально перечисляет факторы проекта, наличие которых должно служить сигналом для использования именно «гибкой» методологии управления IT-проектом. Данные факторы автором разделяются на две группы: «внутренние неопределенности» и «внешние неопределенности» (рисунок 6):



Рис. 6 Внутренние и внешние неопределенности проекта

Если проект подвержен каким-то внутренним или внешним неопределенностям, то вполне благоразумно будет планировать его жизненный цикл, используя «гибкие» методологии.

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

---

, отведенное на выполнение конкретной итерации, до пяти недель.

«Гибкие» методологии базируются на эмпирическом управлении, то есть на таком управлении, где решения принимаются, исходя из промежуточных результатов проекта. Кроме того, данные результаты являются прозрачными, что означает, что все вовлеченные в проект люди осведомлены статусом работ по проекту, количеством изменений и возможными проблемами. (Layton, 2012). Нельзя не отметить, что в случае IT-проектов эмпирическое управление позволяет быстро вносить корректировки в программный продукт, и это является большим преимуществом по сравнению с водопадной моделью жизненного цикла.

Последние несколько лет в США проводилось много исследований, направленных на изучение преимуществ «гибких» методологий по сравнению с традиционной водопадной моделью. Например, согласно седьмому ежегодному государственному исследованию «гибкой» разработки Интернет-ресурса Version One, 84% респондентов (разработчиков) признали, что «гибкие» подходы кажутся им более эффективными, чем традиционные подходы.⁵

Кроме того, 70% респондентов этого же исследования признали, что IT-проекты, внедряемые с помощью «гибких» методологий, реализовываются намного быстрее IT-проектов, внедряемых с помощью водопадной модели жизненного цикла (рисунок 7):



Рис. 7 Проекты внедряются быстрее, если используется "гибкая" методология

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

Таблица 1 Ключевые различия «гибких» методологий и водопадной модели

	«Гибкие» методологии	Водопадная модель
Требования заказчика	Итеративный сбор	Детализированные требования четко определяются до начала фазы непосредственного внедрения
Стоимость доработок	Низкая	Высокая
Направление разработки	Может быть изменено в любой момент	Фиксированное
Тестирование	После каждой итерации	Во время соответствующей фазы, следующей за внедрением/разработкой
Вовлеченность заказчика	Высокая	Низкая

---