Новые методологии программирования

От полного отсутствия - к монументальности, от монументальности - к гибкости Как правило, разработка программного обеспечения представляет собой довольно хаотическую деятельность, которую нередко можно охарактеризовать фразой "code and fix" ("пишем и правим"). Единого плана не существует, а общий проект представляет собой просто смесь краткосрочных решений. Такой подход может сгодиться для создания небольшой системы, однако если система начинает расти, добавлять в нее новые свойства становится все более затруднительно. Кроме того, в ней будет появляться все больше ошибок, которые будет все труднее исправлять. Типичные признаки такой системы - долгий тестовый период уже после того, как разработка всей функциональности системы закончена. При этом нарушаются все планы выпуска программы, так как при подобном тестировании и исправлении ошибок адекватное планирование просто невозможно.

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

Такие методологии существуют уже давно. Нельзя сказать, что они очень уж эффективны. С еще меньшей степенью уверенности можно говорить об их популярности. Чаще всего их обвиняют в бюрократизме - чтобы следовать такой методологии, нужно выполнять так много различных предписаний, что замедляется весь темп работ. Именно поэтому их называют тяжеловесными методологиями, или, согласно термину Джима Хайсмита ( Jim Highsmith ), - монументальными.

За последние годы в противовес этим методологиям появилась группа новых, которые раньше было принято называть облегченными (lightweight). Теперь для них используют другой термин - гибкие (agile) методологии. Привлекательность новых методологий для многих заключается в отсутствии бюрократизма, присущего монументальным методологиям. Новые методологии представляют собой попытку достичь необходимого компромисса между слишком перегруженным процессом разработки и полным его отсутствием. Иначе говоря, объема процесса в них как раз достаточно, чтобы получить разумную отдачу.

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

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

Гибкие методологии адаптивны, а не предсказуемы. Для тяжеловесных методологий необходимо детальное планирование большого объема разработок, и такой подход работает - однако до тех пор, пока не начнутся изменения. Следовательно, для этих методологий сопротивляться всяким изменениям совершенно естественно. Гибкие же методологии, напротив, изменения приветствуют. В отличие от тяжеловесных, они были задуманы как процессы, которые адаптируют изменения и только выигрывают от них, даже в том случае, когда изменения происходят в них самих. Гибкие методологии ориентированы на человека, а не на процесс. В них ясно заявлено о необходимости учитывать в работе природные качества человеческой натуры, а не действовать им наперекор. Кроме этого в гибких методологиях особо подчеркивается, что работа по созданию программных продуктов должна приносить удовольствие.

В последующих разделах я рассмотрю эти различия более подробно, чтобы вы ясно понимали, что имеется в виду под понятиями "адаптивный" и "ориентированный на человека" процесс, в чем его преимущества и недостатки, и стоит ли вам использовать его в своей работе - и как разработчику программных продуктов, и как заказчику.

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

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

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

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

Итак, какую же форму должен иметь такой план? Многие считают, что роль плана должна играть нотация, созданная, например, при помощи языка UML. Если с помощью UML можно отобразить все существенные проектные решения, значит, можно создать нужный план и передать его затем кодировщикам, которые выполнят задачу по конструированию.

Однако здесь возникает важный вопрос: можно ли создать такой план, который превратит кодирование в относительно несложную работу? И, если да, то является ли кодирование настолько дорогим и долговременным процессом, чтобы подобный подход оправдывал себя?

Все это заставляет задуматься еще над несколькими вопросами. Во-первых, насколько сложно довести проект, выполненный на языке UML, до такого состояния, когда его можно передавать программистам. Проблема состоит в том, что нотация на языке UML может выглядеть очень хорошо на бумаге и при этом содержать в себе серьезные дефекты, которые проявятся только тогда, когда начнется работа по непосредственному программированию. В гражданском строительстве создатели моделей опираются на многолетний опыт, зафиксированный в целой системе правил. Кроме того, базовые положения модели (например, проектирование взаимодействия различных сил) поддаются математическому анализу. В отличие от таких моделей, UML и подобные им диаграммы можно проверить только одним образом - с помощью экспертной оценки. Конечно, такая проверка приносит свои плоды, однако при этом кое-какие ошибки могут остаться, и вы узнаете о них только в процессе кодирования или тестирования. Даже опытные проектировщики (каковым я считаю, к примеру, себя) нередко испытывают удивление, видя как их план воплощается в программном продукте.

