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

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

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

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

Компоненты и объем методологии Под "методологией" я понимаю то, что написано в качестве первого толкования этого слова в Американском словаре Miriam-Webster: "ряд связанных между собой методов или техник". Оксфордский словарь толкует это слово только как "изучение методов". В этой статье я использую американский вариант. (Для интересующихся: в "Толковом словаре русского языка" Ожегова это слово трактуется как "принципы и способы организации теоретической и практической деятельности" и "совокупность методов, применяемых в какой-либо науке". -- прим. переводчиков)

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

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

Рисунок 1. Составляющие методологии (с примерами).

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

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

У методологии есть "объем", который определяется протяженностью жизненного цикла проекта, разнообразием ролей и видов их деятельности, которые и пытается покрыть собой методология (см. рис. 2):

Рисунок 2. "Объем" методологии.

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

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

Принцип 1. Большая по размерам методология нужна тогда, когда в проекте занято большое число разработчиков.

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

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

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

Я классифицирую программные системы по следующим категориям возможного ущерба (разумеется, этот список можно расширить):

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

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

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

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

Принцип 3. Незначительное увеличение "размеров" или "плотности" методологии ведет к существенному увеличению стоимости проекта.

Приостановка работы одной команды программистов для координации с другой командой требует не только дополнительного времени, но и дополнительной концентрации (см. обсуждение "потока" у ДеМарко [DeMarco99] и Коуберна [Cockburn98]). Для обновления документации, относящейся к требованиям, дизайну системы и тестированию, тоже понадобится немало времени.

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

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

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

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

Именно поэтому (см. Рисунок 3) для решения конкретной задачи вам понадобится меньше людей, если вы будете использовать легкую методологию, и больше - если тяжелую. Впрочем, существует ограничение по размеру задачи, которую может решить данное число людей. У большой команды, использующей тяжелую методологию, этот "порог" выше, чем у маленькой команды, которая использует легкую методологию. Таким образом, если ваша задача выходит за рамки такого ограничения, то вам придется, с одной стороны, увеличивать количество разработчиков и, с другой, использовать более тяжелую методологию.

Рисунок 3. Объем задачи и методологии непосредственным образом влияет на количество персонала в компании.

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

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

Завершившийся не так давно проект С3 (Chrysler Comprehensive Compensation [C3a, C3b]), может служить убедительным примером всего, о чем я сейчас говорил. После того, как 26 человек не смогли выполнить задачу по созданию системы, которая считалась "большим проектом", за дело взялась малая часть этой команды - всего восемь человек. Используя новую, максимально легкую, но при этом строгую методологию [XP], они начали проект с нуля и уже через год смогли завершить то, что не смогла сделать большая команда, применявшая тяжелую методологию. Можно с уверенностью сказать, что частично такой успех методологии ХР был обеспечен последним, четвертым Принципом.

Принцип 4. Наиболее эффективная форма коммуникации (для передачи идей) - непосредственное взаимодействие, лицом к лицу, как при рисовании у доски.

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

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

Рисунок 4. Эффективность коммуникации

Однако это "правило коммуникации" вовсе не означает, что любой программный продукт должен быть разработан несколькими людьми, сидящими в одной комнате. Автор методологии должен знать, что если первоочередными факторами являются продуктивность и стоимость программных разработок, то необходимо уделить особое внимание работе небольшими командами и непосредственному общению между сотрудниками (как, например, это сделано в Extreme Programming [XP]). Этот вывод подтвержден исследованиями [Plowman95]. Кроме того, в работе Силлинса [Sillince96] приводится обсуждение различных аспектов коммуникации внутри одной организации.

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

В некоторых методологиях приоритеты заметны сразу, в некоторых нет. Так, например, объектно-ориентированная методология Мартина и Оделла [Martin96] достаточно общая и подходит для многих случаев, однако не совсем понятно, на что конкретно она направлена, и можно ли менять эту "направленность" для работы над различными проектами. Семейство методологий OPEN [BHS97], по всей видимости, основной целью полагает корректность программных продуктов, явность и повторяемость процесса. Методология под названием The Personal Software Process of Humphreys [Humphreys97] была разработана для обеспечения предсказуемости работ.

В трех последних методологиях о приоритетах говорится открыто: авторы семейства методологий Crystal [Cockburn98, Crystal] и Extreme Programming [XP, Beck99] заявили, что их методологии направлены, в первую очередь, на повышение продуктивности и снижение стоимости работ. При этом они все же отличаются друг от друга - Crystal призывает совмещать производительность и толерантность, в отличие от ХР, где продуктивность возрастает как раз за счет уменьшения толерантности. Методология "Adaptive Software Development", детище Джима Хайсмита [Highsmith], разработана специально для крайне нестабильных ситуаций в разработках, когда требования, проектирование и невозможно короткие сроки являются функциями друг друга и постоянно меняются (так зачастую происходит в веб-разработках).

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

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

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

