1. Что было сделано с момента прошлого такого совещания?

2. Что планируется сделать к следующему такому совещанию?

3. Какие существуют сложности, тормозящие процесс выполнения задания?

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

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

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

Рис. 12 Организация обратной связи в рамках обзора итогов спринта

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

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

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

В общем и целом, «скрам»-процесс может быть схематически представлен следующим образом (рисунок 13):

Рис. 13 Полноценный "скрам" процесс



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

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

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

Такой подход стимулирует проявление энтузиазма и активности у разработчиков.

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

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

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

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

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

Глава III. Управление проектом внедрения специализированного программного обеспечения в Банк

3.1 Характеристика внедряемого программного обеспечения в Банк

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

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

· Автоматизировать бизнес-процесс кредитования в Банке;

· Автоматизировать современные методы оценки риска клиента и заявки в соответствии с кредитной политикой Банка;

· Минимизировать время рассмотрения заявки на выдачу кредита;

· Уменьшить операционные риски Банка;

· Сформировать новое продуктовое предложение клиенту, соответствующее его риск-сегменту.

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

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

В рамках рассмотрения одной заявки будет произведено несколько обращений к внедряемой системе с помощью пользовательского интерфейса. Обмен данными между системами осуществляется посредством обмена XML-сообщениями, в которые при каждом вызове дописывается новая информация. Схема XML-обмена приведена на рисунке 15:

Рис. 15 Схема XML-обмена

После одного из последних обращений к системе XML-сообщение содержит в себе риск-сегмент заявки, после чего, согласно кредитной политике банка принимается решение о выдаче кредита.

3.2 Управление проектом внедрения ПО на основе водопадной модели

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

Базовый план проекта и распределение ресурсов были построены в программе управления проектами Microsoft Office Project (рисунок 16):



Рис. 16 Базовый план проекта по внедрению ПО в банк

Соответствующая базовому плану диаграмма Ганта (визуализированная цепочка задач) представлена на рисунке 17:

управление банк менеджмент скрам

Рис. 17 Диаграмма Ганта проекта

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

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

Сравнение запланированных и фактических сроков выполнения проекта в процессе выполнения работ продемонстрировано на рисунке 18. Среди 14 задач 9 из них имели существенные отклонения по длительности: задача № 3, задача № 4, задача № 5, задача № 6, задача № 7, задача № 8, задача № 10, задача № 11, задача № 12. На рисунке они выделены цветом:

Рис. 18 Отклонения фактического плана от базового

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



Рис. 19 Диаграмма Ганта с отслеживанием

С помощью наблюдения за ходом выполнения проекта были выявлены и систематизированы следующие причины задержек задач проекта:

Задача № 3 «Сбор бизнес требований и документирование стратегии принятия решений». Базовая длительность предполагалась равной 35 дням, фактическая составила 46 дней.

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

· Долгое формирование требований, стремление к минимизации рисков путем полной аналитики возможных разногласий в будущем. Как следствие - задержка момента подписания технического задания со стороны Банка (заказчика);

· Вносились корректировки и добавления в рисковую политику, а как следствие, в требования к программному обеспечению;

· Долгая неопределенность операционного отдела в предоставлении своих требований аналитикам по работе внедряемого программного обеспечения;

· За задержки с Банка не взималась дополнительная плата, так как на тот момент не было подписано техническое задание (оно стало результатом данного этапа).

Задача №4 «Проектирование модели данных на базе кредитной политики»: Базовая длительность предполагалась равной 3 дням, фактическая составила 14 дней.

· Во время предыдущего этапа отдел маркетинга не участвовал в формировании требований к программному обеспечению, но на текущем этапе его представители решили внести собственные пожелания по работе внедряемой программы с клиентом. Эти изменения в требованиях, по словам исполнителя, в некоторых местах противоречили ТЗ, поэтому за доработку этих требований Банк заплатил 79 200 рублей.

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

· Задержки на этом этапе связаны с коммуникацией между исполнителем и компаниями, которые предоставляли дополнительные сервисы (CreditRegistry, ЦФТ).

Задача №8 «Разработка схемы XSD модели данных»: Базовая длительность предполагалась равной 2 дням, фактическая составила 8 дней.

· На данном этапе разработчику пришлось изменить первоначальную модель данных, так как операционный отдел и отдел маркетинга Банка запросили новый функционал, необходимый им для работы с клиентом (возможность отсылать заявку клиента на предыдущий этап). Запрос на изменение стоил банку 24 000 рублей.

