Процессный компромисс

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

Различия между Agile и ITSM

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

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

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

"Базовое различие между ITSM и Agile заключается в том, что ITSM создает единую среду для взаимодействия бизнеса и ИТ-службы, а при применении Agile-методик формируется единая команда, которая стирает границы между бизнесом и ИТ-структурой, является самодостаточной, самоуправляемой и не требует строгой систематизации своей деятельности"

На рисунке показаны циклы работы по Agile-методике Scrum и по ITSM (для разъяснения терминов см. врезку).

Рисунок. Циклы работы Agile и ITSM

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

Путь к компромиссу

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

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

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

Если оба способа плохи, что же делать? Можно создать отдельную команду для тушения пожаров и устранения дефектов. Но если есть избыточное количество ресурсов, то проще завалить разработку ресурсами и вести спринты (или водопады) большим количеством команд с низким темпом. Это безусловно повысит качество, но тогда не стоит использовать Scrum, основная особенность которого — быстрый темп разработки, а не работа в режиме «фабрики по утилизации ресурсов». 

"В описанных противоречиях и заключается ответ на вопрос, как заставить работать Agile и ITSM вместе. Необходимо идти на компромиссы и при этом понимать, что любой из компромиссов ухудшает и процесс разработки, и процесс поддержки"

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

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

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

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

Последствия компромисса

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

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

"Путь совместного использования Agile-методик и ITSM – это путь компромиссов и ухудшения «чистых» вариантов и Agile, и ITSM"

Зато процесс управления уровнем сервиса может заиграть новыми красками, так как в условиях работы Scrum-команды доступность и непрерывность сервиса фактически зависят и от владельца продукта, а не только от ИТ-службы. Сформулировать согласованный уровень сервиса, а также уровни доступности и непрерывности самого сервиса и бизнес-функционала – это хорошая задача при заключении внутреннего SLA, который при переходе на гибкие методики разработки должен радикально менять формат, смещая фокус внимания с метрик реактивной работы службы поддержки на метрики доступности и непрерывности сервиса.

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

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