М. Шантаренкова, К. Зимин

Мария Шантаренкова. Редактор, специалист в области PR. Работала менеджером по маркетингу и PR компании ALP Group. С 2003 по 2014 г. была выпускающим редактором журнала Intelligent Enterprise. Константин Зимин, главный редактор журнала «Управляем предприятием»

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

Как Agile потерял свое «сердце»

То, что сегодня называют Agile, часто мало похоже на ту идеологию, которую отцы-основатели закладывали в 2001 году. 17 представителей различных концепций разработки программного обеспечения встретились на горнолыжном курорте и это кажется символичным – дух свободы, творчества и гибкости в буквальном смысле «носился» над ними. Agile начинался с энергии новаторов, готовых осваивать неизведанное. Тогда всё, от XP (Extreme Programming), до Scrum, было наполнено творчеством и готовностью к экспериментам.

Надо отметить, что отчасти Agile систематизировал проверенные временем методы. Например, итеративный подход в проектах — сам по себе не новость. В 1990-е годы компании, занимаясь внедрением программных решений, не знали о Agile и Scrum, но использовали здравый смысл: маленькие постоянные итерации позволяли разгружать команду и успокаивать клиентов. Без итераций клиентов было бы невозможно удержать — они звонили каждые пять минут с новыми требованиями и ожиданиями. Удобство итеративной работы в том, что она ограничивает хаос в головах заказчиков. Постепенно такой подход получил официальное оформление, и сегодня мы знаем его как один из ключевых принципов Agile.

Однако сегодня Agile постепенно становится коммодити, когда особенное становится обыденным и общедоступным. Сегодня Agile как направление в менеджменте больше напоминает разношерстный винегрет из подходов, фреймворков и методов, которые сражаются за влияние на рынке. Наиболее популярные методы Agile – это Scrum и Kanban, кроме того, существуют фреймворки для масштабирования Agile, такие как SAFe и LeSS. Следствия коммодитизации:

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

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

Чем больше структуры и упорядоченности – тем меньше свободы и гибкости. Чем больше универсальности – тем меньше творчества. Так Agile потерял свое «сердце».

Именно тут, по мнению ряда экспертов (среди которых Дейв Сноуден, который стоял у истоков одного из ключевых методов разработки программного обеспечения — DSDM (Dynamic Systems Development Method) — и был членом команды, которая формировала повестку встречи на горнолыжном курорте), Agile и потерял свой изначальный дух свободы и новаторства. Современные проблемы Agile — это не сбои в процессах, это болезни роста и масштабирования.

Scrum: фреймворк, который убил «дух» Agile

Agile взлетел за счет своей способности быстро адаптироваться к изменениям, но ключевую роль в становлении современного Agile сыграл Scrum. Почему именно он?

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

Именно усилиями Джеффа Сазерленда и его последователей была создана привычная нам всем бизнес-модель обучения и сертификации. На первый взгляд, это казалось блестящей идеей: создать стандартизированную систему, обучать ей, защитить ее через сертификацию, добавить яркий логотип и продать как универсальный инструмент.

И это сработало — Scrum стал своего рода лицом Agile. Но какой ценой?

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

На современном этапе мы видим, что рынок Agile движим коммерцией, а знание чаще всего продается в красивой упаковке. Scrum удалось монополизировать этот процесс благодаря своей простоте и способности быстро адаптироваться под конкретные цели бизнес-школ и корпораций. Но об этом ли был написан манифест Agile? Давайте вспомним его главные ценности:

  • люди и взаимодействие важнее процессов и инструментов;
  • сотрудничество с заказчиком важнее согласования условий контракта;
  • готовность к изменениям важнее следования первоначальному плану.

Да, конечно, отчасти сообщество практиков Scrum сохраняет эти ключевые ценности, но, по мере роста популярности, все меньше и меньше.

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

Extreme Programming: забытый «дух» Agile

Если мы задумаемся, каким Agile должен был быть исходя из идей его основателей, то ответ лежит гораздо ближе к истокам – это Extreme Programming. Это направление идеально отражало «дух» Agile. Но вот проблема. Extreme Programming оказался слишком сложным для восприятия более широкой аудиторией, его идеи были излишне техничными, а язык, на котором говорили его адепты, — чрезмерно айтишным. Они пытались достучаться до более широкой аудитории, но так и не смогли «перевести» свои идеи для простых смертных. Главная проблема Extreme Programming — именно в недоступной коммуникации.

Блеск инновационной мысли моментально теряется, если язык её подачи сродни лекции по квантовой физике.

Extreme Programming не могло соревноваться со Scrum: его принципы остались слишком неформализованными, и достаточно неопределенными. Extreme Programming остался «ручной работой» мастера.

Когда Agile возможен? Цена ошибки

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

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

Вы не можете «поэкспериментировать» с фундаментом здания так же, как с программным кодом. Итерации обойдутся вам слишком дорого.

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

Простой критерий для выбора между Agile и другими подходами — стоимость ошибки или переделки.

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

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

Границы применимости Agile: балансирование между простотой и сложностью

Agile не универсальный инструмент для всего. Поэтому встает вопрос, для каких ситуаций в жизни компании Agile подходит лучше всего? Очень удобно показать это с помощью фреймворка Cynefin, который помогает структурировать практики и методы работы в зависимости от природы проблемы или ситуации в бизнесе. Мы подробно писали про это в статье «Agile и неопределенность. Часть 2. Когда нужен Agile, а когда лучше не надо?». Здесь уместно повторить основные выводы (см. рис.).

В упорядоченных доменах – ясный/очевидный и усложненный, где взаимосвязь между причиной и следствием очевидна, традиционные подходы, такие как водопад или PRINCE2, остаются вполне эффективными.

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

Управлять в неопределенность часть 9.png

Рис. Действия во фреймворке Cynefin, в том числе и в области ограниченной сложности

Пограничная область ограниченной между сложным и усложненным доменами— именно здесь Agile показывает свои сильные стороны.

Scrum или Kanban, позволяют работать с аморфными идеями и гипотезами через быстрые итеративные циклы. Это позволяет довести недооформленную идею до конкретности и обоснованности, создавая предсказуемость результата.

Почему Agile не годится для работы в сложной ситуации (см. рис.)? Ведь там, на первый взгляд, все очень похоже. Как это ни странно звучит, но гибкие методологии оказываются недостаточно гибкими для работы в сложной системе. Мы подробно писали про это в статье «Agile и неопределенность. Часть 2. Когда нужен Agile, а когда лучше не надо?». Методы и инструменты Agile опираются на убеждение, что мы можем двигаться к желаемой цели последовательными итерациями. В сложной системе мы вынуждены прибегать к параллельному исследованию сразу нескольких гипотез и идей, пробовать сразу несколько возможных путей. Именно таким образом движется наука, и в сложной системе надо использовать такие исследовательские методы.

Как найти тот самый баланс — между изначальным хаосом креативного мышления и жесткой структурой фреймворков, которые чаще вредят, чем полезны? Этот вопрос пока остается открытым.

Подлинный Agile — как игра на музыкальном инструменте: только глубокое понимание структуры и чувство такта позволяют создать гармонию не потеряв творчество.

***

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

 


Комментарии 0

Чтобы оставить комментарий пожалуйста Авторизуйтесь

© «УПРАВЛЯЕМ ПРЕДПРИЯТИЕМ»
Все права защищены. Все торговые марки являются собственностью их правообладателей.