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

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

Я обычно не спешу соглашаться с теми, кто в качестве реакции на возникающие в ходе проекта проблемы сразу же призывает создать дополнительные правила, которые помогут предотвратить возникновение аналогичных проблем в будущем. Если бы я соглашался с ними, то превратился бы в средней руки бюрократа вроде тех, что развешивают все новые и новые дорожные знаки на перекрестках в попытке предотвратить все до единого происшествия, с которыми кому-то где-то приходилось сталкиваться ранее. Некоторые называют это принципом предосторожности, и им пользуются многие правительства, включая Европейский союз. Фундаментальный смысл этого принципа в том, что, если что-то когда-нибудь может пойти не так, надо на всякий случай, превентивно, просто принять еще один закон. Мне этот подход совсем не нравится.

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

К счастью, разработчики программных продуктов сейчас поумнели. Они все лучше осознают, что не существует универсальных методологий. Это признает Ивар Якобсон, один из основателей унифицированного процесса, в своей состоящей из трех частей статье «Хватит процессов: давайте сосредоточимся на практике» [Jacobson 2007]. В целом лучшие результаты достигаются, когда правила создаются на месте точно под текущую задачу. К такому же выводу пришли и три других исследователя, утверждающие, что лучший способ применять Agile-методологии – адаптировать их под свои задачи [Wailgum 2007].

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

Я пишу эту главу сразу после Рождества – одного из самых удачных примеров массового помешательства. Я всегда с нетерпением жду этого праздника, и не только из-за многочисленных возможностей вкусно поесть. Должен признаться, что мне, как и многим другим, нравятся все эти милые глупости – наряжать рождественскую елку, зажигать свечи, покупать подарки, ходить в кино, петь рождественские гимны.

Идеи, концепции, представления, теории, идеологии, массовые увлечения и моду часто называют мемами [Dawkins 1989]. Люди копируют эти единицы информации друг у друга путем подражания, через взаимодействие и обучение [Stacey 2000a: 168]. Примерами мемов будут Санта-Клаус и рождественская елка, обычай класть подарки в чулок (в Голландии мы прячем их в ботинки) и олень Рудольф. Рождение Иисуса Христа, ангелы и эльфы – тоже мемы.

Аналогичным образом дело обстоит с правилами, процедурами и практиками, которые используются при разработке программных продуктов. Они тоже представляют собой идеи, концепции и мнения, которые люди копируют друг у друга путем подражания, через взаимодействие и обучение. Мемами будут короткие совещания, проводимые стоя (стендапы), парное программирование, рефакторинг, итеративный подход к разработке ПО и пользовательские истории. Меметика – изучение эволюционных моделей передачи информации, часто в культурологическом контексте.

Мемплекс – это собрание взаимозависимых мемов (рис. 10.5). Типичным мемплексом будет Рождество. А также Agile-методологии разработки ПО. Теория универсального дарвинизма показала, что мемы объединяются в мемплексы, поскольку совместное копирование осуществляется более успешно (аналогичное поведение демонстрируют гены, объединяющиеся в генные комплексы). Рождество – успешный мемплекс, потому что входящие в его состав мемы, несмотря на разное происхождение, в настоящее время усиливают друг друга, становясь практически неуничтожимыми. Олень Рудольф вряд ли выжил бы в качестве отдельного мема. Но теперь этот мем в буквальном смысле прочно привязан к Санта-Клаусу и тем самым, по всей видимости, обрел надежду на бессмертие.

Аналогичным образом Agile-практики в разработке ПО также имеют тенденцию усиливать друг друга. Рефакторинг совместим с разработкой через тестирование, пользовательские истории хорошо вписываются в еженедельные итерации, а стендапы более эффективны, если при их проведении используется доска задач. Большинство Agile-практик существовало и до возникновения Agile-методологий. Этот аргумент часто приводят люди, скептически относящиеся к гибким методологиям. Но это не имеет отношения к делу. Важно то, что возникновение Agile-мемплекса стало катализатором для лихорадочного копирования Agile-практик в массовом масштабе, который, скорее всего, был бы невозможен в любом другом случае [Kruchten 2007].

Я на своем опыте убедился, что Agile-мемплекс гораздо сильнее, чем входящие в него индивидуальные мемы. Мои изначальные попытки внедрить только тайм-боксы и требования высокого уровня полностью провалились, потому что я выбрал лишь отдельные практики, которые, как мне казалось, будут полезны. Но они не привились, и отнюдь не из-за отсутствия усилий с моей стороны. Все это напоминало попытку заставить сотрудников петь песенку про оленя Рудольфа летом. Это просто не работает. Отдельных мемов оказалось недостаточно. В один прекрасный момент я понял, что лучше просто попробовать Scrum с соблюдением всех правил. Scrum гораздо конкретнее, у него шире сфера применения, поэтому в результате он оказался значительно успешнее моих самодеятельных попыток улучшить рабочие процессы. Scrum – это мемплекс. Мемы взаимно усиливаются и помогают друг другу копироваться в головах людей. Поэтому легче внедрить Scrum в полном объеме, чем, например, только тайм-боксы и требования высокого уровня.