Теперь относительно сравнительной стоимости. При строительстве моста на работы по проектированию уходит около 10% от всей стоимости работ. Остальное - затраты на конструирование. В программных разработках время, которое тратится на кодирование намного меньше (Макконнелл (McConnell) предположил, что в большом проекте на кодирование и написание тестового кода приходится всего 15%, то есть цифра, с точностью до наоборот повторяющая соотношение планирования и конструирования при постройке моста. Даже если считать тестирование частью конструирования, то все равно проектирование займет не менее 50% работ.) Отсюда вопрос о сущности проектирования при разработке программных продуктов и его отличиях от проектирования в других областях инженерной деятельности.

Наличие подобных вопросов заставило Джека Ривза (Jack Reeves) предположить, что на самом деле проектным документом является исходный код, а вся фаза конструирования сводится к использованию компилятора и компоновщика. И в самом деле, все, что можно отнести к конструированию, может и должно быть автоматизировано.

Размышляя обо всем этом, можно прийти к следующим выводам:

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

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

Конечно, можно считать, что меняющиеся требования - результат плохой разработки требований. Идея за разработкой требований стоит простая - получить полную картину требований до того, как начнется работа над созданием программного продукта, заставить заказчика подписаться под этими требованиями, а потом принять меры, препятствующие последующему их изменению.

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

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

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

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

Впрочем, даже если вам удалось получить четкий список требований, все равно вы обречены. В современной экономике ценность тех или иных свойств программных продуктов меняется слишком быстро. То, что является достаточным набором требований сегодня, оказывается устаревшим уже через полгода. Даже если заказчики могут предоставить стабильный список требований, мир бизнеса от этого не замрет. А ведь многие изменения в мире бизнеса совершенно непредсказуемы (тот кто скажет, что я не прав, либо лжет, либо уже заработал миллион, играя на бирже).

Все прочее в разработке программного обеспечения зависит от требований. Если у вас нет стабильного списка требований, вам не удастся составить предсказуемый план работ.

Предсказуемость невозможна? Вообще-то, возможна. Существуют определенные виды программных разработок, где предсказуемость возможна. Такие организации, как группа по разработке программного обеспечения для космических кораблей в NASA являют собой превосходное доказательство того, что создание программных продуктов может быть предсказуемым процессом. Для этого необходимо соблюдение массы условностей, много времени, большая команда разработчиков и стабильные требования. Да, существуют программные проекты для космических кораблей, однако я не думаю, что бОльшая часть программных бизнес-приложений может быть отнесена к этой категории. Для них необходим другой тип процесса.

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

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

Итак, ситуация непредсказуема, и предсказуемую методологию использовать больше нельзя. Тяжелый удар. Это означает, что многие модели управления процессом разработок, многие модели взаимоотношений с заказчиком больше не существуют. Насколько лучше был предсказуемый процесс, и как трудно от него отказаться! Как и в большинстве проблем, самое трудное в данном случае - просто признать, что проблема существует.

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

Управляем непредсказуемым процессом Итак, каким образом нам удается сохранять спокойствие, живя в непредсказуемом мире? Самое главное и самое сложное - точно знать, что в действительности происходит в настоящий момент. Нам необходим механизм, предоставляющий правдивые данные о текущей ситуации через короткие временные интервалы.

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

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

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

Камнем преткновения в данном случае является вопрос о длительности каждой итерации. Единого мнения на этот счет нет. Extreme Programming (XP) предполагает, что итерация должна длиться от одной до трех недель. SCRUM предлагает продлить ее до одного месяца. Crystal - еще больше. Впрочем, все соглашаются в одном - нужно делать итерацию настолько короткой, насколько это возможно. Частые итерации позволяют разработчикам чаще получать сведения о системе от ее заказчиков, а значит, лучше представлять себе текущую ситуацию.

Адаптивный заказчик Адаптивный процесс требует других отношений с заказчиком (не таких, какими их обычно представляют), особенно если разработка выполняется сторонней организацией. Если вы нанимаете отдельную фирму-разработчика, большинство заказчиков захочет заключить контракт с фиксированной стоимостью работ. Процедура известна: вы объясняете компании-разработчику, что нужно сделать, они называют цену, вы ее принимаете, после чего вся ответственность ложится на плечи разработчиков, которые должны создать требуемый программный продукт.

