Каждому проекту своя методология (ЛП)

Как я уже говорил, в проекте 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.