Как Agile потерял свое «сердце»
То, что сегодня называют Agile, часто мало похоже на ту идеологию, которую отцы-основатели закладывали в 2001 году. 17 представителей различных концепций разработки программного обеспечения встретились на горнолыжном курорте и это кажется символичным – дух свободы, творчества и гибкости в буквальном смысле «носился» над ними. Agile начинался с энергии новаторов, готовых осваивать неизведанное. Тогда всё, от XP (Extreme Programming), до Scrum, было наполнено творчеством и готовностью к экспериментам.
Надо отметить, что отчасти Agile систематизировал проверенные временем методы. Например, итеративный подход в проектах — сам по себе не новость. В 1990-е годы компании, занимаясь внедрением программных решений, не знали о Agile и Scrum, но использовали здравый смысл: маленькие постоянные итерации позволяли разгружать команду и успокаивать клиентов. Без итераций клиентов было бы невозможно удержать — они звонили каждые пять минут с новыми требованиями и ожиданиями. Удобство итеративной работы в том, что она ограничивает хаос в головах заказчиков. Постепенно такой подход получил официальное оформление, и сегодня мы знаем его как один из ключевых принципов Agile.
Однако сегодня Agile постепенно становится коммодити, когда особенное становится обыденным и общедоступным. Сегодня Agile как направление в менеджменте больше напоминает разношерстный винегрет из подходов, фреймворков и методов, которые сражаются за влияние на рынке. Наиболее популярные методы Agile – это Scrum и Kanban, кроме того, существуют фреймворки для масштабирования Agile, такие как SAFe и LeSS. Следствия коммодитизации:
- методы стали слишком структурированными, часто перенасыщенными ритуалами и шаблонами, теряя первоначальный дух экспериментов;
- каждый метод и подход упакован в особый бренд, поддерживается обучением, защищается сертификацией и готов предложить универсальные решения;
- возникли не просто столкновения мнений, а настоящие «религиозные войны», где каждая сторона убеждена в превосходстве своей методики.
Все это привносит структуру и упорядоченность, к которым многие из нас подсознательно стремятся, но не кажется ли вам, что именно здесь Agile начал терять свой первоначальный смысл.
Именно тут, по мнению ряда экспертов (среди которых Дейв Сноуден, который стоял у истоков одного из ключевых методов разработки программного обеспечения — DSDM (Dynamic Systems Development Method) — и был членом команды, которая формировала повестку встречи на горнолыжном курорте), Agile и потерял свой изначальный дух свободы и новаторства. Современные проблемы Agile — это не сбои в процессах, это болезни роста и масштабирования.
Scrum: фреймворк, который убил «дух» Agile
Agile взлетел за счет своей способности быстро адаптироваться к изменениям, но ключевую роль в становлении современного Agile сыграл Scrum. Почему именно он?
Именно усилиями Джеффа Сазерленда и его последователей была создана привычная нам всем бизнес-модель обучения и сертификации. На первый взгляд, это казалось блестящей идеей: создать стандартизированную систему, обучать ей, защитить ее через сертификацию, добавить яркий логотип и продать как универсальный инструмент.
Большая часть изначальной гибкости и ценностей резко исчезли. Менеджеры начинают ассоциировать 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 подходит лучше всего? Очень удобно показать это с помощью фреймворка Cynefin, который помогает структурировать практики и методы работы в зависимости от природы проблемы или ситуации в бизнесе. Мы подробно писали про это в статье «Agile и неопределенность. Часть 2. Когда нужен Agile, а когда лучше не надо?». Здесь уместно повторить основные выводы (см. рис.).
Например, в больших инфраструктурных проектах, где конечные цели ясны и четко определены, Agile, как правило, неуместен. Дейв Сноуден приводит такой пример: команда австралийских инженеров, работающая над инфраструктурными проектами связи, пыталась использовать Agile лишь потому, что это "модно". В итоге, они разбили свои работы на спринты длительностью 1 год. Это звучит как идиотизм, но это правда.
Рис. Действия во фреймворке Cynefin, в том числе и в области ограниченной сложности
Scrum или Kanban, позволяют работать с аморфными идеями и гипотезами через быстрые итеративные циклы. Это позволяет довести недооформленную идею до конкретности и обоснованности, создавая предсказуемость результата.
Почему Agile не годится для работы в сложной ситуации (см. рис.)? Ведь там, на первый взгляд, все очень похоже. Как это ни странно звучит, но гибкие методологии оказываются недостаточно гибкими для работы в сложной системе. Мы подробно писали про это в статье «Agile и неопределенность. Часть 2. Когда нужен Agile, а когда лучше не надо?». Методы и инструменты Agile опираются на убеждение, что мы можем двигаться к желаемой цели последовательными итерациями. В сложной системе мы вынуждены прибегать к параллельному исследованию сразу нескольких гипотез и идей, пробовать сразу несколько возможных путей. Именно таким образом движется наука, и в сложной системе надо использовать такие исследовательские методы.
Как найти тот самый баланс — между изначальным хаосом креативного мышления и жесткой структурой фреймворков, которые чаще вредят, чем полезны? Этот вопрос пока остается открытым.
***
Agile, каким он должен был быть, — это не набор рецептов на все случаи жизни. Это умение «читать» динамику команды, чувствовать ритм людей, учиться управлять хаосом. Как только вы начинаете относиться к Agile, как к формальному процессу, он теряет свою ценность. Возврат к истокам Agile — это не слепое следование «религиозным канонам», а осознанное использование гибкости, экспериментов и здравого смысла.
Чтобы оставить комментарий пожалуйста Авторизуйтесь