Текст книги "Каждому проекту своя методология"

Автор книги: Алистэр Коуберн

сообщить о нарушении

Текущая страница: 1 (всего у книги 4 страниц)

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

( [email protected]

[Закрыть])

Humans and Technology

Humans and Technology Technical Report, TR 99.04, Oct.1999 7691 Dell Rd, Salt Lake City, UT 84121 USA

[email protected]

Original article

[Закрыть]

Краткий обзор

«Методология с большой буквы» – это название того, как организация многократно производит и поставляет программные системы: кого в ней нанимают на работу и зачем, чего ожидают люди от своих коллег, какие условности они соблюдают, начиная от размещения рабочих мест в офисе и до используемых рабочих продуктов. Когда какая-то компания помещает в газете объявление о приеме на работу, это объявление представляет собой некий артефакт принятой в этой компании методологии. Как оказалось, чтобы получить практические результаты от изучения методологии, мы должны рассматривать ее именно с такой широкой точки зрения.

В данном случае, моей целью было создать откровенный диалог между людьми, придерживающимися различных взглядов на этот вопрос, и обозначить принципы, согласно которым можно рекомендовать ту или иную методологию. Итак, сначала нам надлежит ответить на следующие вопросы: Что же такое "методология"? Должно ли методологий быть много? Может ли одна быть "лучше", чем другая? Как узнать, какие элементы методологии стоит перенимать? Как применить все эти знания в крупном проекте?

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

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

Компоненты и объем методологии

Под «методологией» я понимаю то, что написано в качестве первого толкования этого слова в Американском словаре Miriam-Webster: «ряд связанных между собой методов или техник». Оксфордский словарь толкует это слово только как «изучение методов». В этой статье я использую американский вариант. ( Для интересующихся: в «Толковом словаре русского языка» Ожегова это слово трактуется как «принципы и способы организации теоретической и практической деятельности» и «совокупность методов, применяемых в какой-либо науке». – прим. переводчиков )

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

Я буду говорить также о "размере проекта". Под этим термином я подразумеваю число людей, работающих над проектом, деятельность которых необходимо координировать. Нередко возникает мнение, что размер проекта соответствует размерам задачи, но все не так просто. Размер задачи нельзя определить в абсолютных величинах, так как всегда может появиться новый человек, который сумеет разглядеть в этой задаче некоторый упрощающий паттерн. Именно поэтому я старательно разграничиваю понятия "размер проекта" и "размер задачи".

Рисунок 1. Составляющие методологии (с примерами).

Методология включает в себя, по крайней мере, те предметы и темы, которые указаны на рис. 1: роли, навыки, команды разработчиков, инструментарий, техники, виды деятельности, стандарты, рабочие продукты, меры качества и систему ценностей, принятых в команде разработчиков. В большинстве своем, эти пункты не нуждаются в дополнительных объяснениях. Под "стандартами" мы имеем в виду нотационные стандарты (например, диаграммы и языки программирования), которые используются при выполнении данного проекта. Есть также стандарты управления и принятия решений, например, использование инкрементных разработок. И, наконец, у нас есть некоторая система условностей – стандартов, которые определяются для данного конкретного проекта.

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

У методологии есть "объем", который определяется протяженностью жизненного цикла проекта, разнообразием ролей и видов их деятельности, которые и пытается покрыть собой методология (см. рис. 2):

Рисунок 2. «Объем» методологии.

Некоторые компании работают по методологиям, которые покрывают весь процесс разработки программного продукта – от первого звонка клиента до поддержки и сопровождения уже работающей системы. При этом все роли оплачиваются из фондов проекта. Большая часть тех коммерческих книг, которые именуются «методологиями», посвящены, как правило, описанию только одной роли, а именно, роли проектировщика/программиста. В таких книгах рассказывается о том, как нужно проектировать, уделяется большое внимание нескольким различным техникам и стандартам изображения диаграмм. Если мы сравним тот объем задач, который должна охватывать методология, с той информацией, которая содержится в этих книгах, сразу станет понятно, почему у загруженных работой программистов такие «методологии» вызывают лишь досаду и раздражение. На самом деле, то, какие техники или стандарты изображения диаграмм использует проектировщик, создавая дизайн системы, не оказывает существенного влияния на конечный успех проекта, который конечно же, является наиболее важным фактором в любом бизнесе.

Принципы

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

Принцип 1. Большая по размерам методология нужна тогда, когда в проекте занято большое число разработчиков.