Контракт с фиксированной стоимостью предполагает неизменность требований, а значит, использование предсказуемого процесса. Если использовать адаптивный процесс при нестабильных требованиях, обычная установка на фиксированную оплату уже не срабатывает. Попытка втиснуть адаптивный процесс в рамки фиксированной оплаты приводит к весьма неприятным конфликтам. При этом самое неприятное то, что заказчик пострадает ничуть не меньше компании-разработчика. В конце концов, заказчику не понадобился бы программный продукт, если бы того не требовал бизнес. Если он не получит этот программный продукт, бизнес пострадает. Итак, даже если заказчик не заплатит компании разработчику ничего, он все равно несет убытки. Более того, он теряет даже больше, чем если бы заплатил за готовую систему (зачем бы заказчику платить за нее деньги большие, нежели ее коммерческая стоимость?)

Таким образом, при подписании контракта с фиксированной суммой оплаты в ситуации, когда невозможно использовать предсказуемый процесс, рискуют обе стороны. Иначе говоря, это означает, что заказчик должен действовать по-другому.

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

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

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

Совместимые программирующие устройства Одна из основных задач, которые ставят перед собой традиционные методологии - обеспечить процесс работ, в котором люди будут представлять собой заменимые блоки. При этом к людям относятся просто как к ресурсам различных типов. У вас есть аналитик, несколько кодировщиков, несколько тестеров, руководитель проекта. Индивидуальность не важна - только роли. Таким образом, при планировании вас не интересует, какой у вас аналитик и какие тестеры - главное, знать, сколько у вас работников, ибо их количество нужно учитывать в плане.

И здесь возникает очень важный вопрос: можно ли считать людей, занятых в создании программного обеспечения, заменимыми блоками? Гибкие методологии говорят - нет.

Возможно, наиболее ярко об этом пишет Алистэр Коуберн (Alistair Cockburn). В своей работе "Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения" ("Characterizing People as Non-Linear, First-Order Components in Software Development"), он утверждает, что предсказуемому процессу нужны компоненты, которые также будут вести себя предсказуемым образом. Люди же не могут считаться таковыми. Более того, в результате изучения различных проектов Коуберн приходит к выводу, что люди представляют собой наиважнейший фактор в создании программных продуктов.

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

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

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

Поставить людей на первое место - серьезный шаг, для осуществления которого потребуется вся ваша решительность. Отношение к людям как к ресурсам глубоко укоренилось в бизнес-сознании, его истоки берут начало в "Научном управлении" Фредерика Тэйлора (Frederick Taylor). При управлении фабрикой этот подход, возможно, и оправдывает себя. Однако для такой творческой и профессиональной работы, какой я считаю создание программных продуктов, он не годится. (Кстати, современное производство также отходит от модели Тэйлора.)

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

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

(Здесь может быть, играет роль и возрастной фактор. Глядя на некоторые анекдотические свидетельства культа молодости в нашей отрасли, я задаюсь вопросом, не пришло ли за последние десять лет в программирование еще больше талантливой молодежи. Если это так, то культ молодости в компьютерном бизнесе вполне может объясняться этим - ведь, как и у любого культа, у него должно быть некое разумное основание.)

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

Управляем процессом, ориентированным на человека Ориентация на человека проявляется в гибких процессах по-разному. Это приводит к различным результатам, причем иногда противоречивым.

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

Из всего этого следует интересный вывод: только сами разработчики могут решить - использовать адаптивный процесс, или нет. Особенно это справедливо для Extreme Programming (XP), при осуществлении которого необходима строгая дисциплина. С этой точки зрения Crystal имеет некоторое преимущество, так как требует минимальной дисциплины.

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

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

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

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

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

Вообще, к этому вынуждает сама суть адаптивных разработок, которая заключается в том, что все очень быстро меняется. Естественно, чтобы все вовремя узнавали об изменениях, необходим постоянный контакт.

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

