Каждой методологии - свое время
Страница 4. Семейства методологий

Семейства методологий

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

Рисунок 1. Методологии, организованные по принципу люди х критичность х приоритетность (взято из [Co2]).

Таким образом, у нас уже есть все необходимые элементы для описания семейства методологий, обладающих динамической природой и повышенной чувствительностью к чертам человеческой натуры. Одно такое семейство я назвал Crystal. Семейство методологий Crystal в настоящее время разрабатывается в работах [Co4] и [Co5], поэтому в данной статье я опишу только наиболее яркие его характеристики.

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

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

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

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

Все методологии Crystal различаются по цвету, причем каждый цвет предназначен для определенных проектов и имеет свои собственные характеристики: "Прозрачная" для самых легких и небольших проектов, затем "Желтая", "Оранжевая", "Красная", "Малиновая", "Синяя", "Фиолетовая" и т.д., для больших команд, использующих более тяжелые методологии.

Рисунок 2. Методологии Crystal различаются по цвету

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

Crystal "Оранжевая"

Этот вид методологии кратко описан в работе автора [Co3] (хотя имя "Crystal" в ней было опущено). В этой работе даются следующие характерные черты проектов, для которых предназначена эта методология:

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

• общее количество занятых в проекте людей от 10 до 40
• продолжительность работ от 1 до 2 лет
• важно своевременное появление продукта на рынке
• нужно поддерживать общение между нынешними и будущими разработчиками, а также снижать временные и финансовые расходы
• критичность: не жизненно-важная

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

"Оранжевая" методология семейства Crystal относится к методологии "D40". Это означает, что она подходит для команды общей численностью не выше 40 человек, работающей в одном здании над разработкой системы, сбой которой может привести к потере несущественной суммы (сюда можно отнести, например, программу учета платежей компании). Для "Оранжевой" методологии нужна бОльшая структуризация и координация команды, чем для проекта, над которым работают 20 человек. Однако она не предусматривает четкого деления команды на подгруппы (как это необходимо при работе над проектом, в котором задействовано, например, 80 человек) и не предполагает строгой проверки дизайна и кода системы (как это необходимо для жизненно-важных проектов). В зависимости от команды, "Оранжевую" методологию можно использовать также для проектов типа "E50".

Вкратце, для "Оранжевой" методологии семейства Crystal характерны следующие моменты (подробнее см. в [Co3]):

• Роли включают в себя спонсора (Sponsor), эксперта в данном виде бизнеса (Business expert), эксперта по использованию системы (Usage expert), технического посредника (Technical facilitator), бизнес-аналитика/проектировщика (Business analyst/designer), руководителя проекта (Project Manager), архитектора (Architect, Design Mentor), проектировщика/программиста (Designer/programmer), ведущего проектировщика/программиста (Lead designer/ programmer), инженера по повторному использованию (Reuse Point), писателя (Writer), тестировщика (Tester), дизайнера интерфейсов (UI designer).
• Все сотрудники распределяются по командам, которые отвечают, соответственно, за планирование, руководство, архитектуру, технологии, функционирование, инфраструктуру и внешнее тестирование.
• Методологические стандарты: программный продукт проходит процесс контроля качества каждые 3 + 1 месяц; прогресс в работе отслеживается по контрольным точкам поставки частей системы, а не по документации; применяется автоматическое регрессивное тестирование функциональности системы, в работах непосредственным образом участвуют пользователи системы, по два пользователя на релиз, вспомогательные виды деятельности начинаются только тогда, когда сама система оказывается достаточно стабильной для ее проверки пользователями. "Настройка" методологии осуществляется на собраниях в начале и середине каждого инкремента.
• Все эти правила обязательны, однако при необходимости их можно замещать другими, например, методами планирования Scrum [Scr], практиками eXtreme Programming или Adaptive Software Development [Hi].
• Что касается рабочих продуктов, то к ним относятся: документ с требованиями к системе, план релизов, отчеты о состоянии работ по проекту, документ, описывающий дизайн интерфейсов, общая объектная модель системы, внутрикомандные спецификации, руководство для пользователя, исходный код, тесты и код для миграции с предыдущей системы. Каждый из упомянутых здесь продуктов дорабатывается до той степени, при которой его начнут понимать коллеги по работе, а именно до уровня детализации, допускающего попарную работу.
• Все шаблоны для рабочих продуктов, стандарты кодирования, стандарты построения пользовательских интерфейсов и детали, касающиеся регрессивного тестирования, считаются локальными стандартами, то есть их должна вырабатывать и поддерживать сама команда разработчиков.
• Что касается стиля работы для каждой конкретной роли, то он всецело зависит от индивида, который эту роль выполняет.

Crystal "Прозрачная"

Для сравнения давайте обратимся к самой легкой из всех методологий этого семейства.

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

Для этого типа методологии обязательны только следующие условия (см. подробнее в работе автора [Co4]):

• Отдельные роли: спонсор (Sponsor), старший дизайнер (Senior designer), дизайнер-программист (Designer/programmer) и пользователь (User), последний может даже работать не полный рабочий день. Все остальные роли распределяются между членами команды: координатор проекта (Project Coordinator), эксперт в данном виде бизнеса (Business Expert), сборщик требований (Requirements Gatherer).
• Над проектом работает только одна команда.
• Методологические стандарты те же, что и в "Оранжевой" методологии, за исключением того, что каждый инкремент длится не более двух месяцев.
• Требуется меньшее количество рабочих продуктов: план релизов, план просмотра системы пользователями и план поставок, снабженные пояснениями варианты использования системы, наброски по дизайну системы и интерфейсам, различные заметки, общая объектная модель системы, работающий код, код миграции, тесты и руководство для пользователя.
• Шаблоны для рабочих продуктов, стиль кодирования, стандарты построения пользовательских интерфейсов и детали, касающиеся регрессивного тестирования, точно так же считаются локальными стандартами, которые должна вырабатывать и поддерживать сама команда разработчиков.
• Опять-таки, все, что касается стиля работы для каждой конкретной роли, всецело зависит от индивида, который эту роль выполняет, и от команды. Можно применять правила, принятые в других методологиях (например, в Scrum и eXtreme Programming).

eXtreme Programming (у нас уже почти прижилось название "Экстремальное программирование" -- прим. перев.) можно считать одним из вариантов "Прозрачной" методологии, хотя у нее есть одно довольно существенное отличие от нее. Как и в других методологиях такого плана, здесь используются частые релизы, тесное общение, наличие пользователя в команде разработчиков, автоматическое регрессивное тестирование, повышенное внимание к боевому духу команды, упор на устную культуру общения. Эту методологию можно отнести к разряду "D6", однако ее можно с успехом "натянуть" на проект из разряда "D14" (см. [C3]).

При всем этом eXtreme Programming и "Прозрачная" методология семейства Crystal придерживаются диаметрально противоположных взглядов на дисциплину и толерантность. ХР находится в стороне от всех прочих методологий подобного типа, так как ее отличают самое незначительное использование письменных рабочих продуктов и самые строгие правила ведения работ. Она базируется на строгом следовании правилам программирования и дизайна, парном программировании, 100%-ном модульном тестировании. И, как это логично следует из общих характеристик методологии, требующей жесткой дисциплины от сотрудников, она вводит роль "наставника", а также некоторые другие механизмы, позволяющие контролировать соблюдение всех своих правил.

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

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