Сколько себя помню - всегда руководствовался принципом Алистэра Коуберна (Alistair Cockburn) "Каждому проекту своя методология" ( 'Methodology per project'). Неудивительно, что "продолжение" этого принципа в виде статьи "Каждой методологии - свое время" ('Just-in-time methodology construction') вызвало у меня немалый интерес. Русский перевод названия на мой взгляд немного неточен, я бы перевёл как "Построение методологии по ходу проекта", однако существующий перевод весма оправдан своей созвучностью со статьёй-предшественницей.

Данная статья базируется на ещё одной известнейшей статье Алистера - "Люди как наиболее важные компоненты процесса разработки ПО" ('Characterizing people as non-linear, first-order components in software development'), о которой я уже писал

Идея статьи проста, очень логична, и в то же время революционна:

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

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

Ответ на этот вопрос, конечно же, существует не один. Коуберн выделяет следующие ключевые моменты:

 - Разработка ведется инкрементным методом. Насколько я могу судить, это единственное необходимое методологическое условие.
 - После каждого инкремента проводите общее собрание, на котором задавайте один-единственный вопрос: "Что мы могли бы делать лучше?"
 - Берите за основу сильные стороны человеческой натуры

Результатом работы Коуберна стала разработка целого семейства методологий Crystal. Метологии внутри этого семейства различаются по 3-м критериям: люди, критичность, приоритетность.

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

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