Пожалуй, нет более популярной темы для обсуждения, чем применение Agile в проектах SAP. Несмотря на то, что принципы гибкой разработки были сформулированы ещё в 2001 году [1], их использование в настоящее время становится как никогда востребованным. Связано это в первую очередь с тем, что последнее десятилетие знаменуется массовым использованием информационных технологий (далее – ИТ) в повседневной жизни: порталы государственные услуг, интернет-магазины, электронное правительство и многое другое. Вышесказанное требует как грамотной разработки программного обеспечения (далее – ПО), так и не менее искусного его внедрения. 

Рис. 1. Ценности и принципы Agile

Agile представляет собой методологию реализации и внедрения ПО на основе итерационной модели и включает совокупность методов, к которым можно отнести FDD (Feature Driven Development - разработка, управляемая функциональностью), XP (eXtreme Programming - экстремальное программирование), Kanban, Crystal и др. Суть методологии заключается в использовании 4 базовых ценностей и 12 принципов (рис. 1), объявленных в манифесте Agile [2], следование которым призвано существенно облегчить имплементацию информационных систем (далее – ИС). Одним из ярких примеров использования принципов Agile является метод Scrum. Рассматриваемый как противовес классической каскадной модели (Waterfall – водопадная модель) внедрения ИС, метод Scrum даёт чёткое представление процесса имплементации и описывает реализацию базовых составляющих манифеста. Справедливости ради следует отметить, что Scrum частично применяется и в водопадной модели, например, для уточнения требований на фазе анализа путём прототипирования.

Напомним, итеративный подход реализации ПО заключается в разбиении процесса внедрения на стадии, называемые итерациями, в рамках которых разрабатывается и демонстрируется заказчику реализованная часть решения [3]. При этом как таковые требования вообще могут отсутствовать, количество предстоящих итераций не известно, а объём проекта изменяем при фиксированных сроках и бюджете. Следуя методу Scrum, итерации называют спринтами, список требований – бэклогом (Backlog), ход проекта контролируют на доске стикерами, а команда рассматривается как самоорганизующаяся [4]. Концептуальная картина ведения проекта имплементации согласно Scrum дана ниже на рис. 2.

Рис. 2. Процесс реализации проекта согласно Scrum

Несмотря на отличие каскадной и итерационной моделей внедрения ИС, в обеих подходах подтверждением работоспособности разработанной системы служит успешно пройденное приёмочное тестирование (User Acceptance Test - UAT) [3]. Однако метод Scrum существенно отличается от обеих моделей из-за отсутствия UAT и документирования решения. Проект внедрения корпоративных информационных систем (далее – КИС) с использованием Scrum состоит из следующих шагов:

• идентификация и анализ требований, предъявляемых к КИС, приоритизация найденных требований и формирование бэклога продукта;

• определение числа и продолжительности спринтов разработки КИС; формирование бэклога спринтов и их распределение по итерациям;

• реализация КИС согласно бэклогу спринта, функциональное и интеграционное тестирование, демонстрация полученного продукта владельцу продукта и заказчику, ретроспектива спринта и обновление бэклогов, а также продуктивная эксплуатация реализованного решения (для всех спринтов) [4].

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

Методология Agile изначально была ориентирована на разработку, но не на кастомизацию ПО, именно поэтому под Scrum командой понимается состав из 5-7 разработчиков. Кастомизация представляет собой настройку ИС, не требующую программной доработки решения. Настройка ПО ведётся силами функциональных консультантов, в то время как реализация решения – программными разработчиками. Следует отметить, что число вариаций настроек системы под нужды заказчика весьма ограничено. Кастомизация ИС обеспечивает стандартизацию, унификацию, а также прозрачность решения: новичку гораздо проще разобраться в настройках в виду их детерминированности, нежели с программными разработками.

Допустим, кастомизация ведётся силами разработчиков. Современные корпоративные информационные системы, например, от компании SAP AG: ERP, SRM, SRM и другие, функционируют и претерпевают изменения из-за:

• внедрения «с нуля»;

• тиражирования;

• развития,

а проект их внедрения характеризуется функциональными:

• большим объёмом основных и переменных данных для целей миграции и последующего использования в SAP;

• единой интегрированной организационной структурой предприятия в SAP;

• заданным числом бизнес-процессов для отражения в SAP;

