"Каждому проекту своя методология" - читать интересную книгу автора (Коуберн Алистэр)

Компоненты и объем методологии

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

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

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

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

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

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

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

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

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