Применение Agile Scrum в проектах SAP

Подробности

Опубликовано: 31.03.2018 10:29

Автор: Степанов Д.Ю., Вельсовский А.В.

Просмотров: 18059

Аннотация: работа содержит описание метода Agile Scrum в проектах внедрения корпоративных информационных систем на базе SAP. Рассматриваются вопросы применения Scrum в проектах развития, тиражирования и внедрения «с нуля» решений SAP, а также использования гибкой методологии Agile для разработки и кастомизации информационных систем. Сделан вывод о целесообразности применения метода Scrum в проектах развития SAP-систем путём доработки. 
Скачать: PDF (статья), PDF (выпуск №1)
Ключевые слова: Agile SAP, Agile разработки для SAP, Agile Scrum SAP, гибкая методология разработки Agile, гибкая методология разработки Scrum, гибкая методология разработки программного обеспечения, Agile принципы, Agile методология Scrum, Agile манифест, Agile при внедрении SAP.

Пожалуй, нет более популярной темы для обсуждения, чем применение 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 изначально былa ориентирована на разработку, но не на кастомизацию ПО, именно поэтому под 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.

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

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

Таблица 2. Особенности проекта SAP с точки зрения Scrum

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

Вернёмся ещё раз к каскадной модели внедрения SAP. Возьмём манифест Agile (рис.1) и попытаемся понять, насколько он покрывается водопадной моделью. Получим следующие результаты:

• принципы совместной работы команды и минимизации лишней работы отражены в модели водопад за счёт вовлечения ключевых пользователей и выполнении только включённых в объём проекта работ;
• принципы общения лицом к лицу и внимания к качеству находят частичное покрытие в каскадной схеме внедрения КИС;все прочие принципы и ценности Agile не релевантны в каскадной модели.

Разберёмся, почему в модели Waterfall применяется так мало принципов Agile. Возможно от того, что в каскадной схеме внедрения КИС акцент сделан на иные сущности. Проведём анализ типовых рисков проекта, идентифицированных Б. Бэмом при усовершенствовании итерационной и создании спиралевидной модели [3]. Сгруппировав риски, выделим проблемные области имплементации КИС:

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

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

При имплементации масштабных SAP решений, когда объём проекта понятен даже при отсутствии детализированных требований, технические неточности устраняются на этапах системного, интеграционного и приёмочного тестирований. Agile Scrum существенных преимуществ здесь дать не может, так же как и в случае, когда затраты на реорганизацию команды и следование Scrum значительно превосходят цикл разработки программного решения. Резюмируя вышесказанное, хочется отметить, что метод Scrum как разновидность итерационной модели ориентирован в большей степени на пользователей и разработчиков, в то время как каскадная схема – на руководителей проектов.

 Литература

1. Larman C., Basili V.R. Iterative and Incremental Development: A Brief History // Computer. - 2003. – Vol.36, №6. – P.47-56.
2. Основополагающие принципы Agile-манифеста [Электронный ресурс] // Agile Alliance – Режим доступа: http://agilemanifesto.org/iso/ru/principles.html (дата обращения 10.01.2018)
3. Гудков Е.А., Деревнина А.М., Катасонова Н.С. Анализ каскадной, итерационной      и спиралевидной моделей внедрения корпоративных информационных систем       // Корпоративные информационные системы. – 2018. – №1. – C. 16-27. – URL: http://corpinfosys.ru/archive/issue-1/48-2018-1-models
4. Стеллман Э., Грин Д. Постигая Agile. Ценности, принципы, методологии. – М.: Манн, Иванов и Фербер, 2018. – 448 c.
5. Применение SCRUM-подходов в проектах SAP [Электронный ресурс] //  SapLand – Режим доступа: https://sapland.ru/courses/for-order/primenenie-scrum-podhodov-v-proektah-sap.html (дата обращения 10.01.2018)

Выходные данные статьи

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

Об авторах

Степанов Дмитрий Юрьевич – кандидат технических наук, доцент МИРЭА, принимал участие более чем в 10 проектах внедрения корпоративных информационных систем на базе SAP, Microsoft и Sage. Специализируется на управлении материальными потоками, сбытом и системой документов. Автор более 25 статей, в том числе публикации в журналах «Логистика сегодня», «Вопросы экономических наук», «САПер» и др. Электронный почта: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.

Вельсовский Андрей Вельтерович – руководитель группы разработки корпоративных информационных систем. Специализируется на среде программирования ABAP. Имеет более чем 15-летний опыт работы с решениями компании SAP, участвовал в многочисленных проектах по значительной доработке информационных систем. Владеет знаниями специфики нефтяной, металлургической и газовой отраслей. Электронная почта: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра.

Статьи выпуска №1 

1. Обзор открытой корпоративной информационной системы Odoo;
2. Применение Agile Scrum в проектах SAP;
3. Анализ каскадной, итерационной и спиралевидной моделей внедрения систем;
4. Особенности проекта внедрения MRP по точке перезаказа;
5. Сложности внедрения WMS-систем на примере SAP ERP.