Scrum и Agile

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

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

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

Эволюция идей

Scrum как подход к реализации проектов с помощью небольших эффективных команд, составленных из специалистов различного профиля, впервые был упомянут в 1986 году в статье И. Нонака и Х. Такэути. В 1991 году на подход сослались в своей книге Де Грейс и Шталь, взяв в качестве иллюстративного образа фигуру, которую образуют регбисты во время матча – скрам («схватка»).

После этого на Scrum пристальное внимание обратил Кен Швабер, занимающийся разработкой программного обеспечения (ПО), который вместе с соавтором Джеффом Сазерлендом за несколько лет доработали идею до формата модели управления со своими философией, порядком проведения операций, ролями, ритуалами. Эту модель с рядом методологических наработок принято теперь называть методом Scrum, хотя сторонники классических определений избегают называть Scrum методологией или методом, предпочитая определения «фреймворк» или «структура».

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

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

Несмотря на то что для некоторых производств каскадный подход остаётся единственно возможным, подвижная и «гибкая» сфера разработки ПО с лёгкостью восприняла новые идеи, а компании, которые поставили эти идеи во главе угла, стали опережать конкурентов.

Результат эволюции

В основе идеи Agile лежал отказ от долгосрочного планирования в пользу динамичного формирования задач и возможности вносить изменения в любой момент, как только того потребует рынок в лице конечных потребителей или заказчиков продукта. Идея «гибкого» менеджмента на рубеже 20-21 веков стала настолько актуальной и востребованной, что пришло время оформить её в виде свода ценностей и принципов. А поскольку к 2001 году, помимо Scrum, существовало несколько трендовых моделей, у которых базовые установки в подходе совпадали, то представители этих трендов собрались в одном месте (на горнолыжном курорте в Юте) и выпустили Манифест Agile.

Подход Agile был актуален, в первую очередь, для быстро развивающейся IT-индустрии, поэтому для подписания Манифеста собрались именно разработчики ПО (в том числе – Кен Швабер и Джефф Сазерленд). Но и сама идеология Agile, и различные модели управления, которые были выстроены с учётом общих требований рынка, нашли своих последователей в самых разных областях бизнеса и в некоммерческих сферах.

Возникла ситуация, когда в компаниях и вне IT-отрасли выросла потребность в выстраивании новой системы отношений, а чёткой схемы для внедрения её у себя в отрасли не было. Точнее, был целый ряд схем и моделей, аналогичных Scrum, но все эти модели создавались разработчиками ПО под свою деятельность. Такие схемы потенциально можно было адаптировать под другой бизнес, но адаптация не всегда сохраняла весь набор инструментов, который присутствовал в исходной модели. А при отказе от какого-то ключевого элемента модели, зачастую переставала работать вся схема – разрушалась тонкая система настроек. В итоге, далеко не в любой бизнес можно было внедрить, например, модель Scrum и не везде её внедрение было целесообразным.

Решалась проблема двумя способами:

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

Таким образом, с определёнными оговорками, можно говорить об Agile-модели управления проектами, которая «взяла», в том числе, и некоторые структурные наработки Scrum-модели.

Scrum и Agile: цели и практические решения

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

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

Подобная логика приводит к созданию универсальной Agile-модели со следующими характеристиками:

1. Вся работа над проектом разделяется на короткие этапы – итерации (в Scrum, например, такие этапы называются «спринтами»). За время одной итерации нужно успеть выпустить продукт, который можно тестировать и получать отклики от потребителей (технический модуль, приложение, локальную услугу – например, востребованность кофемашины в булочной и т. д.).
2. Любые замечания или требования рынка фиксируются и входят в список требований на следующую итерацию. То есть, план составляется по ходу создания продукта. Подобные этапы цикличны и возобновляются до тех пор, пока не исчерпается список требований.
3. Чтобы было удобно фиксировать требования рынка они, как правило, приводятся к единому формату (в Scrum – это «пользовательские истории») и размещаются на информационных площадках (досках).
4. Чем эффективнее и достовернее каналы связи с потребителями, тем выше вероятность получения исчерпывающей информации. Множественные эксперименты дают более злободневные данные о продукте и о клиенте. Причём, каждая значимая поправка добавляет полезность, а, значит, и ценность конечному продукту. (За поддержание такой связи с заказчиком и создание ценности в Scrum отвечает специальный «персонаж» – т. н. «Владелец проекта»). А ориентированность на клиента – это ключевая ценность философии Agile.

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