Адаптация адаптивного процесса До сих пор я говорил об адаптивности в применении к проекту, то есть, тех случаях, когда программный продукт адаптируется к изменяющимся требованиям клиента. Однако адаптивность можно рассматривать и в другом ракурсе: с точки зрения изменяемости самого процесса. Если вы начинаете проект с использованием адаптивного процесса, то уже через год будете работать с процессом, который будет значительно отличаться от первоначального. С течением времени команда разработчиков сама понимает, что в этом процессе ей подходит, а что нет, и соответствующим образом изменяет его.

Основа изменений в адаптивном процессе - регулярный его пересмотр. Обычно это делается в конце каждой итерации, когда вы собираетесь на короткое собрание и задаете себе следующие вопросы (по Норму Керту (Norm Kerth))

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

Если "настройка" процесса происходит во время какого-либо проекта, то процесс становится еще более индивидуализированным, характерным для данной компании. Чтобы углубить такую "настройку" я бы посоветовал разработчикам делать пересмотр процесса еще более строгим и отмечать главные вехи проекта в виде ретроспективных сессий, как это описано у Норма Керта. Ретроспективные сессии включают в себя двух-трех дневное собрание вне офиса компании при содействии специального наставника. Такие сессии служат источником знаний не только для команды разработчиков, но и для всей организации.

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

Адаптивная сущность самого процесса более всего подчеркивается в ASD и Crystal. Что касается ХР, то на первый взгляд может показаться, что строгие правила этой методологии не позволяют вносить в процесс изменения. На самом деле это не так. Однако главное отличие по сравнению с другими гибкими методологиями состоит в данном случае в том, что пропагандисты ХР предлагают следовать "официальной версии" этой методологии в течение нескольких итераций, а уже потом менять ее. Кроме того, источники по ХР вообще не упоминают пересмотры процесса и не считают их частью методологии (хотя существует мнение, что они должны быть сделаны одной из практик ХР).

Методологии К разряду гибких можно отнести целый ряд методологий. Всем им присущи общие черты, однако есть и довольно существенные различия. В таком кратком обзоре как этот я не могу рассказать подробно о каждой методологии, но по крайней мере, могу указать вам, где искать дополнительную информацию. Кроме того, у меня нет опыта практической работы с большинством из них. Я довольно много работал с ХР, видел RUP в разных ипостасях, однако обо всех остальных я имею представление почти исключительно по литературе.

XP (Extreme Programming) Из всех гибких методологий эта - самая известная. Отчасти это произошло потому, что лидеры ХР, в особенности Кент Бек (Kent Beck) наделены замечательной способностью привлекать к себе внимание. Немаловажную роль сыграл и талант Кента вербовать сторонников своего движения и вести их за собой. Можно даже сказать, что популярность ХР стала в некотором роде проблемой, так как эта методология практически вытеснила все остальные, а вместе с ними и те ценные идеи, которые они несут.

Истоки ХР ведут к сообществу разработчиков ПО на языке Smalltalk, а именно к тесному сотрудничеству Кента Бека и Уорда Каннингэма (Ward Cunningham) в конце 80-х годов. В начале 90-х годов оба они оттачивали свои методики на многочисленных проектах, разрабатывая идеи по созданию нового подхода к разработке ПО, который был бы адаптивным и ориентированным на человека.

Окончательный переход от неформальной методики к полноценной методологии произошел весной 1996 года. "Крайслер" пригласил Кента оценить состояние работ по системе контроля платежей. Система создавалась на языке Smalltalk сторонней компанией, которая не справлялась с задачей. Качество программного кода было настолько низким, что Кент посоветовал все выбросить и начать все заново. Проект начался с нуля теперь уже под его руководством и вскоре превратился в первый опытный полигон ХР.

Первая стадия проекта завершилась в начале 1997. После этого проект некоторое время продолжался, затем стал испытывать затруднения, которые привели к тому, что в 1999 году дальнейшие разработки были прекращены. Впрочем, эта система и по сей день используется для выплаты зарплаты десяти тысячам сотрудников компании.

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

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

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

У ХР много лидеров, большинство из которых работало над Крайслеровским проектом. В результате образовалось множество источников информации, касающихся этой методологии. Лучшим кратким изложением ХР была статья Джима Хайсмита (Jim Highsmith) в журнале "Cutter". Однако теперь получается, что написана она аутсайдером, так как сейчас Джим пропагандирует свою собственную методологию, о которой я расскажу позже. Кент Бек написал книгу Extreme Programming Explained, которая представляет собой настоящий манифест ХР. В книге дается логическое обоснование этой методологии и достаточно подробное ее описание, так что читатели сами могут решить, будут ли они следовать ХР в дальнейшем.

