Меметика

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

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

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

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

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

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

Означает ли это, что серьезные революции делаются сверху?

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

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

Рассматривая Agile-практики в качестве мемов, можно сделать несколько интересных наблюдений:

• Порой проще заставить людей принять несколько идей, концепций или практик разом, чем одну-единственную. (Например, обучить сотрудников Экстремальному программированию в целом, а не только юнит-тестированию, а затем немедленно приступить к адаптации Экстремального программирования в контексте данной организации.)

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

• Удаление отдельных мемов может ослабить, а то и свести на нет силу всего мемплекса. (Пример: если исключить из мемплекса коллективное владение кодом, то внедрение Agile-практик может потерпеть полную неудачу.)

• Могут существовать конкурирующие мемплексы, которые тем не менее взаимно усиливаются и нуждаются друг в друге, поскольку конкуренция между ними отвлекает внимание от других подходов. (Пример: конкуренция между Экстремальным программированием, Scrum и канбаном в рамках мира Agile привлекает внимание к Agile-брендам в целом.)

• Мемы могут иметь разное происхождение и одновременно входить в состав нескольких мемплексов. (Пример: пользовательские истории возникли как мем в рамках Экстремального программирования, но в настоящее время прочно закрепились также и в мемплексе Scrum.)

Мне представляется продуктивным рассматривать Agile-методологии в качестве мемплексов. Единственная их цель – служить катализатором копирования Agile-практик. Любой, кто утверждает, что Agile-методологии не внесли в разработку ПО почти ничего, что не существовало бы ранее, полностью упускает эволюционные преимущества объединения разных практик под одним брендом.

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