Задача №9 «Разработка тест-стенда для проверки корректности реализованной стратегии»: Базовая длительность предполагалась равной 37 дням, фактическая составила 41 дней.

· Тест-стенд получает на вход XML-сообщение, затем обращается к серверу, где находится программное обеспечение по принятию решения о выдаче кредита, обрабатывающее запрос, и после этого на экран возвращается новое, дополненное XML-сообщение с результатами проверки. Тест-стенд в своем первом релизе не имел функционала сохранения XML-ответов, что показалось крайне неудобным Банку. Проблема задержки на данном этапе вызвана разным толкованием ТЗ разработчиками и работниками банка. Исполнитель считал, что задача выполнена корректно, по крайней мере предмет спора не был описан в ТЗ, в то время как Банк посчитал что такой очевидный пункт не стоило даже подробно описывать. Дополнительные работы исполнитель оценил в 32 000 рублей.

Задача № 10 «Программирование стратегий во внедренной ИС»: Базовая длительность предполагалась равной 33 дням, фактическая составила 54 дней.

· Задержки на данном этапе связаны с явными изменениями бизнес требований программного обеспечения, вызванными корректировками отдела маркетинга, операционного отдела и отдела рисков. Многие из нововведений повлекли за собой изменения в модели данных (андеррайтеры из операционного отдела захотели видеть на интерфейсе распределение дохода по месяцам, произошло уточнение функционала некоторых кнопок на экранных формах, например, появилась возможность осуществления визуальной оценки клиента). Запросы на изменения на текущем этапе обошлись Банку в 84 000 рублей.

Задача № 11 «Модульное тестирование разработанной стратегии»: Базовая длительность предполагалась равной 6 дням, фактическая вышла 19 дней.

· С результатами тестирования были ознакомлены сотрудники отдела рисков Банка. Задержки во время выполнения данной задачи вызваны расхождением между разработчиками программы и сотрудниками отдела рисков по поводу корректности настроенной стратегии. Заказчиком были установлены новые требования, учитывающие динамику заявки клиента во времени (в ТЗ данный функционал описан не был). Трудозатраты на добавление такого функционала были оценены менеджером проекта в 32 часа, что в денежном выражении равно 16 000 рублям согласно ставке разработчика.

Задача №12: «Интеграционное тестирование внедренной ИС с фронт-офисным решением»: Базовая длительность предполагалась равной 10 дням, фактическая составила 20 дней.

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

· Внедряемое программное обеспечение рассчитывает рисковые показатели, риск-сегмент клиента, а также проверяет соответствие правилам кредитной политики банка. Вышеописанные действия предполагают формирование некоторых комментариев, которые в бизнес требованиях и ТЗ записаны на русском языке (пример «Клиент имеет негативную кредитную историю»). Их реализация была осуществлена на этапе программирования стратегии, однако на этапе интеграции с фронт-офисным решением выяснилось, что передача данных возможна только с помощью латинского алфавита; таким образом, разработчикам пришлось вводить понятие «транслитерации» для решения данной проблемы. Существенное время было потрачено на обсуждение проблемы между заказчиком проекта (Банком) и менеджером проекта.

· Издержки, понесенные Банком на данном этапе, составили 72 000 рублей.

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

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

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

3) Отклонение по времени составляет 88,5 дней (в базовом плане предполагалось 102,5 дней, фактически вышло 191 день);

4) В плане предполагалась стоимость проекта равная 937 600 рублям, фактическая составила 1 465 600 рублей, из которых 323 200 рублей - запросы на изменения, соответственно, стоимость проекта для Банка равняется 1 260 800 рублям (рисунок 20):



Рис. 20 Сравнение затрат

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

Поэтому критерий качества в данном случае зависит напрямую от удовлетворения заказчика от полученного, в конечном счете, продукта.

Таким образом, чтобы действительно достичь более или менее желаемый уровень качества, длительность проекта пришлось увеличить на 86,3%, а стоимость на 34,5%.

Введем следующие обозначения:

,

.

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

3.3 Моделирование и анализ внедрения проекта с помощью «гибкой» методологии «скрам»

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

Процесс моделирования можно описать следующим образом:

(1) Вводятся предпосылки, уравновешивающие проектируемую модель с реальной ситуацией:

1. Производительности команд при использовании методологии «скрам» и водопадной модели равны;

2. Количество специалистов той или иной области в двух проектах одинаково

3. Время выполнения задач при использовании методологии «скрам» включает время проведения командой совещаний, что является тоже оплачиваемым заказчиком;