Недавно появились еще две книги. Первую написали трое участников Крайслеровского проекта: Рон Джеффрис (Ron Jeffries), Энн Андерсон (Ann Anderson) и Чет Хендриксон (Chet Hendrickson). Называется она Extreme Programming Installed и представляет собой описание XP, построенное на опыте работы авторов в этом проекте. Кент Бек и я написали книгу Planning Extreme Programming, в которой раскрываются принципы адаптивного планирования.

Помимо книг, существует изрядное количество web-ресурсов. Чтобы начать знакомство с ХР лучше обратиться к более структурированной информации на сайтах Рона Джеффри xProgramming.com и Дона Веллса (Don Wells) extremeProgramming.org. Целое море интересных материалов содержится на xPlorations Билла Уэйка (Bill Wake). Первоначально практически все обсуждение и развитие идей, касающихся ХР, происходило на wiki web (среда для совместного ведения записей) Уорда Каннингэма. На этот сайт и по сей день интересно заходить, однако в таком обилии информации легко потеряться. Роберт Мартин, широко известный своими работами в области C++ и объектно-ориентированного проектирования, также пополнил ряды сторонников XP. На сайте его компании ObjectMentor можно найти ряд работ на эту тему, включая описание варианта XP, который построен на основе RUP и носит название dX. Кроме этого его компания является спонсором дискуссионной группы XP на сайте egroups. Интересный взгляд на ХР "со стороны" мы находим у Марка Полка (Mark Paulk), одного из лидеров СММ-сообщества. Он рассматривает ХР как раз в перспективе СММ.

Семейство методологий Crystal Алистэра Коуберна Алистэр Коуберн (Alistair Cockburn) изучает методологии разработки ПО с начала 90-х, когда компания IBM дала ему задание написать работу на эту тему. При этом его подход существенно отличается от подхода большинства других методологов. Его теории основаны не только на личном опыте, но и на постоянных исследованиях других проектов и процессов. Более того, он не боится менять свои воззрения в результате своих находок в этой области. Именно поэтому Алистэр Коуберн остается моим любимым методологом.

Первой рекомендацией Коуберна по ведению проектов стала книга Surviving Object-Oriented Projects, и по моему мнению, она остается лучшей работой по управлению итеративным проектом и по сей день. Совсем недавно он написал еще одну книгу, которая посвящена обзору гибких методологий разработки программного обеспечения. В ней он рассматривает базовые принципы, лежащие в основе всех этих методологий.

После этого он продолжал исследовать гибкие методологии, результатом чего стало появление семейства методологий Crystal. Коуберн называет это "семейством", так как убежден, что разным проектам нужны разные методологии. Он вводит следующую градацию проектов: по одной оси откладывается количество занятых в проекте людей, по другой - критичность ошибок. Каждая из методологий "семейства" предназначена для определенной ячейки получившийся сетки. Таким образом, проект, в котором занято 40 человек, и на котором компания может позволить себе потерять некоторую сумму, будет работать по другой методологии, нежели проект для 6 разработчиков, от которого зависит существование компании.

Как и ХР, методологии семейства Crystal тоже ориентированы на человека, однако несколько по-другому. Алистэр считает, что людям сложно использовать в работе процесс, который требует от них высокой дисциплины. В результате своих исследований он выяснил, какой объем дисциплины является для действенной методологии минимальным. При этом производительность методологии сознательно приносилась в жертву простоте ее использования. Пусть Crystal уступает ХР в производительности, зато ей сможет пользоваться большее количество людей, полагает Алистэр.

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

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

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

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

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

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

Процесс разработки ПО с открытым исходным кодом до сих пор толком не описан. Самым известным источником по этой теме остается замечательная статья Эрика Рэймонда The Cathedral and the Bazar. Тем не менее, она не может претендовать на полное изложение процесса разработки открытого ПО. (Русский перевод статьи - "Собор и базар" - опубликован в журнале "Byte Россия" в октябре 1999 года. Прим. перев.) Тему процесса разработки проектов с открытыми исходниками затрагивает и Карл Фогель (Karl Fogel) в своей книге о репозитории кода CVS. Эту книгу будет интересно почитать даже тем, кто никогда не хотел выполнять команду "cvs update".

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

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

