Означает ли это, что серьезные революции делаются сверху?
Совсем нет. Организационные изменения могут быть осуществлены как сверху вниз, так и снизу вверх. (Хотя многие считают, что подход снизу вверх работает лучше.) При проведении масштабных изменений использование мемплексов будет полезно как для менеджеров (подход сверху вниз), так и для членов команд (подход снизу вверх).
Это не значит, что в ходе большой революции вы должны принять все новые практики одновременно. В конце концов, некоторым требуется несколько месяцев, чтобы подготовиться к Рождеству.
Рассматривая Agile-практики в качестве мемов, можно сделать несколько интересных наблюдений:
• Порой проще заставить людей принять несколько идей, концепций или практик разом, чем одну-единственную. (Например, обучить сотрудников Экстремальному программированию в целом, а не только юнит-тестированию, а затем немедленно приступить к адаптации Экстремального программирования в контексте данной организации.)
• Не все идеи, концепции или практики в составе мемплекса одинаково полезны. Некоторые могут даже оказаться вредными. Но, поскольку все они входят в данный мемплекс, даже плохие идеи помогают копированию полезных, что нейтрализует их отрицательный эффект. (Вот достаточно рискованный пример: я пока не видел убедительных доказательств, что коллективное владение кодом добавляет в проект какую-либо ценность, но в гибких методологиях эта практика подкрепляет остальные, поэтому в целом не повредит, если она также будет скопирована.)
• Удаление отдельных мемов может ослабить, а то и свести на нет силу всего мемплекса. (Пример: если исключить из мемплекса коллективное владение кодом, то внедрение Agile-практик может потерпеть полную неудачу.)
• Могут существовать конкурирующие мемплексы, которые тем не менее взаимно усиливаются и нуждаются друг в друге, поскольку конкуренция между ними отвлекает внимание от других подходов. (Пример: конкуренция между Экстремальным программированием, Scrum и канбаном в рамках мира Agile привлекает внимание к Agile-брендам в целом.)
• Мемы могут иметь разное происхождение и одновременно входить в состав нескольких мемплексов. (Пример: пользовательские истории возникли как мем в рамках Экстремального программирования, но в настоящее время прочно закрепились также и в мемплексе Scrum.)
Мне представляется продуктивным рассматривать Agile-методологии в качестве мемплексов. Единственная их цель – служить катализатором копирования Agile-практик. Любой, кто утверждает, что Agile-методологии не внесли в разработку ПО почти ничего, что не существовало бы ранее, полностью упускает эволюционные преимущества объединения разных практик под одним брендом.
Момент, когда самореплицирующиеся молекулы начали объединяться в генные комплексы, чтобы способствовать копированию друг друга, стал ключевым в эволюционной биологии. Аналогичным образом если смотреть на ситуацию с точки зрения культурной антропологии, то культуры, религии и науки так и не возникли бы, если бы люди не изобрели механизм группировки идей и их копирования под одним именем. Поэтому, как мне представляется, оглядываясь назад, мы увидим, что возникновение Agile-брендов стало очень важным шагом в эволюции разработки ПО.
Разбитые окна
Дома у меня на рабочем столе царит полный беспорядок. Когда я окидываю его взглядом, то вижу книги, журналы, счета, очки, жуткого вида рождественскую елку, звуковые колонки, внешние накопители, два калькулятора, сканер, принтер, стикеры с заметками, лекарства, визитные карточки, карандаши, ручки, цветные маркеры, линейку, батарейки – и даже желудь (из Киева) и каштан (из Хельсинки). И чем больше на моем столе беспорядка, тем больше этого беспорядка становится. В то же время, если на стол бросить, например, еще и сосновую шишку, то никто этого вообще не заметит.
Идея, что проблемы со временем становятся только хуже, обязана своей популярностью теории разбитых окон. Она утверждает, что, когда люди видят явные следы беспорядка или антиобщественного поведения, это провоцирует их на нарушение общественных норм или совершение правонарушений. А это приводит к распространению криминального поведения в целом. Считается, что если бороться с самыми мелкими проявлениями антиобщественного поведения и чаще наводить порядок, то могут быть предотвращены даже более серьезные преступления [Wilson, Kelling 1982: 2–3].Некоторые ученые относятся к теории разбитых окон критически. По их мнению, корреляция здесь могла быть ошибочно принята за причинно-следственную связь и привела к неверной интерпретации результатов некоторых исследований, в том числе к ошибке в знаменитом примере с уровнем преступности в Нью-Йорке, который описан в книге «Переломный момент»
[56] [Gladwell 2002]. И тем не менее существует достаточно доказательств, что верен сам принцип, лежащий в основе теории разбитых окон [Keizer 2008]. Эта теория стала логическим развитием более общей идеи, выраженной в уравнении Левина:
Это уравнение, предложенное психологом Куртом Левином, говорит о том, что поведение человека является функцией личности и внешней среды. Конечно, это не уравнение в научном смысле слова, а обобщение практического опыта. Из него следует, что люди адаптируют свое поведение к среде, в которой живут.
Поскольку люди копируют нормы и поведение друг друга (меметика), то примеры антисоциального поведения, если их сразу не пресекать, с большой вероятностью приводят к его дальнейшему распространению (петля положительной обратной связи). Легко увидеть, что комбинация всех этих идей автоматически приводит к теории разбитых окон.
Какие выводы мы можем сделать из всего этого? С моей точки зрения, их два:
• Крупные проблемы часто начинаются с мелких, которые лучше купировать на начальной стадии, пока они не вышли из-под контроля.
• Если проблема слишком серьезная, чтобы ее можно было решить сразу, необходимо заняться связанной с ней менее крупной проблемой.
Мы обсудим это идеи более подробно в следующей главе, когда будем рассматривать практические аспекты развития компетенций. А тем временем я постараюсь ликвидировать беспорядок на своем столе, пока он не перекинулся на весь дом.
Резюме
Сложные системы, в которых действуют конкурирующие между собой правила, способны к самообучению. Используемые правила могут быть чрезвычайно разнообразными и необязательно распространяться на всю систему (команду).
Вопрос о том, на каком иерархическом уровне должны создаваться правила, – это вопрос компетентности. В явном виде она не упоминается в Agile-манифесте, что, возможно, является слепой зоной гибких методологий и одной из причин возникновения движения в защиту мастерства программирования. Развитие компетенций осуществляется в двух измерениях: дисциплина и профессиональные умения.
