Алистэр Коуберн - Каждому проекту своя методология

( #mailto:arc@acm.org Алистэр Коуберн Каждому проекту своя методология ( #mailto:arc@acm.org ) Humans and Technology Humans and Technology Technical Report, TR 99.04, Oct.1999 7691 Dell Rd, Salt Lake City, UT 84121 USA arc@acm.org Original article )

Humans and Technology

Humans and Technology Technical Report, TR 99.04, Oct.1999 7691 Dell Rd, Salt Lake City, UT 84121 USA

arc@acm.org

Original article Алистэр Коуберн Каждому проекту своя методология ( #mailto:arc@acm.org Алистэр Коуберн Каждому проекту своя методология ( #mailto:arc@acm.org ) Humans and Technology Humans and Technology Technical Report, TR 99.04, Oct.1999 7691 Dell Rd, Salt Lake City, UT 84121 USA arc@acm.org Original article ) Humans and Technology Humans and Technology Technical Report, TR 99.04, Oct.1999 7691 Dell Rd, Salt Lake City, UT 84121 USA arc@acm.org Original article

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

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

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

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

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

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

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

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

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

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

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

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

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