Основу ASD составляют три нелинейные перекрывающие друг друга фазы: обдумывание, сотрудничество и обучение.

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

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

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

В адаптивном окружении обучения не избежать всем участникам проекта - и разработчикам, и их заказчикам - поскольку и те, и другие в процессе работы должны пересматривать собственные обязательства, а также использовать итоги каждого цикла разработки для того, чтобы подготовиться к следующему. -- [Хайсмит] Таким образом, обучение оказывается постоянной и важной характеристикой процесса, наличие которой подразумевает, что планы и проекты должны меняться в ходе работ.

Основное, наиболее действенное и первостепенное достоинство жизненного цикла ASD заключается в том, что этот процесс заставляет нас отказаться от интеллектуальных построений, которые являются источником самообмана. Он вынуждает нас оценивать собственные способности более реалистично. -- [Хайсмит] Подчеркнув это, Хайсмит переходит непосредственно к сложным моментам адаптивных разработок, в частности, к вопросу обеспечения сотрудничества и обучения во время реализации проекта. Таким образом, его книга, описывающая эти "гибкие" аспекты процесса, представляет собой замечательное дополнение к более "приземленным" подходам, например, ХР, FDD и Crystal. С этой точки зрения, слияние методологии Хайсмита с Crystal выглядит вполне обоснованным.

SCRUM Этот метод довольно давно известен среди тех, кто занимается объектно-ориентированными разработками, однако я не могу сказать, что досконально знаю его историю и развитие. Как и в прочих гибких методологиях, здесь подчеркивается, что определенный и повторяющийся процесс годится только для решения определенных и повторяющихся проблем в определенной и повторяющейся среде, в которой работают определенные и повторяющиеся разработчики.

Согласно методу SCRUM, проект делится на итерации (которые здесь называются "спринт"), по 30 дней каждая. Перед началом спринта вы определяете функциональность, которая требуется на данном этапе, после чего уступаете место команде разработчиков, которые выполняют поставленную вами задачу. Весь фокус в том, чтобы в течение одного спринта требования оставались неизменными.

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

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

Книгу по методологии SCRUM все ждали довольно давно, и вот Кен Швабер (Ken Schwaber) и Майк Бидл (Mike Beedle) наконец-то написали ее. Кен Швабер также поддерживает сайт controlChaos.com, где содержится, пожалуй, лучший обзор SCRUM. На всегда оживленном сайте Джеффа Сазерлэнда (Jeff Sutherland), посвященном объектно-ориентированным технологиям, есть раздел о SCRUM. Хорошо изложен материал о приемах работы по методологии SCRUM в книге PLoPD 4.

Feature Driven Development Эта методология (кратко именуемая FDD) была разработана Джеффом Де Люка (Jeff De Luca) и признанным гуру в области объектно-ориентированных технологий Питером Коадом (Peter Coad). Как и остальные адаптивные методологии, она делает основной упор на коротких итерациях, каждая из которых служит для проработки определенной части функциональности системы. Согласно FDD, одна итерация длится две недели.

FDD насчитывает пять процессов. Первые три из них относятся к началу проекта.

Разработка общей модели Составление списка требуемых свойств системы Планирование работы над каждым свойством Проектирование каждого свойства Конструирование каждого свойства Последние два шага необходимо делать во время каждой итерации. При этом каждый процесс разбивается на задачи и имеет критерии верификации.

Все разработчики делятся на два вида: "class owners" (владельцы классов) и "chief programmers" (старшие программисты). Старшие программисты - это наиболее опытные разработчики. Именно им поручается разработка конкретных свойств системы. Однако они не занимаются этим самостоятельно: старший программист определяет, какие классы заняты в реализации данного конкретного свойства, после чего собирает команду из владельцев необходимых классов, которая и будет заниматься разработкой. Сам он действует как координатор, главный проектировщик и руководитель, а на долю владельцев классов остается, по большей части, непосредственное кодирование.

Наиболее полное описание методологии FDD можно найти в книге Питера Коада со товарищи, под названием "UML in Color" . Его компания, "TogetherSoft", также занимается консалтингом и обучением FDD.

