Когда эффективен и полезен Agile?

В 2001 году известные разработчики ИТ-систем собрались вместе, чтобы описать, как правильно создавать новые продукты в отрасли. Результатом этой встречи стал Agile Manifesto, текст которого был переведен на более чем 50 языков и получил глобальное распространение в ИТ-сфере. В нем сформулировано 4 базовых принципа и 12 правил работы по Agile, которые многие команды программистов взяли на вооружение.

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

Для методологов проектного управления Agile делится на:

• мindset, образ мышления — установки, парадигмы, взгляды человека, нацеленные на быструю реакцию;
• 4 базовых принципа и 12 правил — философская основа Agile.
• набор практик: что делать и как выстраивать работу, чтобы образ мышления и принципы манифеста естественно сочетались.

Именно в таких трех смыслах мы и будем далее говорить про Agile.

Agile для хайпа или для результата?

Любая новая и инновационная технология, метод или подход переживают различные стадии: от популярности и очарования, до бесполезности и забытья. И эта стадия влияет на то, как мы их воспринимаем. Компания Gartner, знаменитая своими исследованиями ИТ-рынка, описала эту динамику «Циклами хайпа» (Hype cycle). Эта модель выделяет пять стадий (рис. 1).

• Первая стадия: «Инновационный триггер или запуск технологии» – стадия запуска, когда потенциальная технология «прорывается в свет». Cначала никто не знает о новой технологии, но постепенно о ней начинают говорить — хайп начинает расти. С ростом популярности увеличивается рекламная шумиха и ажиотаж, хотя инновация еще не подтвердила свою коммерческую ценность.
• Вторая стадия: «Пик завышенных ожиданий» – стадия ажиотажа, когда новизна делает технологию предметом широкого обсуждения в обществе. Все узнают о технологии, ждут, что она решит актуальные проблемы. Повышенный интерес и чрезмерное внимание провоцируют появление иллюзий и ничем не мотивированных ожиданий.
• Третья стадия: «Пропасть разочарования» – стадия ослабевания интереса по мере того, как ожидания не сбываются, а инновация не приносит желаемых результатов. Выясняется, что она работает не всегда, не везде, не у всех. Обнаруживаются главные недостатки, слабые места и ограничения, и новой технологии или методу выносится «смертный приговор» как со стороны потребителей, так и со стороны СМИ.
• Четвертая стадия: «Склон просвещения» – стадия реабилитации новой технологии или метода, в рамках которой действительно актуальные технологии после некоторой адаптации находят применение. Набирается опыт, исправляются ошибки, корректируются инструменты и области применения, возникают новые задачи и решения, реализация которых дает больше преимуществ. На этой стадии приходит понимание, что новая технология или метод, где-то применим, а кое-где по-настоящему эффективен и результативен.
• Пятая стадия: «Плато продуктивности» – фаза поэтапного применения технологии на рынке, после того как она доказала свою состоятельность и экономическую выгоду. Общество воспринимает зрелую технологию как данность, объективно оценивая ее возможности, достоинства и ограничения.

Рис. 1. «Цикл хайпа» (Hype cycle) компании Gartner

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

Узнать это снаружи — нельзя. Информация закрыта. И, насколько нам известно, в Сбербанке оценка эффективности этого подхода не проводилась.

Зачем Agile Сбербанку? На наш взгляд, Сбербанк внедрял Agile, потому что руководство хотело позиционировать себя как инновационную, передовую ИТ-компанию, а не как традиционный и консервативный банк. Подняв флаг Agile, банк убедил многих, что стремительно двигается в сторону цифровизации и технологизации. Это флаг был нужен для бренда, а какова его результативность — это вопрос открытый.

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

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

Фреймворк Cynefin

Agile как система коммуникации и принцип производства продуктов эффективен, но в определенных границах.

Чтобы в этом разобраться, были придуманы разные подходы к описанию систем. Один из самых известных — фреймворк Cynefin («Киневин») Дейва Сноудена (Dave Snowden).

В 1998 году в IBM был создан Институт управления знаниями, который проводил исследования проблем создания и передачи знаний. Дэйв Сноуден работал в IBM и изучал процессы передачи знаний, пытаясь понять, за счет чего неформальные сети и поддерживающие их технологии, позволяют передавать неочевидные знания быстрее, чем формальные системы управления знаниями. В результате исследований процессов передачи знаний Сноуден пришел к созданию фреймворка, который выходит далеко за границы управления знаниями. Так, в 2000 году появился фремворк Cynefin, нацеленный уже на понимание и осмысление широкого спектра систем и ситуаций (об истории рождения фремворка Cynefin можно почитать в публикации Истоки и история рождения фреймворка Cynefin). Фремворк Киневин говорит о системах в широком смысле, как о наборе элементов и связей между ними. Касательно бизнеса проект — это система, подразделение — система, отдельная команда — тоже система. Отметим также, что важнейшей составляющей фреймворка Cynefin и его базой является теория сложных адаптивных систем или синергетика (об этом можно почитать на сайте Всложности).

