Эта статья подготовлена для блогов журнала PCWeek.
Теория запутанности (сложности), предложенная Дейвом Сноудоном в начале двадцать первого века, несмотря на свою молодость, уже нашла применение в кибернетике, менеджменте и биологии. Сегодня я предлагаю обсудить парадигму Кеневина в применении к разработке программного обеспечения.

Владеющие английским могут посмотреть вот это видео (ссылка http://www.youtube.com/watch?v=N7oz366X0-8), в котором сам автор описывает парадигму. Для остальных кратко изложу ее суть на русском.
Итак, в теории запутанности понятие «система» немного отличается от привычного многим, поэтому начну с нескольких определений:
Артефакт — материальный ресурс, имеющий определенное положение и реагирующий на действия агентов.
Агент — коллекция свойств, стратегий и возможностей для взаимодействия с артефактами и другими агентами.
Агентами могут быть как отдельные люди, так и группы людей, правила, идеи и т.д.
Система – некая сеть, включающая одну или несколько групп агентов, и, возможно, артефакты.
Обратите внимание, что в отличие от классического понимания систем, в данном определении отсутствует понятие цели.
В рамках парадигмы Кеневина все окружающие нас системы делятся на три большие группы. На одном конце оси координат находятся упорядоченные системы с жестко ограниченными агентами, характеризующиеся детерминированностью и независимостью от наблюдателя. К таким системам можно отнести конвейер, армию, разработку медицинского оборудования. На другом — хаотические системы, в которых агенты не зависимы от системы и друг от друга. Примером такой системы может быть попытка сплавиться по Ниагарскому водопаду в бочке и предсказать, как эту бочку с находящимся в ней человеком будет крутить и куда выбросит. Ну, а между ними находятся запутанные системы. Такие системы, с одной стороны, ограничивают своих агентов, а с другой — агенты оказывают влияние на систему и друг на друга, в результате чего все это коэволюционирует, и процесс этот является необратимым. Примером может послужить большинство коммерческих организаций, живые организмы и даже кружки по интересам.

Для упорядоченных систем характерно наличие экспертов. В простых системах мнения экспертов сходятся, и есть понятие лучших практик (Best practice). Достаточно действовать в соответствии с этими практиками, и результат будет гарантирован. Все, кто не придерживаются Best practice, начинают проигрывать. В упорядоченных сложных системах разные эксперты могут предлагать разные пути решения, получая одинаково хорошие результаты. Для примера можно взять двух хороших программистов и попросить их выполнить некую задачу. Решения будут отличаться, а вот результаты будет практически идентичными. В данном случае идеального пути нет, но можно выделить несколько достаточно правильных.
В запутанных системах экспертов нет. Да оно и понятно, ведь такие системы имеют множество агентов, взаимосвязи между которыми разнообразны и запутанны. Очень часто в таких системах можно найти факты, противоречащие друг другу. Даже небольшое воздействие на систему может привести к сильным изменениям. В таких системах приходится идти методом проб и ошибок: Попробовали? Дало положительный результат? Продолжаем, а если нет, то давайте сделаем что-то другое.
Хаотичные системы не поддаются анализу. В них нет вообще никакой структуры. Поэтому главное в такой ситуации — начать действовать. Правильно или неправильно — понять не возможно, но так как  состояние хаоса заканчивается очень быстро, то по его завершении мы и узнаем, правильной ли дорогой мы шли. Как правило, те, кто идут, оказываются в более выигрышной позиции по сравнению с теми, кто во время хаоса ничего не делал.
Теперь давайте посмотрим на разработку ПО через призму изложенной теории. Если у нас проекты простые и без изменения требований (правый нижний угол), то можно применять водопадные методики «и в ус не дуть». Если система упорядоченная, но сложная, то можно воспользоваться любой устоявшейся инженерной практикой, будь то PMI или PRINCE2. В зоне же запутанности хорошо себя покажут итеративные подходы к разработке — Scrum или Kanban. Ну а в хаосе можно пробовать все. Если придет жесткий диктатор — появится шанс перейти из хаоса в жестко упорядоченный правый нижний угол, поведет за собой открытый для внешнего мира лидер — попадете в правый верхний квадрат. Даже если вы ничего делать не будете, то хаос вас выкинет хотя бы в зону запутанности.
Главное — не забывать, что все эти зоны субъективны. Вспомните свой первый день на первом месте работы. Все вокруг непонятно, куда-то движется, кто-то с кем-то обсуждает вещи, даже названия которых вы не слышали. Но для окружающих это все могло быть упорядоченной системой с детерминизмом в основе. Да и для вас через несколько дней или недель это был уже не хаос, а система.
Тоже самое происходит и в разработке. Когда вы запускаете новый проект, все запутанно. Гибкие методологии позволят в параллельном или последовательном эксперименте проверить гипотезы, оценить трудоемкость тех или иных задач, определить производительность команды и т.д. Но в дальнейшем может иметь смысл перейти на более формальные подходы к управлению проектом, построить диаграмму Ганта, запланировать буферы, составить реестр рисков. Само собой, многие практики из PMI можно применить и в запутанных системах. Никак не лишним будет список заинтересованных лиц или устав проекта. Но использовать многие другие практики окажется нецелесообразным. Тем не менее, важно о них знать и пробовать применять, чтобы в максимально короткие сроки перейти к упорядоченному состоянию системы.