Dynamic System Development Method (DSDM) DSDM появился в Великобритании в 1994. Его основателем стал консорциум из 17 английских компаний, которые хотели работать с использованием RAD и принципов итеративной разработки. Сейчас число его членов перевалило за тысячу, причем многие из них находятся за пределами Соединенного королевства. То, что DSDM разрабатывается целым консорциумом, заметно отличает его от прочих гибких методологий. Целая организация занимается разработкой пособий по этой методологии, организацией учебных курсов, программ аккредитации и т.п. Кроме того, ценность DSDM имеет денежный эквивалент, что ограничило глубину моего исследования. Впрочем, Дженифер Стэйплтон (Jennifer Stapleton) написала книгу, где можно найти краткий обзор этой методологии.

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

Далее процесс делится на три взаимосвязанных цикла: цикл функциональной модели отвечает за создание аналитической документации и прототипов, цикл проектирования и конструирования - за приведение системы в рабочее состояние, и наконец, последний цикл - цикл реализации - обеспечивает развертывание программной системы.

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

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

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

Надо сказать, что я ошибался. Каждый из присутствовавших сознавал, что у всех представленных на семинаре процессов много общего, и что это гораздо важнее существующих между ними расхождений. Таким образом, дело не ограничилось простым установлением контакта между лидерами методологий, и было высказано предложение выпустить совместное заявление - призыв к большему использованию гибких методологий. (Мы также решили, что термин "гибкие" (agile) точнее всего отражает наши общие представления о таких методологиях.)

В результате родился Манифест гибкой разработки программного обеспечения (Manifesto for Agile Software Development) - описание общих черт и принципов гибких процессов. В нем также высказывается намерение сотрудничать и в дальнейшем, а также способствовать тому, чтобы и специалисты в области бизнеса, и специалисты в области техники, использовали гибкие подходы в разработке ПО и требовали этого от своих партнеров. Недавно в одном из компьютерных журналов появилась статья, в которой приводятся комментарии к Манифесту. Кроме того, здесь вы можете прочесть чуть более подробно о том, как мы видим будущее этого документа.

Можно ли считать RUP гибким методом? Всякий раз при обсуждении методов разработки ПО в сфере объектно-ориентированных технологий, разговор неизбежно заходит о роли Rational Unified Process (Рациональный Унифицированный Процесс). Унифицированный Процесс был разработан Филиппом Крачтеном (Philippe Kruchten), Иваром Якобсоном (Ivar Jacobson) и другими сотрудниками компании "Rational Software" в качестве дополнения к языку моделирования UML. RUP представляет собой каркас для процессов, и таким образом, включает в себя огромное их количество. Именно эта черта RUP вызывает основную критику - поскольку он может быть чем угодно, его нельзя считать ничем определенным. Мне же больше по душе те процессы, в которых вам ясно указывается, что делать, вместо того, чтобы предоставлять бесконечные возможности.

В результате такого каркасного построения RUP можно использовать и как основу для самого, что ни на есть традиционного водопадного стиля разработки, и в качестве гибкого процесса. Итак, RUP может быть и гибким, и тяжеловесным процессом - все зависит от того, как вы будете его применять в вашем конкретном случае.

Крэйг Ларман (Craig Larman) - один из пропагандистов использования RUP в качестве гибкого процесса. В своей замечательной книге - введению в объектно-ориентированную разработку ПО он описал процесс, который в большой степени основан именно на таком восприятии RUP. Крэйг считает, что недавний переход к новым гибким методологиям на самом деле ничто иное, как принятие идеи объектно-ориентированной разработки, которую как раз и отражает RUP. Он рекомендует всей команде разработчиков проводить первые два-три дня каждой итерации (продолжительность которой составляет месяц), принимая предварительные решения по построению системы и оформляя их в виде UML-диаграмм. Эти диаграммы - не строгое предписание, от которого нельзя отклониться, а лишь набросок, дающий разработчикам представление о работах, намеченных на данную итерацию.

Еще одним вариантом "гибкого RUP" является процесс dX Роберта Мартина (Robert Martin). dX - это процесс, полностью соответствующий RUP, и при этом являющийся копией ХР (чтобы понять шутку, переверните "dХ"). dX создан для тех, кто вынужден использовать RUP, хотя хотел бы работать по XP. А этот процесс является одновременно и XP, и RUP, что являет собой хороший пример "гибкого" использования RUP.

