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

Agile — это прежде всего процесс, поэтому при внедрении методик быстрой разработки ИТ-служба переходит от проектно-процессной парадигмы к процессно-процессной, что, однако, противоречит одному из постулатов Agile Manifesto: люди и взаимодействие важнее процессов и инструментов. Тем не менее от реальности уйти нельзя — разработка по agile-методике представляет собой бесконечный процесс разработки ПО, не имеющий ни конечной цели, ни конечных сроков, ни фиксированного бюджета. Поэтому нельзя выделить точку, в которой разработанное с использованием agile-методик ПО может быть передано в эксплуатацию — оно всегда будет находиться в разработке, темп которой может как увеличиваться, так и уменьшаться, но конец может наступить только в случае смерти бизнеса. Однако задачи сопровождения никуда не исчезают — команды agile-разработчиков не создаются для решения задач поддержки, следовательно, необходимы все линии сопровождения, которые сегодня обеспечивают управление ИТ-сервисами (IT service management, ITSM) с практиками, описанными в ITIL [1]. Как совместить оба процессных подхода в одной ИТ-структуре?

Базовое различие между двумя подходами заключается в том, что ITSM создает единую среду для взаимодействия бизнеса и ИТ-службы, а при применении agile-методик формируется единая команда, стирающая границы между бизнесом и ИТ-структурой. Такая команда является самодостаточной, самоуправляемой и не требует строгой систематизации своей деятельности. Конечно, сами по себе обе методики ничего не гарантируют, но, если они применяются правильно, возникает вопрос: возможно ли организовать их совместное использование без потери эффективности каждой из методик? Скорее нет, но есть варианты.

Циклы работы по Scrum [2] и ITSM показаны на рисунке. Здесь возникают закономерные вопросы. Каким образом крайние сроки устранения дефекта могут попасть в бэклог (журнал) продукта или текущего спринта? Каким образом Scrum-команда может выдержать крайний срок по устранению дефекта, если спринт уже начался и объем работ пересмотру не подлежит? Как можно согласовать фиксированные сроки устранения дефектов в SLA, если журналом управляет владелец продукта (Product Owner) и приоритизация задач входит в его компетенцию?

 

Циклы работы Agile и ITSM
Циклы работы Agile и ITSM

 

По сути, в Scrum есть два способа работы с дефектами: либо включение в журнал и управление приоритетами и сроками через владельца продукта, либо понижение фокус-фактора (вовлечения в основную деятельность) Scrum-команды с выделением значительных ресурсов на устранение дефектов во время поддержки. Оба метода плохие, но каждый из них нехорош по-своему. Работа с дефектами через владельца продукта исключает возможность согласования фиксированных уровней обслуживания и определения жестких крайних сроков по устранению дефектов — управление сроками ведется по всему объему задач (включая доработки) в соответствии с текущими приоритетами, а фиксированные и гарантированные сроки устранения дефектов нарушают эту логику управления. Но, во-первых, отложить исправление текущего критического дефекта до следующего спринта может быть вообще невозможно. А во-вторых, интересы владельца продукта и пользователей продукта могут сильно расходиться, поскольку основная задача владельца продукта и Scrum-команды — это быстрое развитие функционала продукта, а не поддержка пользователей. Кому-то нужно закрыть и оплатить договор здесь и сейчас, так как клиент уже сидит в офисе, а кому-то необходимо через неделю запустить продажи нового продукта. Как расставить приоритеты — зависит от интересов того, кто этими приоритетами управляет, и от текущей ситуации. Таким образом, работа с дефектами через владельца продукта сильно затрудняет процессы поддержки. Понижение фокус-фактора Scrum-команды уменьшает эффективность разработки. Работа команды может оказаться и вовсе неэффективной, если она больше половины времени будет заниматься устранением дефектов, а владелец продукта будет ходить вокруг нетронутого бэклога и грустить — высокий темп разработки при постоянном прерывании на устранение дефектов набрать невозможно.

Если оба способа плохи, что же делать? Можно создать отдельную команду для тушения пожаров и устранения дефектов, но если есть избыток ресурсов, то тогда не стоит использовать Scrum. Как ни парадоксально, но в описанных противоречиях и заключается ответ на вопрос, как заставить работать Agile и ITSM вместе. Необходимо идти на компромиссы, понимая, что при этом ухудшаются и процесс разработки, и процесс поддержки.

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

Безусловно, нужно использовать одновременно agile-методики и ITSM/ITIL — ITSM гораздо шире, чем гибкие методики разработки ПО. И пусть идея ITSM по движению в направлении бесконечной атомизации процессов, скорее всего, не вполне корректна — логично было бы двигаться к универсализации, — тем не менее учитывать конфигурационные единицы по agile-методике нельзя и тут замены процессам ITSM нет.

При использовании agile-подхода многие процессы ITSM/ITIL будут сильно переформатированы, а некоторые и вовсе отпадут — например, процесс управления изменениями в части ПО можно смело выбросить, так как никто никогда не увидит согласованный запрос на изменение, а вместо него будет только желтая бумажка на стене в кабинете Scrum-команды. Соответственно, если в процессе управления изменениями и будет совет по изменениям (Change Advisory Board, CAB), то заниматься ему придется только стратегическими вопросами и вопросами управления Scrum-командами, что, безусловно, важно, но по сравнению с полным процессом в ITSM/ITIL это весьма немного. Управление релизами тоже не понадобится — успеть за спринтами в этом процессе вряд ли удастся, тем более что оценивать спринты два раза в разных процессах нет необходимости. Зато процесс управления уровнем обслуживания может заиграть новыми красками — в условиях работы Scrum-команды доступность и непрерывность сервиса фактически зависят не только от ИТ-службы, но и от владельца продукта. Сформулировать согласованный уровень обслуживания, а также уровни доступности и непрерывности самого сервиса и бизнес-функционала — это хорошая задача при заключении внутреннего соглашения об уровне обслуживания, который при переходе на гибкие методики разработки должен радикально поменять формат, смещая фокус внимания с метрик реактивной работы службы поддержки на метрики доступности и непрерывности сервиса.

***

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

Литература

  1. Заурбек Алехин. ITIL — основа концепции управления ИТ-службами // Открытые системы. СУБД. — 2001. — № 3. — С. 32–36. URL: http://www.osp.ru/os/2001/03/179975 (дата обращения 30.5.2015).
  2. Михаил Борисов. Scrum: гибкое управление разработкой // Открытые системы. СУБД. — 2007. — № 4. — С. 57–65. URL: http://www.osp.ru/os/2007/04/4220063 (дата обращения 29.5.2015).

Александр Огнивцев (shura@alfastrah.ru) — руководитель управления сервисной поддержки, страховая группа «АльфаСтрахование».