Каждому проекту своя методология
Шрифт:
Рисунок 4. Эффективность коммуникации
Однако это "правило коммуникации" вовсе не означает, что любой программный продукт должен быть разработан несколькими людьми, сидящими в одной комнате. Автор методологии должен знать, что если первоочередными факторами являются продуктивность и стоимость программных разработок, то необходимо уделить особое внимание работе небольшими командами и непосредственному общению между сотрудниками (как, например, это сделано в Extreme Programming [XP]). Этот вывод подтвержден исследованиями [Plowman95]. Кроме того, в работе Силлинса [Sillince96] приводится обсуждение различных аспектов коммуникации внутри одной организации.
И еще два фактора
При
В некоторых методологиях приоритеты заметны сразу, в некоторых нет. Так, например, объектно-ориентированная методология Мартина и Оделла [Martin96] достаточно общая и подходит для многих случаев, однако не совсем понятно, на что конкретно она направлена, и можно ли менять эту "направленность" для работы над различными проектами. Семейство методологий OPEN [BHS97], по всей видимости, основной целью полагает корректность программных продуктов, явность и повторяемость процесса. Методология под названием The Personal Software Process of Humphreys [Humphreys97] была разработана для обеспечения предсказуемости работ.
В трех последних методологиях о приоритетах говорится открыто: авторы семейства методологий Crystal [Cockburn98, Crystal] и Extreme Programming [XP, Beck99] заявили, что их методологии направлены, в первую очередь, на повышение продуктивности и снижение стоимости работ. При этом они все же отличаются друг от друга - Crystal призывает совмещать производительность и толерантность, в отличие от ХР, где продуктивность возрастает как раз за счет уменьшения толерантности. Методология "Adaptive Software Development", детище Джима Хайсмита [Highsmith], разработана специально для крайне нестабильных ситуаций в разработках, когда требования, проектирование и невозможно короткие сроки являются функциями друг друга и постоянно меняются (так зачастую происходит в веб-разработках).
Методология и ее автор
"Любая методология основывается на страхе", - написал как-то Кент Бек в одном из обсуждений методологий. Поначалу это замечание показалось мне малозначительным, но потом я понял, что в большинстве случаев, оно совершенно справедливо. Каждый элемент методологии призван предотвратить появление тех проблем, с какими автор методологии уже сталкивался в прошлом. Боитесь, что программисты сделают в коде много ошибок? Не забывайте о проверках кода. Вам кажется, что заказчики сами не знают, чего им надо? Создавайте прототипы пользовательских интерфейсов. Опасаетесь, что проектировщики уйдут в самый разгар работы? Сделайте так, чтобы они писали подробную документацию всего, что делают. Если бы методологи могли (или хотели) явно обозначить свои основные страхи и пожелания, цель методологии была бы ясна с первого же взгляда.
И, наконец, в качестве последней составляющей характеристики методологии, мы должны упомянуть индивидуальную философию ее автора. Эта философия оформляется в процессе приобретения автором личного опыта, а также экстраполяций, сделанных на основе этого опыта. Чтобы методология "подошла" определенному проекту, она должна соответствовать философии и страхам как команды разработчиков, так и самого автора методологии.
Каждому проекту своя методология
В предыдущих разделах статьи мы уже показали, что существует множество различных методологий (и это совершенно естественно) - см. рис. 5. Все они отличаются друг от друга с точки зрения количества занятых в проекте людей, критичности проекта, приоритетов и, возможно, философии разработчиков.
Рисунок 5.
На рисунке 5 вы видите семь возможных размеров проекта и четыре зоны его критичности. Такое деление достаточно условно, хотя и правдоподобно - мой опыт подсказывает, что именно такие показатели свидетельствуют о необходимости изменения характера методологии, применяемой в проекте. Каждой ячейке схемы может одновременно соответствовать сразу несколько различных методологий. Выбор будет зависеть от предпочтений спонсоров проекта - ставят ли они на первое место производительность, обозреваемость, повторяемость или корректность процесса. "Размер" методологии растет по мере приближения к правой стороне схемы (больше людей, больше коммуникационных элементов в методологии), а "плотность" - к верхней ее части (более строгий контроль). Согласно Принципу 3, чем правее или выше, тем больше стоимость разработки проекта, поэтому те, кто озабочен экономической стороной вопроса, должны постараться разместить свой проект как можно левее и ниже. Бывают ситуации, когда прочие стимулы, например, престиж руководителя проекта или безопасность собственной карьеры, могут заставить вас считать проект "более значительным и критичным", даже если это приведет к увеличению стоимости разработок.
Самое замечательное, что эта схема действительно приблизительно соответствует реальному положению дел. Мы можем сосчитать количество занятых в проекте людей, обсудить его критичность и приоритеты. Используя описанные выше принципы, мы можем принять некие базовые решения относительно того, какую методологию следует использовать в данном конкретном проекте. В конце концов, все остальное решают личные предпочтения. Ниже я приведу несколько примеров из личного опыта и расскажу, как мне самому удавалось применять эти идеи и принципы на практике.
Мой опыт в различных проектах
В Центральном Банке Норвегии работает около 40 штатных программистов и вполовину меньше контрактников, и надо сказать, им приходится решать на удивление много разнообразных задач.
В то время, когда я там находился, основным проектом был проект Y2K, в котором было занято 35 человек. Главной целью здесь являлось предотвращение крушения банковской системы Норвегии, которое могло состояться 1 января 2000 года. Критичность проекта соответствовала "потере невосполнимой суммы", главными приоритетами были своевременность и корректность проекта. Основополагающей технологией являлись традиционные большие ЭВМ.
В то же самое время шла работа над другим, внутренним проектом, который заключался в создании программы для банковского персонала. Она включала в себя возможность заказывать обед в кафетерии и отслеживать статус сделанных заказов - и все это в виде веб-приложения. Над этой задачей работало один-два человека, которые использовали Delphi или Java и Интернет-браузер. Критичность проекта соответствовала "потере комфорта", приоритеты - сделать быстро и без особых затрат.
Та же группа программистов несла ответственность за работу над системой, которая должна была собирать и проверять все данные о межбанковских транзакциях в стране, причем эти разработки велись вместе с еще одной компанией. В проекте, который я сейчас опишу более подробно, тоже использовались большие ЭВМ.
Один программист использовал язык SQL для формирования различных обобщающих отчетов, касающихся инвестиций и затрат. Еще один проект был начат для того, чтобы заменить существующие системы, работающие на больших ЭВМ, на распределенные системы, использующие Интернет-технологии, объектно-ориентированный подход и компонентную архитектуру, построенную на базе CORBA/Java. Были еще и другие проекты, но я думаю, что упомянул уже достаточно, чтобы читатель получил общее представление о ситуации. Как мне кажется, в подобном случае невозможно говорить о какой-то одной методологии, которая была бы "правильной" для всего этого разнообразия задач и проектов.