Юрген Аппело - Agile-менеджмент. Лидерство и управление командами

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

К счастью, разработчики программных продуктов сейчас поумнели. Они все лучше осознают, что не существует универсальных методологий. Это признает Ивар Якобсон, один из основателей унифицированного процесса, в своей состоящей из трех частей статье «Хватит процессов: давайте сосредоточимся на практике» [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 в полном объеме, чем, например, только тайм-боксы и требования высокого уровня.

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

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

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

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