Найти тему

Подходит ли SCRUM для внедрения комплексных систем, таких как 1С:ERP?

Юлий Минькин, руководитель проектного офиса

Методология SCRUM была впервые представлена в 1995 году, а сегодня уже широко применяется во многих компаниях по всему миру, в том числе и в России. Ее популярность можно объяснить двумя факторами:

  1. Доступность информационных материалов по этой технологии. Существует большое количество книг и статей, посвященных методологии SCRUM. Некоторые из них написаны ее создателями, а другие - опытными практиками, которые успешно применяют эту методологию в своей работе.
  2. Эффективность и гибкость. Одним из главных преимуществ SCRUM является то, что она способствует улучшению производительности и качества работы команды, что в свою очередь повышает эффективность проекта в целом. Кроме того, она может быть легко адаптирована к различным проектам и условиям. Это позволяет компаниям быстро реагировать на изменения внешней среды и требованиям рынка.

Но так ли универсальна эта технология и как ее можно применять при внедрении сложных и комплексных автоматизированных систем?

Рассмотрим для начала такие понятия, как “каденция поставок проекта” и “инкремент” применительно к методологии SCRUM.

Каденция поставок означает сроки и частоту применительно к поставляемым результатам проекта (PMBOK®).

Каденция поставок (Delivery cadence) - это периодичность (ритмичность) выпуска новых версий или функциональности продукта в рамках проекта. В методологии SCRUM каденция поставок является одним из ключевых элементов, который определяет ритм работы команды и обеспечивает прогресс проекта, обычно составляет от 1 до 4 недель.

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

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

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

Теперь взглянем на статистику фирмы 1С по срокам поставок для проектов внедрения 1С:ERP (рис.1).

Рис. 1. Средние сроки внедрения 1С:ERP (из доклада фирмы 1С на бизнес-форуме 1С:ERP 11 октября 2019 г.)
Рис. 1. Средние сроки внедрения 1С:ERP (из доклада фирмы 1С на бизнес-форуме 1С:ERP 11 октября 2019 г.)

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

Конечно, есть и исключения, по данным все той же фирмы 1С, запустить 1С:ERP можно в течение 1,5-2 месяцев (рис.2).

Рис.2 Проекты с коротким сроком внедрения 1С:ERP (из доклада фирмы 1С, бизнес-форум 1С:ERP 28 октября 2022 г.)
Рис.2 Проекты с коротким сроком внедрения 1С:ERP (из доклада фирмы 1С, бизнес-форум 1С:ERP 28 октября 2022 г.)

Специалисты, занимающиеся внедрением 1С:ERP, хорошо понимают, что проект по запуску такого сложного решения занимает значительно больше времени. А ввод в действие системы через 1,5 месяца после начала проекта, скорее всего, связан с очень ограниченным функционалом, небольшой численностью пользователей, их слабым уровнем подготовки и отсутствием полноценной технической и пользовательской документации.

Таким образом, можно утверждать, что рекомендованная длительность спринта в методологии SCRUM, равной 1-4 неделям, как правило, недостаточна для поставки работающей системы или ее части.

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

Для этих случаев, целесообразно применять более "приспособленные" проектные технологии, такие как:

  • Rational Unified Process (RUP) - это система процессов разработки программного обеспечения, созданная компанией Rational Software Corporation, которая в настоящее время является частью IBM. RUP является итеративным и инкрементальным подходом по своей природе.
  • DSDM (Dynamic Systems Development Method) – это методология разработки программного обеспечения, которая была создана в 1990-х годах в Великобритании. DSDM основывается на принципе "быстрой разработки приложений" (Rapid Application Development, RAD). Одним из ключевых принципов DSDM является инкрементальный подход, который позволяет быстро разрабатывать ПО, постепенно добавляя новые функции и улучшения на протяжении нескольких итераций.
  • Waterfall - это последовательная методология разработки программного обеспечения, которая используется с 1970-х годов. Она получила свое название из-за своей линейной структуры, где каждый этап проекта выполняется по порядку, а их завершение передает задание на следующий этап. Этот процесс, как водопад, течет от одного этапа к другому, не возвращаясь к предыдущему шагу.

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

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

  • Product Owner (владелец продукта)- это роль, которая представляет заказчика и управляет продуктом в целом. Владелец продукта определяет требования к продукту, планирует работу команды разработчиков и управляет бэклогом продукта.
  • Scrum Master - это роль, которая обеспечивает эффективную работу команды разработчиков и поддерживает соблюдение методологии SCRUM. Scrum Master помогает команде разработчиков в решении проблем и координирует работу.
  • Development team (команда разработчиков) - это роль, которая отвечает за непосредственное создание продукта. Команда разработчиков должна быть автономной и самоорганизующейся, обладать необходимыми навыками и знаниями, чтобы реализовывать требования к продукту.

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

  • Stakeholder (заинтересованная сторона) - это роль группы пользователей, которые могут быть заинтересованы в продукте. Stakeholder может вносить предложения и требования по развитию продукта.
  • SME (Subject Matter Expert) - это роль эксперта в определенной области знаний, которые могут быть связаны с продуктом. SME может помочь команде разработчиков в решении проблем, связанных с его областью экспертизы.

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

Кроме того, в технологии SCRUM никак не раскрывается собственно методика итераций, таких как проектирование, разработка, тестирование и пр. А для запуска комплексных автоматизированных систем методика их создания имеет существенное значение.

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

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