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

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

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

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

Проект Центрального банка Норвегии под названием BankLab представлял собой разработку прототипа для будущей критически важной банковской программной системы. Его можно отнести к категории С5: всю команду разработчиков посадили в одной комнате и постарались избавить от любых помех в работе. Руководитель и ведущий программист пришли к единому мнению относительно того, что привело проект к успеху: "Возьмите хороших специалистов, работайте небольшой командой, поместите всех в одну комнату, обеспечьте их необходимой информацией, а потом не мешайте". (Как сильно все это отличается от атмосферы работы над проектом Y2K в этом же банке!)

Как я уже говорил, в проекте Chrysler Comprehensive Compensation (C3) использовалась методология "Extreme Programming". Они заменили всю письменную документацию непосредственным общением, рисованием у доски, индексными карточками и усиленным регрессионным тестированием. Были также и другие нововведения, которые подробно описаны в [XP, C3a, C3b, Beck99]: постоянная смена партнеров при парном программировании и поставки очередных версий системы каждые три недели. Если оперировать понятиями, которые мы ввели в этой статье, то они использовали те принципы, которые позволили натянуть методологию D6 на проект размера D14, и, таким образом, снизить расходы и повысить продуктивность.

Проект под названием "Winifred" разрабатывался с использованием языка Smalltalk. Он попал в категорию D40, его главным приоритетом было "сделать в срок". Вся команда разработчиков размещалась в одном месте, внутренние коммуникации были на высоте. Ход работ над проектом и методология задокументирована и опубликована в [Cockburn98]. Я упоминаю этот проект в данном контексте, поскольку выбор методологии основывался на размере команды, близости рабочих мест, а также приоритетах и критичности самого проекта. Все эти факторы привели к увеличению роли непосредственного межличностного общения.

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

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