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

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

Рисунок 5. Методологии, организованные по принципу люди х критичность х приоритетность.

На рисунке 5 вы видите семь возможных размеров проекта и четыре зоны его критичности. Такое деление достаточно условно, хотя и правдоподобно - мой опыт подсказывает, что именно такие показатели свидетельствуют о необходимости изменения характера методологии, применяемой в проекте. Каждой ячейке схемы может одновременно соответствовать сразу несколько различных методологий. Выбор будет зависеть от предпочтений спонсоров проекта - ставят ли они на первое место производительность, обозреваемость, повторяемость или корректность процесса. "Размер" методологии растет по мере приближения к правой стороне схемы (больше людей, больше коммуникационных элементов в методологии), а "плотность" - к верхней ее части (более строгий контроль). Согласно Принципу 3, чем правее или выше, тем больше стоимость разработки проекта, поэтому те, кто озабочен экономической стороной вопроса, должны постараться разместить свой проект как можно левее и ниже. Бывают ситуации, когда прочие стимулы, например, престиж руководителя проекта или безопасность собственной карьеры, могут заставить вас считать проект "более значительным и критичным", даже если это приведет к увеличению стоимости разработок.

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

Мой опыт в различных проектах

В Центральном Банке Норвегии работает около 40 штатных программистов и вполовину меньше контрактников, и надо сказать, им приходится решать на удивление много разнообразных задач.

В то время, когда я там находился, основным проектом был проект Y2K, в котором было занято 35 человек. Главной целью здесь являлось предотвращение крушения банковской системы Норвегии, которое могло состояться 1 января 2000 года. Критичность проекта соответствовала "потере невосполнимой суммы", главными приоритетами были своевременность и корректность проекта. Основополагающей технологией являлись традиционные большие ЭВМ.

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

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

Один программист использовал язык SQL для формирования различных обобщающих отчетов, касающихся инвестиций и затрат. Еще один проект был начат для того, чтобы заменить существующие системы, работающие на больших ЭВМ, на распределенные системы, использующие Интернет-технологии, объектно-ориентированный подход и компонентную архитектуру, построенную на базе CORBA/Java. Были еще и другие проекты, но я думаю, что упомянул уже достаточно, чтобы читатель получил общее представление о ситуации. Как мне кажется, в подобном случае невозможно говорить о какой-то одной методологии, которая была бы "правильной" для всего этого разнообразия задач и проектов.

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