Каждому проекту своя методология
Шрифт:
Рисунок 1. Составляющие методологии (с примерами).
Методология включает в себя, по крайней мере, те предметы и темы, которые указаны на рис. 1: роли, навыки, команды разработчиков, инструментарий, техники, виды деятельности, стандарты, рабочие продукты, меры качества и систему ценностей, принятых в команде разработчиков. В большинстве своем, эти пункты не нуждаются в дополнительных объяснениях. Под "стандартами" мы имеем в виду нотационные стандарты (например, диаграммы и языки программирования), которые используются при выполнении
Менее очевидно, что такое "система ценностей, принятых в команде разработчиков". Под этим термином мы понимаем то, к чему стремится команда, как они предпочитают общаться и работать. Для команд с различными системами ценностей будут эффективны различные методологии.
У методологии есть "объем", который определяется протяженностью жизненного цикла проекта, разнообразием ролей и видов их деятельности, которые и пытается покрыть собой методология (см. рис. 2):
Рисунок 2. "Объем" методологии.
Некоторые компании работают по методологиям, которые покрывают весь процесс разработки программного продукта - от первого звонка клиента до поддержки и сопровождения уже работающей системы. При этом все роли оплачиваются из фондов проекта. Большая часть тех коммерческих книг, которые именуются "методологиями", посвящены, как правило, описанию только одной роли, а именно, роли проектировщика/программиста. В таких книгах рассказывается о том, как нужно проектировать, уделяется большое внимание нескольким различным техникам и стандартам изображения диаграмм. Если мы сравним тот объем задач, который должна охватывать методология, с той информацией, которая содержится в этих книгах, сразу станет понятно, почему у загруженных работой программистов такие "методологии" вызывают лишь досаду и раздражение. На самом деле, то, какие техники или стандарты изображения диаграмм использует проектировщик, создавая дизайн системы, не оказывает существенного влияния на конечный успех проекта, который конечно же, является наиболее важным фактором в любом бизнесе.
Принципы
Существенную роль в поисках нужной методологии играет определение принципов, по котором ее можно было бы разработать. После создания полудюжины различных методологий и проведения нескольких дюжин опросов и интервью разнообразных проектов, я сумел определить четыре основные принципа, которые и представляю вашему вниманию. На сегодняшний день я могу сказать, что практически уверен в справедливости любого из них. Ниже мы рассмотрим их использование.
Принцип 1. Большая по размерам методология нужна тогда, когда в проекте занято большое число разработчиков.
"Большей по размерам" я называю ту методологию, в которой содержится большое количество элементов. Поскольку главное предназначение любой методологии - координировать работу людей, то следовательно, чем больше проект, тем "больше" должна быть и используемая в нем методология. Объем методологии возрастает пропорционально числу ролей и типов рабочих продуктов. [Harrison96].
Этот принцип не позволит нам рассчитывать, что методология, которая хорошо зарекомендовала себя в маленькой команде, будет так же хорошо работать и в большой. Кроме того, он указывает на то, что не стоит употреблять методологию, рассчитанную на большую команду разработчиков, если над проектом работает небольшая группа программистов.
Принцип 2. Большая корректность методологии (видимая со
Я классифицирую программные системы по следующим категориям возможного ущерба (разумеется, этот список можно расширить):
Потеря комфорта в работе означает, что при поломке системы люди будут вынуждены больше работать вручную или же идти друг к другу для разговора, чтобы устранить помеху в коммуникации. Представьте, например, что ломается система, контролирующая процесс купли-продажи, или же программа, поддерживающая корпоративную инфраструктуру.
Потеря несущественной суммы означает, что утрата денежных или других сходных по значимости ценностей приносит компании некоторые неудобства, но не более. К этому типу можно отнести неправильную выплату зарплаты или неверные платежи по счетам (все это можно исправить вручную).
Потеря невосполнимой суммы означает, что утрата денежных или сходных по значимости средств фактически эквивалентна банкротству компании. В эту категорию можно отнести программные системы национальных банков и т.п.
Потеря жизни означает, что в результате ошибки в программе могут погибнуть люди. К этой категории относятся предприятия, работающие на атомной энергии, проекты, связанные с космосом, системы управления полетами самолетов и т.д. Согласно этому принципу, дополнительные затраты на более тщательную защиту от ошибок вполне могут себя оправдать - в зависимости от того, в какой из четырех вышеперечисленных категорий находится проект.
Поломка на атомной станции гораздо серьезнее, чем, например, поломка в моей программке, которая отслеживает течение матча по боулингу. Следовательно, при создании программных продуктов для атомной станции можно позволить себе использовать более трудоемкую и дорогую методологию. В этом случае, методология будет содержать большее количество различных элементов, причем эти элементы будут иметь большую "плотность".
Допустим, в обоих проектах используются варианты использования (use cases). Ребята из Лиги по боулингу вполне могут написать их в виде нескольких предложений на салфетке или на доске и считать это достаточным документом. Команда, которая строит атомную станцию, наверняка будет настаивать на том, чтобы все варианты использования были написаны с помощью специального инструментария, чтобы были заполнены все необходимые поля и т.д. После они обязательно потребуют пересмотра, внесения правок и многократного подписания документов в течение жизненного цикла проекта. При этом стоимость вторично написанных вариантов использования возрастает. Однако преимущество этого метода состоит в том, что чем большее количество "писателей" и "читателей" будут взаимодействовать между собой, тем меньше вероятность возникновения ошибок и недопонимания. Возрастающая стоимость разработок вполне оправдывается большей безопасностью и надежностью конечного продукта.
Принцип 2 указывает на то, что есть ситуации, когда дополнительные расходы на разработку оправдывают себя. И это хорошо, поскольку следующий Принцип, за номером 3, гласит, что более "тяжелая" методология ложится тяжким бременем на бюджет проекта.
Принцип 3. Незначительное увеличение "размеров" или "плотности" методологии ведет к существенному увеличению стоимости проекта.
Приостановка работы одной команды программистов для координации с другой командой требует не только дополнительного времени, но и дополнительной концентрации (см. обсуждение "потока" у ДеМарко [DeMarco99] и Коуберна [Cockburn98]). Для обновления документации, относящейся к требованиям, дизайну системы и тестированию, тоже понадобится немало времени.