Cynefin – это слово валлийского языка, которое не имеет прямого аналога ни на одном их европейских языков. Cynefin – это место, где возникли и «живут» наши многочисленные привязанности, а также ощущение, что у всех нас вместе и у каждого в отдельности есть множество привязанностей – культурных, религиозных, географических, этнических и т. д. Дейв Сноуден так комментирует название фреймворка (Snowden 2010): «Название фреймворка это напоминание, что любое человеческое взаимодействие подвергается сильному влиянию и зачастую определяется паттернами нашего предыдущего опыта – как личного, так и коллективного».

Мы не ставим целью всесторонний рассказ о фреймворке Cynefin (о нем можно прочитать на сайте Всложности), но напомним основные моменты. Фреймворк Cynefin делит все системы на четыре типа:

• ясные (clear) или очевидные (obvious);
• усложненные (complicated);
• сложные (complex);
• хаотичные (chaotic).

Это глубокое разделение систем проводится на основе природы системы и, прежде всего, нашего знания ее причинно-следственных связей (рис. 2).

Рис. 2. Причинно-следственные связи между элементами систем и типы систем во фреймворке Cynefin

1. Ясные и очевидные (иногда их называют простые) — это системы с понятными причинно-следственными связями между элементами. Например, табуретка на 4 ножках: отпилишь две ножки — и табуретка не сможет стоять и упадет. Все ясно и понятно.
2. Усложненные (иногда их называют упорядоченные сложные) — это системы, где причинно-следственные связи не всегда понятны и надо потратить время, чтобы разобраться самому в системе, или привлечь эксперта, который объяснит, как все это работает. Например, автомобиль, вряд ли все читатели детально развираются в своих автомобилях, за нас с вами это делают профессиональные автомеханики. Или самолет, в котором более миллиона деталей, но, несомненно, есть эксперты, которые в них разбираются.
3. Сложные (иногда их называют запутанные) — это системы, в которых причинно-следственные связи запутаны и сейчас нам непонятны. Например, лягушка. Когда ее тыкают палочкой, у нее дергается лапка. Непонятно, от чего, и наука до сих пор разбирается с деталями и особенностями функционирования ее нервной системы. Когда разберется, появятся эксперты по лягушкам, и эта система перейдет в класс усложненных систем.
4. Хаотические — это системы, в которых все настолько непонятно и размыто, что говорить о причинно-следственных связях крайне сложно, все смешалось и не удается выделить причины и следствия из них. Да еще, к тому же, система динамично изменяется.

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

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

1. Ясные и очевидные системы — мы понимаем и знаем поведение системы, оно полностью предсказуемо.
2. Усложненные системы — поведение системы понятно не всем, а только опытным экспертам, которые и могут его спрогнозировать. Прогнозирование (экспертное) возможно, на короткий, средний и дальний горизонты хотя, возможно, с некоторыми вариациями и сценариями.
3. Сложные системы — мы не понимаем поведение системы, существующих знаний недостаточно. На длинный срок прогнозирование невозможно, но возможно на короткий. Однако время у нас есть, и мы можем исследовать повторяющиеся паттерны поведения.
4. Хаотические системы — мы не понимаем поведение системы, существующих знаний недостаточно. И исследовать систему мы не можем, из-за ее высокой динамики, невозможно исследовать то, что постоянно изменяется. Такая система принципиально непредсказуема.

Рис. 3. Возможности прогнозирования изменения различных типов систем во фреймворке Cynefin

Область ограниченной сложности

Отметим важную вещь, это лишь основные домены. В 2017 году появилась версия фреймворка Cynefin, которая кроме пяти основных доменов включает еще два пограничных (подробнее о ней читайте в статье Пограничная (liminal) версия фреймворка Cynefin).

Вблизи границы между усложненными и сложными системами существует пограничное состояние (рис .4). Это система, в которой мы не знаем, как правильно действовать, не получается найти правильный путь решения проблемы, наших знаний о системе для этого не хватает – то есть это уже не усложненная система. С другой стороны, ситуация не столь уж непонятна, как в сложной, есть набор возможных гипотез, либо вообще одна гипотеза, но требующая подтверждения.

Рис. 4. Область ограниченной сложности во фреймворке Cynefin

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

***

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

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