Мне кажется, что лидеры RUP должны со всей определенностью заявить о своем подходе к разработке ПО. Несколько раз я слышал, что те, кто использует RUP, применяют водопадный стиль разработок. Согласно моим сведениям, Филипп Крачтен и его команда являются твердыми сторонниками итеративности процесса. Объяснив свою позицию, а также поощряя гибкие варианты RUP (такие как процессы Крэйга Лармана или Роберта Мартина) они внесли бы ценный вклад в дело развития методологий.

Прочие источники Существует еще множество других работ и дискуссий на тему легких методологий. Возможно, их нельзя назвать настоящими, оформленными методологиями, однако в них тоже встречаются интересные идеи.

В конференциях Patterns Language of Programming часто встречаются материалы на данную тему (наверное, потому что те, кто интересуется паттернами, интересуется также и более адаптивными и ориентированными на человека методами разработки ПО). Основным источником из числа ранних работ на эту тему была работа Джима Коплейна в PLoP1. В PLoP2 появился Episodes pattern language Уорда Каннингэма. В настоящее время Джим Коплейн поддерживает сайт OrgPatterns, который представляет собой wiki (среду для совместного ведения записей), где собираются и организовываются паттерны.

Дирк Риэль (Dirk Riehle) отправил работу на XP2000. В этой работе он сравнивает характеристики XP и Adaptive Software Development. В письме Коада сравниваются уже XP и FDD. В июльском номере "IEEE Software" есть несколько статей на тему "многообразия процессов", где также говорится об этих методологиях.

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

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

Сегодня самой распространенной методологией остается "пишем и исправляем". Внести в этот хаос немного дисциплины всегда на пользу, к тому же у гибких подходов есть существенное преимущество - переход к ним осуществить значительно легче, нежели использовать тяжеловесную методологию. Гораздо легче перейти к использованию простого процесса, особенно если до этого никакого процесса у вас вообще не было.

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

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

Итак, как вы заметили, я сказал, что если у вас в команде более 50 человек, вам следует использовать предсказуемый процесс, а если требования к системе часто меняются, то адаптивный. Что же делать, если у вас и большой проект, и меняющиеся требования? Честно говоря, не знаю. Могу только сказать, что вам придется попотеть, но вы об этом наверняка и сами догадываетесь.

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

Итак, подведем итоги. Адаптивный процесс стоит использовать, если у вас:

Неясные или изменяющиеся требования к системе Ответственные и квалифицированные разработчики Понимающий заказчик, который согласен участвовать в разработке.

А в этих случаях лучше использовать предсказуемый процесс:

Команда разработчиков более 50 человек Контракт с фиксированной стоимостью, или, скорее, с фиксированным объемом работ.

Какой из гибких процессов выбрать? Все описанные выше процессы новые, поэтому я только могу дать вам совет, основываясь на личном опыте. По моему мнению, весь вопрос в размере команды и объеме дисциплины, на который они согласны.

Я без сомнения порекомендовал бы ХР, если у вас есть дюжина или меньше разработчиков, которые хотели бы попробовать этот процесс. Возможно, ваша команда не будет соблюдать этот процесс в точности (по крайней мере, в начале), однако даже в этом случае, частичное использование ХР будет полезным. С моей точки зрения, главным показателем правильного использования процесса является написание автоматизированных тестов (unit testing). Если команда справляется с этим, то все остальное приложится. Если же нет, то, скорее всего, ХР им не подойдет.

Если команда очень большая, или в ней хромает дисциплина, то я бы стал использовать Crystal. Это самая легкая из всех гибких методологий, а Коуберн очень восприимчив к урокам разработки. Но и в этом случае процесс планирования я бы позаимствовал у ХР.

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

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

Благодарности Идеи для этой статьи я позаимствовал у большого числа людей, гораздо большего, чем могу здесь перечислить. За конкретные замечания я хотел бы поблагодарить Марка Бэлсера (Marc Balcer), Кента Бека, Алистэра Коуберна, Уорда Каннингэма, Билла Киммеля (Bill Kimmel) и Фрэнка Вестфэла (Frank Westphal).