Рисунок 5. Методологии, организованные по принципу люди х критичность х приоритетность.
На рисунке 5 вы видите семь возможных размеров проекта и четыре зоны его критичности. Такое деление достаточно условно, хотя и правдоподобно - мой опыт подсказывает, что именно такие показатели свидетельствуют о необходимости изменения характера методологии, применяемой в проекте. Каждой ячейке схемы может одновременно соответствовать сразу несколько различных методологий. Выбор будет зависеть от предпочтений спонсоров проекта - ставят ли они на первое место производительность, обозреваемость, повторяемость или корректность процесса. "Размер" методологии растет по мере приближения к правой стороне схемы (больше людей, больше коммуникационных элементов в методологии), а "плотность" - к верхней ее части (более строгий контроль). Согласно Принципу 3, чем правее или выше, тем больше стоимость разработки проекта, поэтому те, кто озабочен экономической стороной вопроса, должны постараться разместить свой проект как можно левее и ниже. Бывают ситуации, когда прочие стимулы, например, престиж руководителя проекта или безопасность собственной карьеры, могут заставить вас считать проект "более значительным и критичным", даже если это приведет к увеличению стоимости разработок.
Самое замечательное, что эта схема действительно приблизительно соответствует реальному положению дел. Мы можем сосчитать количество занятых в проекте людей, обсудить его критичность и приоритеты. Используя описанные выше принципы, мы можем принять некие базовые решения относительно того, какую методологию следует использовать в данном конкретном проекте. В конце концов, все остальное решают личные предпочтения. Ниже я приведу несколько примеров из личного опыта и расскажу, как мне самому удавалось применять эти идеи и принципы на практике.
Мой опыт в различных проектах
В Центральном Банке Норвегии работает около 40 штатных программистов и вполовину меньше контрактников, и надо сказать, им приходится решать на удивление много разнообразных задач.
В то время, когда я там находился, основным проектом был проект Y2K, в котором было занято 35 человек. Главной целью здесь являлось предотвращение крушения банковской системы Норвегии, которое могло состояться 1 января 2000 года. Критичность проекта соответствовала "потере невосполнимой суммы", главными приоритетами были своевременность и корректность проекта. Основополагающей технологией являлись традиционные большие ЭВМ.
В то же самое время шла работа над другим, внутренним проектом, который заключался в создании программы для банковского персонала. Она включала в себя возможность заказывать обед в кафетерии и отслеживать статус сделанных заказов - и все это в виде веб-приложения. Над этой задачей работало один-два человека, которые использовали Delphi или Java и Интернет-браузер. Критичность проекта соответствовала "потере комфорта", приоритеты - сделать быстро и без особых затрат.
Та же группа программистов несла ответственность за работу над системой, которая должна была собирать и проверять все данные о межбанковских транзакциях в стране, причем эти разработки велись вместе с еще одной компанией. В проекте, который я сейчас опишу более подробно, тоже использовались большие ЭВМ.
Один программист использовал язык SQL для формирования различных обобщающих отчетов, касающихся инвестиций и затрат. Еще один проект был начат для того, чтобы заменить существующие системы, работающие на больших ЭВМ, на распределенные системы, использующие Интернет-технологии, объектно-ориентированный подход и компонентную архитектуру, построенную на базе CORBA/Java. Были еще и другие проекты, но я думаю, что упомянул уже достаточно, чтобы читатель получил общее представление о ситуации. Как мне кажется, в подобном случае невозможно говорить о какой-то одной методологии, которая была бы "правильной" для всего этого разнообразия задач и проектов.
Что касается меня, то я работал над проектом, связанным с межбанковскими транзакциями, а также над внутренним Интернет-проектом для отслеживания заказов. Первый из них был особенно интересен, так как за время работы над ним его пришлось дважды "передвигать" из одной клетки нашей "методологической решетки" (рис. 5) в другую.
В ноябре мне сказали, что этот проект рассчитан на 15 рабочих недель, что всего в разработках участвует 3 человека, что дизайн программы уже практически завершен, и что у людей есть сходный опыт работы над предыдущей версией системы. Исходя из изложенной выше схемы методологий и моего собственного опыта, я предположил, что этот проект соответствует позиции D4 на схеме, а это означало, что трем разработчикам следует создавать систему просто работая сообща, обращая минимум внимания на всякие бюрократические штучки (нашей стандартной фразой было: "сделай свою работу и иди домой").
Впрочем, вскоре оказалось, что вся задача была оценена приблизительно, и к тому же, только частично. Мы провели дополнительные вычисления, и оказалось, что этот проект должен быть рассчитан на 130 рабочих недель. Кроме того, мы пересмотрели идею насчет того, что все три программиста могут работать в разных городах. В процессе работы использовались новые технологии, требовалось внедрение новой, более чувствительной схемы обработки ошибок, система должна была работать в реальном времени, и вдобавок обнаружились проблемы со взаимоисключающим доступом внутри основной базы данных. Кроме того, выяснилось, что им нужно еще и работать вместе с другой командой, которая находилась в другой части города. Ведущий архитектор через два месяца уходил в отпуск по уходу за ребенком, руководитель проекта не имел опыта работы ни в IT сфере, ни в руководстве проектами, а между тем, отчетность по проекту должна была осуществляться на высоком государственном уровне.
В этот момент я решил перевести наш проект в категорию E5. Это означало переход к инкрементным разработкам, планированию выпусков системы с минимальным риском, еженедельные телеконференции всей группы разработчиков, ежемесячный доклад о положении дел и т.д.
Первая итерация прошла в начале февраля, и прошла в срок. Однако сразу после этого ушел в отпуск архитектор, одного из ведущих программистов перебросили на проект "по борьбе с ошибкой 2000 года", а мы обнаружили ошибку в проектных решениях, отвечающих за восстановление после ошибочных ситуаций и за контроль над взаимоисключающим доступом. Теперь на наш проект отвели уже десять человек, большинство которых не имело опыта работы в данной области, к тому же работали в совершенно разных местах. Обычные каждодневные встречи и общение были попросту невозможны.
В середине февраля я решил, что проект пора переводить в категорию E15. Мы разработали более подробный план поставок для каждого разработчика, запустили программу моделирования тестов, стали уделять большее внимание общению с каждым из группы разработчиков. Из-за нехватки времени мы не стали предписывать членам команды делать еще и бумажную работу, а предложили перевести все в рамки личного общения - бесед по телефону, телеконференций и поездок друг к другу на поезде.
Уже через месяц персоналу удалось наладить свою работу, стабилизировался и план. Наконец-то вся история пришла к своему счастливому завершению. Мы сумели обнаружить все серьезные ошибки в дизайне на ранней стадии работ. Наш новый руководитель проекта сумел найти общий язык со своими подчиненными и хорошо отслеживал запланированные выпуски программы. Проект был закончен вовремя через год - в феврале. Все руководители были довольны как технической стороной проекта, так и по той причине, что общий план выпуска системы не изменился даже после мартовского пересмотра проекта. В этом проекте я впервые на практике применил схему с рис. 5 и с ее помощью последовательно менял методологию прямо в ходе проекта. Впрочем, неосознанно я пользовался всеми этими принципами и схемами, начиная с 1994 года. Вот еще несколько примеров, которые я привожу в порядке возрастания размеров проекта:
Интернет-проект по отслеживанию заказов в кафетерии относился к категории C4, иначе говоря, "самых дешевых" проектов. В нем не было никакой письменной документации, за исключением нескольких набросков вариантов использования. Вся работа проходила в совершенно неформальной обстановке, вплоть до того момента, когда было принято решение не разрабатывать эту систему самим, а купить уже готовый продукт (все в соответствии с приоритетами экономичных проектов).
Проект Центрального банка Норвегии под названием BankLab представлял собой разработку прототипа для будущей критически важной банковской программной системы. Его можно отнести к категории С5: всю команду разработчиков посадили в одной комнате и постарались избавить от любых помех в работе. Руководитель и ведущий программист пришли к единому мнению относительно того, что привело проект к успеху: "Возьмите хороших специалистов, работайте небольшой командой, поместите всех в одну комнату, обеспечьте их необходимой информацией, а потом не мешайте". (Как сильно все это отличается от атмосферы работы над проектом Y2K в этом же банке!)
Как я уже говорил, в проекте Chrysler Comprehensive Compensation (C3) использовалась методология "Extreme Programming". Они заменили всю письменную документацию непосредственным общением, рисованием у доски, индексными карточками и усиленным регрессионным тестированием. Были также и другие нововведения, которые подробно описаны в [XP, C3a, C3b, Beck99]: постоянная смена партнеров при парном программировании и поставки очередных версий системы каждые три недели. Если оперировать понятиями, которые мы ввели в этой статье, то они использовали те принципы, которые позволили натянуть методологию D6 на проект размера D14, и, таким образом, снизить расходы и повысить продуктивность.
Проект под названием "Winifred" разрабатывался с использованием языка Smalltalk. Он попал в категорию D40, его главным приоритетом было "сделать в срок". Вся команда разработчиков размещалась в одном месте, внутренние коммуникации были на высоте. Ход работ над проектом и методология задокументирована и опубликована в [Cockburn98]. Я упоминаю этот проект в данном контексте, поскольку выбор методологии основывался на размере команды, близости рабочих мест, а также приоритетах и критичности самого проекта. Все эти факторы привели к увеличению роли непосредственного межл