Рисунок 5. Методологии, организованные по принципу люди х критичность х приоритетность.

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

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

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

В то время, когда я там находился, основным проектом был проект Y2K, в котором было занято 35 человек. Главной целью здесь являлось предотвращение крушения банковской системы Норвегии, которое могло состояться 1 января 2000 года. Критичность проекта соответствовала "потере невосполнимой суммы", главными приоритетами были своевременность и корректность проекта. Основополагающей технологией являлись традиционные большие ЭВМ.

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

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

Один программист использовал язык SQL для формирования различных обобщающих отчетов, касающихся инвестиций и затрат. Еще один проект был начат для того, чтобы заменить существующие системы, работающие на больших ЭВМ, на распределенные системы, использующие Интернет-технологии, объектно-ориентированный подход и компонентную архитектуру, построенную на базе CORBA/Java. Были еще и другие проекты, но я думаю, что упомянул уже достаточно, чтобы читатель получил общее представление о ситуации. Как мне кажется, в подобном случае невозможно говорить о какой-то одной методологии, которая была бы "правильной" для всего этого разнообразия задач и проектов.

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

В ноябре мне сказали, что этот проект рассчитан на 15 рабочих недель, что всего в разработках участвует 3 человека, что дизайн программы уже практически завершен, и что у людей есть сходный опыт работы над предыдущей версией системы. Исходя из изложенной выше схемы методологий и моего собственного опыта, я предположил, что этот проект соответствует позиции D4 на схеме, а это означало, что трем разработчикам следует создавать систему просто работая сообща, обращая минимум внимания на всякие бюрократические штучки (нашей стандартной фразой было: "сделай свою работу и иди домой"). Впрочем, вскоре оказалось, что вся задача была оценена приблизительно, и к тому же, только частично. Мы провели дополнительные вычисления, и оказалось, что этот проект должен быть рассчитан на 130 рабочих недель. Кроме того, мы пересмотрели идею насчет того, что все три программиста могут работать в разных городах. В процессе работы использовались новые технологии, требовалось внедрение новой, более чувствительной схемы обработки ошибок, система должна была работать в реальном времени, и вдобавок обнаружились проблемы со взаимоисключающим доступом внутри основной базы данных. Кроме того, выяснилось, что им нужно еще и работать вместе с другой командой, которая находилась в другой части города. Ведущий архитектор через два месяца уходил в отпуск по уходу за ребенком, руководитель проекта не имел опыта работы ни в IT сфере, ни в руководстве проектами, а между тем, отчетность по проекту должна была осуществляться на высоком государственном уровне. В этот момент я решил перевести наш проект в категорию E5. Это означало переход к инкрементным разработкам, планированию выпусков системы с минимальным риском, еженедельные телеконференции всей группы разработчиков, ежемесячный доклад о положении дел и т.д. Первая итерация прошла в начале февраля, и прошла в срок. Однако сразу после этого ушел в отпуск архитектор, одного из ведущих программистов перебросили на проект "по борьбе с ошибкой 2000 года", а мы обнаружили ошибку в проектных решениях, отвечающих за восстановление после ошибочных ситуаций и за контроль над взаимоисключающим доступом. Теперь на наш проект отвели уже десять человек, большинство которых не имело опыта работы в данной области, к тому же работали в совершенно разных местах. Обычные каждодневные встречи и общение были попросту невозможны. В середине февраля я решил, что проект пора переводить в категорию E15. Мы разработали более подробный план поставок для каждого разработчика, запустили программу моделирования тестов, стали уделять большее внимание общению с каждым из группы разработчиков. Из-за нехватки времени мы не стали предписывать членам команды делать еще и бумажную работу, а предложили перевести все в рамки личного общения - бесед по телефону, телеконференций и поездок друг к другу на поезде. Уже через месяц персоналу удалось наладить свою работу, стабилизировался и план. Наконец-то вся история пришла к своему счастливому завершению. Мы сумели обнаружить все серьезные ошибки в дизайне на ранней стадии работ. Наш новый руководитель проекта сумел найти общий язык со своими подчиненными и хорошо отслеживал запланированные выпуски программы. Проект был закончен вовремя через год - в феврале. Все руководители были довольны как технической стороной проекта, так и по той причине, что общий план выпуска системы не изменился даже после мартовского пересмотра проекта. В этом проекте я впервые на практике применил схему с рис. 5 и с ее помощью последовательно менял методологию прямо в ходе проекта. Впрочем, неосознанно я пользовался всеми этими принципами и схемами, начиная с 1994 года. Вот еще несколько примеров, которые я привожу в порядке возрастания размеров проекта:

Интернет-проект по отслеживанию заказов в кафетерии относился к категории C4, иначе говоря, "самых дешевых" проектов. В нем не было никакой письменной документации, за исключением нескольких набросков вариантов использования. Вся работа проходила в совершенно неформальной обстановке, вплоть до того момента, когда было принято решение не разрабатывать эту систему самим, а купить уже готовый продукт (все в соответствии с приоритетами экономичных проектов). Проект Центрального банка Норвегии под названием BankLab представлял собой разработку прототипа для будущей критически важной банковской программной системы. Его можно отнести к категории С5: всю команду разработчиков посадили в одной комнате и постарались избавить от любых помех в работе. Руководитель и ведущий программист пришли к единому мнению относительно того, что привело проект к успеху: "Возьмите хороших специалистов, работайте небольшой командой, поместите всех в одну комнату, обеспечьте их необходимой информацией, а потом не мешайте". (Как сильно все это отличается от атмосферы работы над проектом Y2K в этом же банке!) Как я уже говорил, в проекте Chrysler Comprehensive Compensation (C3) использовалась методология "Extreme Programming". Они заменили всю письменную документацию непосредственным общением, рисованием у доски, индексными карточками и усиленным регрессионным тестированием. Были также и другие нововведения, которые подробно описаны в [XP, C3a, C3b, Beck99]: постоянная смена партнеров при парном программировании и поставки очередных версий системы каждые три недели. Если оперировать понятиями, которые мы ввели в этой статье, то они использовали те принципы, которые позволили натянуть методологию D6 на проект размера D14, и, таким образом, снизить расходы и повысить продуктивность. Проект под названием "Winifred" разрабатывался с использованием языка Smalltalk. Он попал в категорию D40, его главным приоритетом было "сделать в срок". Вся команда разработчиков размещалась в одном месте, внутренние коммуникации были на высоте. Ход работ над проектом и методология задокументирована и опубликована в [Cockburn98]. Я упоминаю этот проект в данном контексте, поскольку выбор методологии основывался на размере команды, близости рабочих мест, а также приоритетах и критичности самого проекта. Все эти факторы привели к увеличению роли непосредственного межличностного общения. Проект "Rishi" (язык Smalltalk) попал в категорию D90. Конечно, мы старались работать в максимально "легком" стиле, однако даже при этом нам понадобилось несколько команд проектировщиков. В этом проекте мы ввели специальную систему координирования работы внутри команды, куда входили различные собрания и документы. Изменения методологии в режиме реального времени И, наконец, последний из наиболее важных факторов при создании методологии - подгонка нужной методологии непосредственно в ходе работ. Коль скоро мы понимаем, что каждый проект заслуживает своей собственной методологии, то становится очевидно, что изначальные предположения о том, какую методологию следует использовать, это всего лишь наша первая попытка угадать, что же нам в действительности понадобится. Вот тут-то и становится заметна роль инкрементных разработок.

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

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

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

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

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

Библиография [Beck99] Beck, K., Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999.

[C3a] The "C3" Team, "Chrysler goes to 'Extremes'", in Distributed Object Computing, October, 1998, pp. 24-28.

[C3b] Jeffries, R., "Extreme testing", in Software Testing and Quality Engineering, March/April, 1999, pp. 23-26.

[Cockburn98] Cockburn, A., Surviving Object-Oriented Projects, Addison-Wesley, 1998.

[Crystal] Cockburn, A., Crystal/Clear: A Human-Powered Methodology for Small Teams, Addison-Wesley, 2000, in preparation, early version visible at http://members.aol.com/humansandt/crystal/clear.

[DeMarco99] DeMarco, T., Lister, T., Peopleware: Productive Projects and Teams, 2nd Ed., Dorset House, 1999.

[Graham97] Graham, I., Henderson-Sellers, B., Younessi, H., The OPEN Process Specification, Addison-Wesley, 1997.

[Harrison96] Harrison, N., Coplien, J, "Patterns of productive software organizations", Bell Labs Technical Journal, Summer, 1996, pp. 138-145.

[Highsmith] Highsmith, J., Adaptive Software Development, xxx press, 2000.

[Humphreys97] Humphreys, W., Introduction to the Personal Software Process, Addison-Wesley, 1997.

[Martin96] Martin, J., Odell, J., Object-oriented Methods, Pragmatic Considerations, Prentice Hall, 1996.

[Plowman95] Plowman, L., "The interfunctionality of talk and text", CSCW, vol. 3, 1995, pp.229-246.

[Sillince96] Sillince, J.A., "A model of social, emotional and symbolic aspects of computer-mediated communication within organizations", CSCW vol. 4, 1996, pp. 1-31.

[XP] Jeffries, R., Beck, K., et al.,Extreme Programming, as described on the web: http://extremeprogramming.com, http://armaties.com/extreme.html, http://c2.com/ppr/wiki/ExtremeProgrammingRoadmap/html.zip.

Дизайн и поддержка: Silicon Taiga

Обратиться по техническим вопросам