"Большей по размерам" я называю ту методологию, в которой содержится большое количество элементов. Поскольку главное предназначение любой методологии – координировать работу людей, то следовательно, чем больше проект, тем "больше" должна быть и используемая в нем методология. Объем методологии возрастает пропорционально числу ролей и типов рабочих продуктов. [Harrison96].

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

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

Я классифицирую программные системы по следующим категориям возможного ущерба (разумеется, этот список можно расширить):

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

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

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

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

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

Допустим, в обоих проектах используются варианты использования (use cases). Ребята из Лиги по боулингу вполне могут написать их в виде нескольких предложений на салфетке или на доске и считать это достаточным документом. Команда, которая строит атомную станцию, наверняка будет настаивать на том, чтобы все варианты использования были написаны с помощью специального инструментария, чтобы были заполнены все необходимые поля и т.д. После они обязательно потребуют пересмотра, внесения правок и многократного подписания документов в течение жизненного цикла проекта. При этом стоимость вторично написанных вариантов использования возрастает. Однако преимущество этого метода состоит в том, что чем большее количество "писателей" и "читателей" будут взаимодействовать между собой, тем меньше вероятность возникновения ошибок и недопонимания. Возрастающая стоимость разработок вполне оправдывается большей безопасностью и надежностью конечного продукта.

Принцип 2 указывает на то, что есть ситуации, когда дополнительные расходы на разработку оправдывают себя. И это хорошо, поскольку следующий Принцип, за номером 3, гласит, что более "тяжелая" методология ложится тяжким бременем на бюджет проекта.

Принцип 3. Незначительное увеличение "размеров" или "плотности" методологии ведет к существенному увеличению стоимости проекта.

Приостановка работы одной команды программистов для координации с другой командой требует не только дополнительного времени, но и дополнительной концентрации (см. обсуждение "потока" у ДеМарко [DeMarco99] и Коуберна [Cockburn98]). Для обновления документации, относящейся к требованиям, дизайну системы и тестированию, тоже понадобится немало времени.

Этот принцип справедлив для любого проекта. Как вы уже заметили, мы не обсуждаем, выгодны или не выгодны компании дополнительные затраты – здесь затрагивается исключительно вопрос стоимости, не более. Проблема определения сообразности дополнительных расходов относится к Принципу 2.

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

Размеры проекта и методологии связаны между собой положительной обратной связью. Если над проектом работает сравнительно немного людей, то им нужна сравнительно небольшая методология. Чем меньше "весит" методология, тем продуктивнее работает команда. А чем продуктивнее работают люди, тем больше задач они могут решать – иначе говоря, маленькая команда разработчиков, использующая "легкую" методологию, вполне способна решать крупномасштабные задачи.

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

Именно поэтому (см. Рисунок 3) для решения конкретной задачи вам понадобится меньше людей, если вы будете использовать легкую методологию, и больше – если тяжелую. Впрочем, существует ограничение по размеру задачи, которую может решить данное число людей. У большой команды, использующей тяжелую методологию, этот "порог" выше, чем у маленькой команды, которая использует легкую методологию. Таким образом, если ваша задача выходит за рамки такого ограничения, то вам придется, с одной стороны, увеличивать количество разработчиков и, с другой, использовать более тяжелую методологию.

Рисунок 3 . Объем задачи и методологии непосредственным образом влияет на количество персонала в компании.

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

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

Завершившийся не так давно проект С3 (Chrysler Comprehensive Compensation [C3a, C3b]), может служить убедительным примером всего, о чем я сейчас говорил. После того, как 26 человек не смогли выполнить задачу по созданию системы, которая считалась "большим проектом", за дело взялась малая часть этой команды – всего восемь человек. Используя новую, максимально легкую, но при этом строгую методологию [XP], они начали проект с нуля и уже через год смогли завершить то, что не смогла сделать большая команда, применявшая тяжелую методологию. Можно с уверенностью сказать, что частично такой успех методологии ХР был обеспечен последним, четвертым Принципом.

Принцип 4. Наиболее эффективная форма коммуникации (для передачи идей) – непосредственное взаимодействие, лицом к лицу, как при рисовании у доски .

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

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

Рисунок 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, чем правее или выше, тем больше стоимость разработки проекта, поэтому те, кто озабочен экономической стороной вопроса, должны постараться разместить свой проект как можно левее и ниже. Бывают ситуации, когда прочие стимулы, например, престиж руководителя проекта или безопасность собственной карьеры, могут заставить вас считать проект "более значительным и критичным", даже если это приведет к увеличению стоимости разработок.

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