Как определить, что вашему проекту нужен Agile?

Всем привет!

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

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

Эту модель разработал Дейв Сноуден (Dave Snowden) – исследователь и консультант по управлению знаниями из Уэльса. Эта модель создавалась для принятия решений при помощи определения контекста проекта. Основная мысль модели в том, что, действуя в разных системах, мы должны вести себя по-разному.

Киневин выделяет 5 типов систем: Простые (Simple), Сложные (Complicated), Запутанные (Complex), Хаотические (Chaotic) и Беспорядочные (Disorder).

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

В Сложных системах взаимосвязей больше, а их выявление требует знаний и дополнительного анализа. В этой области не существует одной единственной «лучшей практики», есть множество «хороших практик». Так, два дизайнера по одному ТЗ сделают разные макеты сайта, и будет сложно объективно определить, какой из них лучше. Продукт в таких системах понятен и поддается описанию в виде требований, есть понимание технологии его создания, содержание работ такого проекта поддается описанию и декомпозиции. Сложные системы – «место обитания» экспертов. В общем виде в Сложной области действовать нужно так: «Ощути – Анализируй – Реагируй». Примером проектов в этом домене могут быть создание медицинского центра, внедрение ERP-системы, реконструкция производственной линии.

Примером Запутанной системы может служить биржа или транспортная система крупного мегаполиса: огромное количество взаимосвязей, одни и те же действия часто приводят к совершенно разным последствиям. В таких системах сложно полагаться как на историческую информацию, так и на отдельные наблюдаемые со стороны факты. В таком случае нам необходимо самим изобрести практики достижения результатов. Для этого мы действуем по алгоритму «Исследуй – Ощути – Реагируй». Мы выдвигаем гипотезу, проверяем ее, смотрим на результаты и вносим изменения в нашу картину мира. Мы повторяем этот процесс до тех пор, пока не достигнем необходимого результата или пока не станет понятно, что дальнейшая реализация проекта нецелесообразна. Кстати, несколько гипотез можно проверять одновременно. В качестве примера этого домена могут быть проекты разработки нового мобильного приложения, выход на новый зарубежный рынок или создание законопроекта в области искусственного интеллекта.

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

И наконец, Беспорядок. Беспорядочные системы невозможно отнести к одной из вышеописанных категорий. Как правило, Беспорядочными считаются системы, которые состоят из нескольких подсистем, относящихся к разным категориям. Цель действий в этом домене – выявить эти самые подсистемы, отнести их к одной из категорий и действовать соответственно.

Но вернемся к проектному управлению. Классический или «водопадный» подход предполагает построение подробного плана проекта на весь период его жизненного цикла. Мы планируем сроки, стоимость, содержание и качество. А для этого необходимо знать причинно-следственные связи в цепочке работ проекта и взаимосвязи между участниками. По всем этим критериям классическое проектное управление наиболее подходит для работы в Сложных системах: при строительстве дорог, зданий, запуске производства промышленного оборудования.И наконец, Беспорядок. Беспорядочные системы невозможно отнести к одной из вышеописанных категорий. Как правило, Беспорядочными считаются системы, которые состоят из нескольких подсистем, относящихся к разным категориям. Цель действий в этом домене – выявить эти самые подсистемы, отнести их к одной из категорий и действовать соответственно.

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

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

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

Тогда приходите к нам на тренинг Agile Certified Professional и научитесь правильно применять Scrum и Kanban на практике, чтобы сделать рывок в карьере или бизнесе!