• большим массивом транспортных запросов и задач для переноса в SAP

и организационными особенностями:

• интеграцией SAP с внешними системами;

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

Внедрение подобных систем осуществляется преимущественно на основе каскадной модели в виду дороговизны, объёмности, сложности и продолжительности проекта. Проделаем следующее упражнение: выделим способы реализации КИС, а также виды проектов, далее для пары «способ-вид» попытаемся оценить целесообразность использования Agile Scrum (табл. 1). В качестве оценивания выберем шкалу от 1 до 3, где 1 – применение маловероятно, 2 – использование возможно, но требуется значительная трансформация команды, 3 – рекомендуется использовать Scrum.

Таблица 1. Целесообразность применения Agile Scrum в проектах SAP

Использование Agile Scrum для доработки SAP системы в процессе её развития может позволить достичь положительного эффекта. Стоит отметить, что разработка затрагивает лишь ограниченный функционал SAP-системы, сравнимый по объёму с модулем, например, закупки, сбыт, запасы и др. Применение Scrum диктует особые требования к организации и составу команды: теперь архитектурные решения должны приниматься доверительно и коллективно; разработка ведётся от требований, проектные решения, спецификации на разработку и прочая документация отсутствуют; каждый ежедневно отчитывается о результатах проделанной работы. Для использования гибкой методологии необходима трансформация проектной команды, первая попытка которой может закончиться неудачей. Преимущества Scrum будут ощутимы только при условии, что команда непрерывно работает над проектами, используя гибкую методологию Agile, а не от случая к случаю: применение Scrum требует преодоления инерции водопадной модели. Одно и тоже требование может быть одновременно неправильно трактовано и неверно реализовано, непрерывная демонстрация разрабатываемого решения владельцу продукта и конечным пользователям позволяет получить именно тот продукт, который ожидает и хочет увидеть пользователь. В этом заключается преимущество итерационной модели, к которой относится и Agile. Таким образом, целесообразность использования Agile Scrum в проектах развития SAP-систем за счёт их доработки видится оправданной, однако требует значительных изменений в мышлении, организации и понимании новых правил игры всей проектной команды (табл. 1, оценка целесообразности 2-3).

Обратимся к случаю кастомизации системы SAP в процессе её развития. Самый простой пример – внедрение ранее не использованного модуля, например, SAP ERP WM (Warehouse Management - управление складами). Подобные активности не требуют чрезмерных трудозатрат функционального консультанта. Давайте разберемся за счёт чего достигается положительный эффект применения Scrum в процессе доработки SAP. Программа может быть организована и запрограммирована огромным числом способов, гибкая модель разработки позволяет выбрать лишь тот, который удовлетворяет конечному пользователю. В случае настройки SAP-системы ситуация в корне иная: кастомизация решения весьма ограничена, а варианты настройки либо носят единичный характер, либо очень близки. Демонстрация промежуточного продукта пользователю кардинально не может изменить выбранного решения в виду его детерминированности. В итоге, конечный пользователь мало на что может повлиять, а сам метод Scrum обеспечивает лишь быструю доставку решения без какой-либо существенной обратной связи (табл. 1, оценка целесообразности 1-2).

И, наконец, полномасштабное внедрение SAP. Значительная часть проектов как тиражирования, так имплементации SAP «с нуля» требует доработки: кастомизация в большинстве своём не может покрыть всех требований бизнеса. Начнём с организационных сложностей: проект внедрения SAP требует вовлечения большого числа как разработчиков, так и консультантов. В зависимости от проекта количество членов команды может варьироваться от 5 до 37, что явно нарушает требования Scrum (согласно гибкой методологии команда должна состоять из 5-7 разработчиков). Практически каждый проект SAP включает интеграцию с внешними системами. Вне зависимости от содержания и качества реализации спринтов проектной командой SAP, велика зависимость от внешнего ресурса. Игнорирование плана проекта SAP, задерживание тестирования и выпуска продукта, не информирование о внесённых изменениях и прочие действия внешней стороны критически влияют на выполнение спринта и не могут быть устранены в рамках Scrum ...

Литературный источник

Степанов Д.Ю., Вельсовский А.В. Применение Agile Scrum в проектах SAP // Корпоративные информационные системы. – 2018. – №1. – C. 9-17. – URL: http://corpinfosys.ru/archive/issue-1/46-2018-1-scrum.