4. Сбор новых требований не занимает дополнительного времени, а происходит в течение «спринта»;

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

(2) Описывается хронология ведения проекта и формализация действий:

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

«Скрам»-проект будет проходить следующим образом:

Ш Владелец Продукта подготавливает к каждому спринту журнал продукта, отсортированный по приоритету;

Ш Каждый спринт начинается с его планирования, т.е. команда определяет количество времени, которое необходимо каждому участнику для выполнения заданий из журнала продукта;

Ш Выбранные задания из журнала продукта переносятся в журнал спринта и, если надо, детализируются разработчиками;

Ш Во время планирования спринта участники команды обсуждают общую идею выполнения задач, их коррелированность с другими специалистами и прочее;

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

Ш Выполнение сроков совещаний, а также поддержание атмосферы в команде обеспечивает Скрам-мастер;

Ш В конце спринта команда демонстрирует настроенный функционал Скрам-мастеру, Владельцу продукта и любым желающим со стороны заказчика (например, топ-менеджменту Банка);

Ш Если Скрам-команда не успевает сделать задание за один спринт, то, в случае мелких недочетов, спринт может задержаться на пару дней, а в случае крупных недоработок это же задание выносится снова в журнал продукта;

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

(3) Оценка базовой длительности задач, описанных с помощью методологии «скрам»:

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

Им была объяснена идея внедрения программного обеспечения по итерациям с помощью методологии «скрам» и был продемонстрирован пример журнала продукта с базовыми требованиями от заказчика, отсортированный по убыванию важности для бизнеса на момент составления:

1. Способность внедряемой системы проверять клиента по минимальным требованиям кредитной политики;

2. Настройка функционала, предназначенного для тестирования настроенной стратегии во внедряемом программном обеспечении;

3. Способность внедряемой системы проверять и оценивать внешнюю кредитную историю клиента;

4. Способность внедряемой системы осуществлять поиск клиента по «черным» спискам (список неплательщиков и клиентов, являющихся должниками);

5. Способность внедряемой системы считать скоринговый балл по формуле, определенной Владельцем продукта;

6. Способность внедряемой системы анализировать результаты телефонной верификации клиента;

7. Способность внедряемой системы определять риск-сегмент заявки;

8. Способность внедряемой системы анализировать результаты проверки клиента по службе безопасности;

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

10. Способность внедряемой системы определять роль для окончательного принятия решения;

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

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

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

Таким образом, на самую первую итерацию (то есть, в журнал спринта) разработчики назначили первую задачу из журнала продукта и часть второй (рисунок 22). План проекта строился с помощью дополнения к программному обеспечению Microsoft Office Project 2010, которое называется Scrum Tool, которое просто помогает формализовать процесс.

Рис. 22 Моделирование первого спринта

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

С учетом важных изменений в требованиях, которые были описаны при рассмотрении плана проекта, построенного с помощью водопадной модели, был смоделирован финальный журнал продукта (после завершения проекта) (рисунок 23):

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



Рис. 23 Состояние журнала продукта в конце проекта

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

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

Таким образом, смоделированный полноценный проект приведен на рисунке 24:



Рис. 24 Представление проекта внедрения ПО в банк с помощью «скрам»-методологии

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

(4) Оценка максимально возможных отклонений по длительности задач, описанных с помощью методологии «скрам»:

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

Смоделированные отклонения фактического плана от базового, построенного по методологии «скрам» представлены на рисунке 25:

Рис. 25 Смоделированные отклонения фактического плана от базового по методологии "скрам"

(5) Сравнение базового и фактического планов:

Проанализировав длительности базового и фактических планов, можно заметить, что отклонение по длительности 18,6% (.

Так как проект, смоделированный с помощью методологии «скрам», не предполагает наличие запросов на изменение, время выполнения которых оценивается в водопадной модели менеджером проекта, важно отметить, что отклонения по стоимости проекта с предлагаемой методологией невелики, так как происходит только доплата за дни задержек. Базовая стоимость проекта оценивается в 915 487 рублей, а фактическая - в 1 076 171 рубль, таким образом, отклонение по стоимости (рисунок 26):

Рис. 26 Сравнение затрат

Как было неоднократно отмечено ранее, итеративный метод управления проектами хорош тем, что уточнение и демонстрация очередной версии ПО происходит довольно часто, после окончания очередной итерации.

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

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

Соответственно, оперируя данными суждениями, можно отметить, что отклонение по качеству продукта, полученного с помощью методологии «скрам» намного меньше отклонения по качеству продукта, полученного с помощью водопадной модели:

В таблице 3 представлено соотношение общих критериев двух моделей: водопадной и «скрам»:

Таблица 3 Сравнение показателей

Модель	Качество	Длительность (дни)	Отклонение (%)	Стоимость (руб)	Отклонение (%)
		Базовая	Фактическая		Сметная	Фактическая
Водопадная		102,5	191	86,3%	937 600	1 260 800	34,5%
«Скрам»		123	146	18,6%	915 487	1 076 171	17,5%

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

Заключение

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

1. Были проанализированы определения терминов «проект» и «IT-проект» для выявления отличительных характеристик последнего. Было выяснено, что управление IT-проектом намного отличается от управления проектом, не связанным с информационными технологиями.

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

3. Было рассмотрено понятие «жизненный цикл IT-проекта» и были проанализированы преимущества и недостатки основных моделей: водопадной (традиционной), итеративной и спиральной. В результате было выяснено, что сильные стороны итеративной и спиральной моделей стали основой создания «гибких» методологий;

4. Была проанализирована специфика предметной области исследования (банковской сферы) на предмет применимости той или иной модели жизненного цикла при управлении IT-проектом. Как следствие, была выдвинута гипотеза о наиболее эффективном применении «гибкой» методологии управления IT-проектом, которая является улучшенным синтезом итеративной и спиральной моделей;

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

6. В работе был разработан базовый план проекта внедрения специализированного программного обеспечения для автоматизированной оценки кредитоспособности клиента и для принятия решения о выдаче кредита в Банк «XXX», основанный на водопадной модели жизненного цикла. После сравнения сроков и стоимости базового проекта с фактически реализованным было выявлено, что для минимизации возможных отклонений по требуемому заказчиком качеству ПО длительность проекта была увеличена на 86,3% а стоимость на 34,5%.

7. Для моделирования проекта по предложенной методологии «скрам» был проведен опрос у команды разработчиков, с целью определения ими длительности выполнения задач и максимально возможных отклонений. По этой методологии «скрам» был смоделирован проект внедрения специализированного программного обеспечения в Банк. Также был смоделирован план «скрам»-проекта, удовлетворяющий качеству и требованиям заказчика с учетом максимально возможных отклонений по длительности решения задач. В результате отклонения по длительности выполнения проекта составили 18,6%, а по стоимости 17,5% при практически минимальных отклонениях от качества.

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



Список использованной литературы

1. Богданов В. Управление проектами. Корпоративная система - шаг за шагом. - М.: Манн, Иванов и Фербер, 2012. - 248 с.

2. Брукс Фредерик. Мифический человеко-месяц, или как создаются программные системы. - М, Символ-плюс, 2010. - 304 с.

3. Вольфсон Б. Гибкие методологии разработки, версия 1.2 (электронная книга), 2012.

4. Грей, Клиффорд Ф. Управление проектами: учебник: пер. с англ. третьего, полн. перераб. изд./ Клиффорд Ф. Грей, Эрик У. Ларсон; [науч. Ред. перевода В. М. Дудников]. - М.: Издательство «Дело и Сервис», 2007. - 608 с. - Доп. тит. л. англ.

5. Грекул В. И., Коровкина Н. Л., Куприянов Ю. В. Методические основы управления ИТ-проектами. - Интернет-университет информационных технологий, 2011. - 392 с.

6. Гробовцов Г. Я. УПРАВЛЕНИЕ ПРОЕКТОМ: Учебно-методический комплекс. - М.: Изд. центр ЕАОИ, 2009. - 288 c.

7. Дитхелм Г. Управление проектами. В 2 т. Т. I. пер. с нем. - СПБ.: Издательский дом «Бизнес-пресса», 2004. - 400 с.

8. Дитхелм Г. Управление проектами. В 2 т. Т. II. пер. с нем. - СПБ.: Издательский дом «Бизнес-пресса», 2004. - 288 с.

9. Мазур И. И., Шапиро В. Д., Ольдерогге Н. Г. Управление проектами: Учебное пособие / Под общ. ред. И.И. Мазура. -- 2-е изд. -- М.: Омега-Л, 2004. -- с. 664

10. Портни, Стэнли И. Управление проектами для «чайников».: Пер. с англ. - М.: Издательский дом «Вилямс», 2005. - 352 с.: ил. - Парал. тит. англ.

11. Разу М. А., Бронникова Т. М., Разу Б. М., Титов С. А., Якутин Ю. В. Управление проектом. Основы проектного управления: учебник / кол. авт,: под ред. проф. М. А. Разу. - М.: КНОРУС, 2006 - 768 с.

12. Товб А. С., Ципес Г. Л. Управление проектами: стандарты, методы, опыт. - М.: ЗАО «Олимп-Бизнес», 2003. - 240 с.: ил.

13. Грекул В. Проектирование информационных систем (лекции), 2010

14. Черных Е. А. Agile Project Management и его история, М., «Менеджмент качества», 02(02)2008

15. Pekka Abrahamsson, Outi Salo, Jussi Ronkainen and Juhani Warsta. Agile Software Development Methods - Review and Analysis, by Technical Research Centre of Finland, 2002. - 107 p.

16. Gary Chin. Agile Project Management: How to Succeed in the Face of Changing Project Requirements, by AMACOM, 2004. - 229 p.

17. Charles G. Cobb. Making Sense of Agile Project Management: Balancing Control and Agility, by Wiley, 2011. - 265 p.

18. Michael Cohn. Succeeding with Agile: Software Development Using Scrum, by Addison-Wesley Professional, 2009. - 504 p.

19. Clifford F. Gray, Erik W. Larson. Project Management: The Managerial Process, 4th Edition, by McGraw-Hill/Irwin, 2008. - 608 p.

20. Bill Holtsnider, Tom Wheeler, George Stragand and Joseph Gee. Agile Development & Business Goals, by Elsevier Inc, 2010. - 256 p.

21. Mark C. Layton. Agile Project Management for Dummies, by John Wiley & Sons, 2012. - 360 p.

22. James P. Lewis. Fundamentals of Project Management (3rd Edition) by AMACOM Books, 2006. - 176 p.

23. Stanley E. Portny. Project Management For Dummies; 2nd Edition, by Willey Publishing, Inc., 2007. - 384 p.

24. Paul Roberts. Guide to Project Management, by Profile Books/The Economist, 2007. - 319 p.

25. Peter Schuh. Integrating Agile Development in the Real World, by Charles River Media, 2004. - 364 p.

26. Jason Westland, Project Management Life Cycle, by Kogan Page Ltd., 2006. - 255 p.

27. A Guide to the Project Management Body of Knowledge (PMBOK Guide), Fourth Edition, Project Management Institute, Inc., 2008.

28. H. Frank Cervone, (2011), “Understanding agile project management methods using Scrum”, OCLC Systems & Services, Vol. 27 Iss: 1 pp. 18-22

29. Dr. Alistair Cockburn, “Using Both Incremental and Iterative Development”, 2008, The Journal of Defense Software Engineering pp.27-30

30. Pete Deemer and Gabrielle Benefield. THE SCRUM PRIMER An Introduction to Agile Project Management with Scrum Version 1.04, goodagile from www.goodagile.com, 2007

31. Gabrielle Benefield. Rolling out Agile in a Large Enterprise, HICSS '08 Proceedings of the Proceedings of the 41st Annual Hawaii International Conference on System Sciences, 2008.

32. Pankaj Jalote, Aveejeet Palit, Priya Kurien, V.T. Peethamber, “Timeboxing: a process model for iterative software development”, The Journal of System and Software (2004), pp. 117-127

33. Yu Beng Leau, Wooi Khong Loo, Wai Yip Tham and Soo Fun Tan. “Software Development Life Cycle AGILE vs Traditional Approaches”, International Conference on Information and Network Technology (ICINT 2012)

34. Louise Ledbrook, “Waterfall Project Management: An Overview”, 2012, http://projectcommunityonline.com/waterfall-project-management-an-overview.html

35. Xavier Amatriain Rubio, Gemma Hornos Cirera. Agile Methods in Research (presentation), by Telefonica, 2008. - 42 s.

36. Ken Schwaber, Jeff Sutherland, “The Scrum Guide”, 2011. - 16 p.

37. Melonfire, “Understanding the pros and cons of the Waterfall Model of software development”, 2006, http://www.techrepublic.com/article/understanding-the-pros-and-cons-of-the-waterfall-model-of-software-development/6118423

38. www.agilelogic.com

39. http://agilemanifesto.org

40. www.banki.ru

41. www.bankir.ru

42. www.creditregistry.ru

43. http://itlegalsolutions.com/e-posobie

44. www.koltsov.by

45. http://rsdn.ru/

46. www.versionone.com

47. http://www.wisegeek.com

Размещено на Allbest.ru

...