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

Проанализировав недостатки водопадной модели при ее использовании для управления 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.		86,3%.	937 600.	1 260 800.	34,5%.
«Скрам».				18,6%.	915 487.	1 076 171.	17,5%.

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