« "Каждому проекту своя методология", Алистэр Коуберн | | Главы из перевода "Planning Extreme Programming", Кент Бек и Мартин Фаулер »

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

Алистэр Коуберн

Humans and Technology
arc@acm.org

Humans and Technology Technical Report 2000.01

Original article

Содержание

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

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

Краткий обзор дискуссии

Эта статья - логическое продолжение предыдущих работ: "Characterizing people as first-order, non-linear components of software development" [Co1] (в русском переводе: "Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения") и "A methodology per project" [Co2] (в русском переводе: "Каждому проекту своя методология"), где обсуждалась возможность создания гибкой "человекоцентричной" методологии для отдельно взятой команды, причем непосредственно в процессе работы над проектом.

Суть изложенного в этих статьях материала сводится к следующему:

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

Можно, конечно, начинать давать рекомендации, основываясь только на принципах конструирования методологии (даже притом, что относительно самих этих принципов до сих пор нет единого мнения). Впрочем, один из них гласит, что в любом проекте человеческий фактор может легко возобладать над процессом (см. [Co1], [Wei]). Легкие методологии, основанные на межличностных коммуникациях, представляют собой довольно прочные структуры (см. [Co2]). Их оптимальный "вес" может разниться от проекта к проекту, в зависимости от количества занятых в работе людей и близости их физического размещения, а также ущерба от возможного сбоя системы (см. [Co2]).

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

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

Данная работа состоит из следующих частей:

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

Первая из двух статей, на основе которых я написал эту, называется "Characterizing people as first-order, non-linear components of software development" [Co1] (в русском переводе: "Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения"). Заканчивается она следующим образом:

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

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

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

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

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

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

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

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

Второй статьей была "A methodology per project" [Co2] (в русском переводе: "Каждому проекту своя методология"). Она заканчивается такими словами:

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

Мы выяснили четыре основных принципа проектирования методологии. Вкратце их можно описать следующим образом:

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

Объединив и то, и другое, получаем:

  1. Каждый проект заслуживает своих собственных процесса и методологии, созданных специально для него.
  2. "Легкость" и непосредственное общение являются весьма желательными их атрибутами.
  3. Наиболее эффективно люди общаются непосредственным образом - лицом к лицу.
  4. Непостоянство, непоследовательность и лень представляют собой самые заурядные человеческие слабости, которые всегда нужно учитывать при конструировании методологии (ключевая фраза: "процессы, требующие высокой дисциплины, обречены на хрупкость").
  5. Процесс разработки должен строиться на положительных качествах человеческой натуры: чувстве гражданской ответственности, способности ориентироваться в обстановке, общаться друг с другом и проявлять инициативу.

Источники

Эта статья основывается на результатах работы над реальными проектами, а также исследованиях и опросах, проведенных мною в период с 1991 по 1999 гг. Большая часть собранных материалов так или иначе представлена в работах [Co1], [Co2] и [Co3].

Все эти идеи подтвердились после опроса тех организаций, которые сумели добиться таких же успехов, разрабатывая аналогичные методологические подходы. В Великобритании IBM Object Technology Practice уже несколько лет проводит семинар по так называемой "настройке методологии" в начале каждого проекта. Что-то подобное делает в Мюнхене Siemens. А один из военных субподрядчиков во Флориде рассказал, как его сертифицированная по ISO-9000 группа разработчиков создает особый легкий процесс для каждого вида работ (при помощи контрольных таблиц для процесса).

Я также использовал работу Керта (Kerth), [Ke], где рассматривается техника ретроспективного анализа работ (обычно их называют "разбором полетов", но этот автор использует понятие "послеродовый осмотр").

С процессом осуществления изменений в структуре и в принципах работы команды в конце каждого инкремента я впервые познакомился во время работы над проектом "Ingrid", [Co3] в 1992. Тогда без этого было просто не обойтись. С тех пор я внес в метод некоторые дополнения, а именно объединил его с правилом "настраивать" методологию еще и в середине инкремента. После я открыто использовал этот принцип в работе над проектом "Winifred" [Co3], и когда работал в Центральном Банке Норвегии [Co2]. Кроме того, мой коллега использовал принцип "настройки" методологии в конце каждого инкремента, работая над проектом "Insman" в Германии [Co2]. Все три проекта окончились успешно, причем применение такой методологии явно повлияло на качество результата.

В течение многих лет при разработке ПО использовались самые разнообразные методологии (как в случае уже упомянутых IBM и Siemens, а также описанные в работах [MO] и [Gr]). Однако, насколько мне известно, первой методологией, которая рекомендует динамически менять процесс во время проекта, является Crystal.

Идея заменить письменную документацию непосредственным личным общением была высказана давным-давно. Ее отстаивал в конце 60-х Вайнберг (Weinberg [Wei]), а в конце 70-х - Демарко (и снова он, но уже в 90-х [De1], [De2]). С тех пор многие использовали эти идеи как "секретное оружие", а недавно вышли из подполья - независимо и сразу в нескольких местах:

Динамические методологии

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

Начало проекта

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

"В успешно завершившихся проектах между разработчиками и пользователями (или менеджментом) была налажена тесная коммуникация. А в неудачных общение было поставлено из рук вон плохо".

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

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

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

Теперь объедините данные всех опросов и выделите их общие черты. Именно они говорят о сильных и слабых сторонах организации. В тех ответах, которые доводилось слышать мне, максимальное внимание уделяется именно человеческому фактору (как в двух приведенных выше примерах). Нередко мне приходится сталкиваться и с комментариями относительно любви/или нелюбви к CASE инструментам, проверке и пересмотру кода, нестабильности требований, частоты итераций, тестирования и стандартов кодирования.

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

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

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

Первый инкремент

Приблизительно в середине первого инкремента проведите повторный опрос команды (задайте им все те же вопросы - индивидуально каждому или всем вместе, в зависимости от размеров компании и физической удаленности сотрудников).

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

Теперь внесите в свои методологические выкладки те предложения, воплотить которые совсем несложно, или же те, которые просто нельзя проигнорировать. Остальную "доводку" оставьте на потом.

Время, которое вам на это понадобится: от одного до трех часов.

После каждого инкремента

После каждого инкремента проводите общее собрание, на котором задавайте один-единственный вопрос: "Что мы могли бы делать лучше?"

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

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

Следующие инкременты

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

Главный вопрос, на который надо ответить во время таких "внутриинкрементных" аналитических сессий, это "Все ли работает так, как надо?" Иногда у команды появляется новая идея на втором или третьем инкременте, и ее нужно опробовать. Может быть, эта идея не сработает, и тогда у команды должна быть возможность вернуться к предыдущему варианту методологии или же опробовать следующую идею. Проект "Winifred" трижды менял структуру команды во время третьего инкремента [С3]. Разработчики решили, что структура команды, использовавшаяся во время первого и второго инкремента, им не подходит. Впрочем, первые два предложения по новой структуре тоже оказались ошибочными. Третий вариант всех устроил. Его и использовали до конца проекта.

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

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

Берите за основу сильные стороны человеческой натуры

Человеческий фактор может легко перекрыть все другие элементы процесса [Co1]. Двойная проверка методологии во время каждого инкремента позволит вам справиться с этой пресловутой проблемой. Однако начинать строить методологию нужно на неких базовых выкладках, основывающихся на предыдущем опыте работы команды. Здесь я продемонстрирую, как использовать сильные стороны человеческой натуры при построении базового варианта методологии.

Чем легче, тем лучше, и пусть люди сами обеспечивают передачу информации

Легкие методологии явно лучше, чем тяжелые, со всеми их условностями и высокой себестоимостью [Co2]. Особенно уместно использовать легкие методологии, когда основной проблемой становится количество времени перед поставкой системы на рынок. Однако тут возникает вопрос: если команда производит меньшее количество вспомогательных рабочих продуктов, а те, что производит, оформлены в гораздо более свободном стиле, то что связывает воедино всю информацию о проекте? Ответ прост. В данном случае вступают в силу два положительных качества человеческого характера: во-первых, людям лучше всего общаться в неформальной обстановке, "лицом к лицу", а во-вторых, как правило, каждый из нас имеет чувство гражданской ответственности [Co2].

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

Устное общение гораздо более выразительно и менее дорого, чем письменное [Co2], поэтому устный компонент в методологии может быть довольно большим, нередко гораздо большим, чем того ожидают. Создатели методологии "eXtreme Programming" (ХР) [Be] сделали устное общение одним из основных своих постулатов и добились отличных результатов [C3]. В XP не принято записывать даже подробные требования - вместо этого они определяются в процессе общения с экспертами по использованию программного продукта (заказчиками), которые работают как полноправные члены команды.

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

Управляйте внутрипроектными зависимостями

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

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

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

Все люди отличаются друг от друга, и все они непостоянны

Итак, поскольку человеку свойственны такие слабости, как изменчивость и непостоянство, методология должна как-то их учитывать.

Можно установить строгие стандарты и выработать специальные методологические механизмы, которые обеспечивали бы их соблюдение. Именно таким путем пошли eXtreme Programming [Be] и Personal Software Process / Team Software Process [Hu1], [Hu2].

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

Очень важно также, чтобы методологии, требующие строгой дисциплины, подходили для команды разработчиков. В противном случае, команда будет саботировать и придумывать всяческие увертки, чтобы уклониться от выполнения всех требуемых правил. В конце концов, проект может лишиться не только дисциплины, но и всех выгод, которые сулила используемая методология. Именно по этой причине строгие методологии являются непрочными. Впрочем, на этот счет собрано еще очень мало информации. Есть, по крайней мере, одно свидетельство того, что в методологиях ХР и TSP используются вполне приемлемые для разработчиков механизмы ([XP3], [Webb]).

Существует и другой подход - нужно проектировать методологию таким образом, чтобы она учитывала индивидуальность характеров, и в меньшей степени полагалась на последовательность и неизменность человеческих поступков. Такой подход принят в семействе методологий Crystal ([Co4], [Co5]), а также в методологии под названием Adaptive Software Development ([Hi]). Однако и в этом случае команда разработчиков должна прийти к соглашению относительно минимальных и достаточных характеристик используемых рабочих продуктов и правил их создания. Стандартизация приветствуется, но не требуется.

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

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

Семейства методологий

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

Рисунок 1. Методологии, организованные по принципу люди х критичность х приоритетность (взято из [Co2]).

Таким образом, у нас уже есть все необходимые элементы для описания семейства методологий, обладающих динамической природой и повышенной чувствительностью к чертам человеческой натуры. Одно такое семейство я назвал Crystal. Семейство методологий Crystal в настоящее время разрабатывается в работах [Co4] и [Co5], поэтому в данной статье я опишу только наиболее яркие его характеристики.

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

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

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

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

Все методологии Crystal различаются по цвету, причем каждый цвет предназначен для определенных проектов и имеет свои собственные характеристики: "Прозрачная" для самых легких и небольших проектов, затем "Желтая", "Оранжевая", "Красная", "Малиновая", "Синяя", "Фиолетовая" и т.д., для больших команд, использующих более тяжелые методологии.

Рисунок 2. Методологии Crystal различаются по цвету

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

Crystal "Оранжевая"

Этот вид методологии кратко описан в работе автора [Co3] (хотя имя "Crystal" в ней было опущено). В этой работе даются следующие характерные черты проектов, для которых предназначена эта методология:

... для проектов среднего размера в индустриальном окружении, обладающих следующими характеристиками:

  • общее количество занятых в проекте людей от 10 до 40
  • продолжительность работ от 1 до 2 лет
  • важно своевременное появление продукта на рынке
  • нужно поддерживать общение между нынешними и будущими разработчиками, а также снижать временные и финансовые расходы
  • критичность: не жизненно-важная

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

"Оранжевая" методология семейства Crystal относится к методологии "D40". Это означает, что она подходит для команды общей численностью не выше 40 человек, работающей в одном здании над разработкой системы, сбой которой может привести к потере несущественной суммы (сюда можно отнести, например, программу учета платежей компании). Для "Оранжевой" методологии нужна бОльшая структуризация и координация команды, чем для проекта, над которым работают 20 человек. Однако она не предусматривает четкого деления команды на подгруппы (как это необходимо при работе над проектом, в котором задействовано, например, 80 человек) и не предполагает строгой проверки дизайна и кода системы (как это необходимо для жизненно-важных проектов). В зависимости от команды, "Оранжевую" методологию можно использовать также для проектов типа "E50".

Вкратце, для "Оранжевой" методологии семейства Crystal характерны следующие моменты (подробнее см. в [Co3]):

  • Роли включают в себя спонсора (Sponsor), эксперта в данном виде бизнеса (Business expert), эксперта по использованию системы (Usage expert), технического посредника (Technical facilitator), бизнес-аналитика/проектировщика (Business analyst/designer), руководителя проекта (Project Manager), архитектора (Architect, Design Mentor), проектировщика/программиста (Designer/programmer), ведущего проектировщика/программиста (Lead designer/ programmer), инженера по повторному использованию (Reuse Point), писателя (Writer), тестировщика (Tester), дизайнера интерфейсов (UI designer).
  • Все сотрудники распределяются по командам, которые отвечают, соответственно, за планирование, руководство, архитектуру, технологии, функционирование, инфраструктуру и внешнее тестирование.
  • Методологические стандарты: программный продукт проходит процесс контроля качества каждые 3 + 1 месяц; прогресс в работе отслеживается по контрольным точкам поставки частей системы, а не по документации; применяется автоматическое регрессивное тестирование функциональности системы, в работах непосредственным образом участвуют пользователи системы, по два пользователя на релиз, вспомогательные виды деятельности начинаются только тогда, когда сама система оказывается достаточно стабильной для ее проверки пользователями. "Настройка" методологии осуществляется на собраниях в начале и середине каждого инкремента.
  • Все эти правила обязательны, однако при необходимости их можно замещать другими, например, методами планирования Scrum [Scr], практиками eXtreme Programming или Adaptive Software Development [Hi].
  • Что касается рабочих продуктов, то к ним относятся: документ с требованиями к системе, план релизов, отчеты о состоянии работ по проекту, документ, описывающий дизайн интерфейсов, общая объектная модель системы, внутрикомандные спецификации, руководство для пользователя, исходный код, тесты и код для миграции с предыдущей системы. Каждый из упомянутых здесь продуктов дорабатывается до той степени, при которой его начнут понимать коллеги по работе, а именно до уровня детализации, допускающего попарную работу.
  • Все шаблоны для рабочих продуктов, стандарты кодирования, стандарты построения пользовательских интерфейсов и детали, касающиеся регрессивного тестирования, считаются локальными стандартами, то есть их должна вырабатывать и поддерживать сама команда разработчиков.
  • Что касается стиля работы для каждой конкретной роли, то он всецело зависит от индивида, который эту роль выполняет.

Crystal "Прозрачная"

Для сравнения давайте обратимся к самой легкой из всех методологий этого семейства.

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

Для этого типа методологии обязательны только следующие условия (см. подробнее в работе автора [Co4]):

  • Отдельные роли: спонсор (Sponsor), старший дизайнер (Senior designer), дизайнер-программист (Designer/programmer) и пользователь (User), последний может даже работать не полный рабочий день. Все остальные роли распределяются между членами команды: координатор проекта (Project Coordinator), эксперт в данном виде бизнеса (Business Expert), сборщик требований (Requirements Gatherer).
  • Над проектом работает только одна команда.
  • Методологические стандарты те же, что и в "Оранжевой" методологии, за исключением того, что каждый инкремент длится не более двух месяцев.
  • Требуется меньшее количество рабочих продуктов: план релизов, план просмотра системы пользователями и план поставок, снабженные пояснениями варианты использования системы, наброски по дизайну системы и интерфейсам, различные заметки, общая объектная модель системы, работающий код, код миграции, тесты и руководство для пользователя.
  • Шаблоны для рабочих продуктов, стиль кодирования, стандарты построения пользовательских интерфейсов и детали, касающиеся регрессивного тестирования, точно так же считаются локальными стандартами, которые должна вырабатывать и поддерживать сама команда разработчиков.
  • Опять-таки, все, что касается стиля работы для каждой конкретной роли, всецело зависит от индивида, который эту роль выполняет, и от команды. Можно применять правила, принятые в других методологиях (например, в Scrum и eXtreme Programming).

eXtreme Programming

eXtreme Programming (у нас уже почти прижилось название "Экстремальное программирование" -- прим. перев.) можно считать одним из вариантов "Прозрачной" методологии, хотя у нее есть одно довольно существенное отличие от нее. Как и в других методологиях такого плана, здесь используются частые релизы, тесное общение, наличие пользователя в команде разработчиков, автоматическое регрессивное тестирование, повышенное внимание к боевому духу команды, упор на устную культуру общения. Эту методологию можно отнести к разряду "D6", однако ее можно с успехом "натянуть" на проект из разряда "D14" (см. [C3]).

При всем этом eXtreme Programming и "Прозрачная" методология семейства Crystal придерживаются диаметрально противоположных взглядов на дисциплину и толерантность. ХР находится в стороне от всех прочих методологий подобного типа, так как ее отличают самое незначительное использование письменных рабочих продуктов и самые строгие правила ведения работ. Она базируется на строгом следовании правилам программирования и дизайна, парном программировании, 100%-ном модульном тестировании. И, как это логично следует из общих характеристик методологии, требующей жесткой дисциплины от сотрудников, она вводит роль "наставника", а также некоторые другие механизмы, позволяющие контролировать соблюдение всех своих правил.

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

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

Заключение

Данная статья строилась на основе полученных ранее выводов:

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

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

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

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

И в-третьих, можно создать целую "семью" или спектр методологий, которые бы имели в основе одни и те же базовые принципы, и которые можно было бы точно так же "настраивать" по ходу проекта. Здесь я постарался дать общее представление о методологиях Crystal. Эти методологии отличаются друг от друга по цвету. Для каждой из них характерны свои собственные элементы построения коммуникации. При этом не затрагиваются базовые принципы: замещать письменные рабочие продукты короткими и мощными коммуникационными каналами и часто поставлять заказчику рабочие версии ПО.

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

 

Библиография

[Be] Beck, K., Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999.

[C3] The "C3" Team, "Chrysler goes to 'Extremes'", in Distributed Object Computing, October, 1998, pp. 24-28.

[Co1] Cockburn, A., "Characterizing People as Non-Linear, First-Order Components in Software Development", submitted to International Conference on Software Engineering 2000. Online as Humans and Technology Technical Report, TR 99.05, at http://members.aol.com/humansandt/papers/ nonlinear/nonlinear.htm.

[Co2] Cockburn, A., "A methodology per project," submitted to IEEE Software. Online as Humans and Technology Technical Report, TR 99.04, http://members.aol.com/humansandt/ papers/methyperproject/ methyperproject.htm.

[Co3] Cockburn, A., Surviving Object-Oriented Projects, Addison-Wesley, 1998.

[Co4] Cockburn, A., Crystal/Clear: A Human-Powered Methodology for Small Teams, Addison-Wesley, 2001, in preparation. Online draft at http://members.aol.com/humansandt/crystal/clear.

[Co5] Cockburn, A., Software Development as a Cooperative Game, Addison-Wesley, 2001, in preparation, online at http://members.aol.com/humansandt/crystal/game.

[De1] DeMarco, T., Lister, T., Peopleware: Productive Projects and Teams, 2nd Ed., Dorset House, 1999.

[De2] DeMarco, T., The Deadline, Dorset House, 1997.

[Gr] Graham, I., Henderson-Sellers, B., Younessi, H., The OPEN Process Specification, Addison-Wesley, 1997.

[Hi] Highsmith, J., Adaptive Software Development, Dorset House, 1999.

[Hu1] Humphreys, W., Introduction to the Personal Software Process, Addison-Wesley, 1997.

[Hu2] Humphreys, W., Introduction to the Team Software Process, Addison-Wesley, 2000.

[Ke] Kerth, N., "An approach to postmorta, postparta, and project reviews", online at http://c2.com/doc/ppm.pdf.

[MO] Martin, J., Odell, J., Object-oriented Methods, Pragmatic Considerations, Prentice Hall, 1996.

[Scr] Shwaber, K., "Scrum development process", online at http://www.jeffsutherland.org/oopsla/schwapub.pdf.

[Webb] Webb, D., Humphrey, W., "Using TSP on the TaskView Project", in CrossTalk, The Journal of Defense Software Engineering, Feb 1999, pp. 3-10, online at http://www.stsc.hill.af.mil/crosstalk/1999/feb/webb.asp

[Wei] Weinberg, J., The Psychology of Computer Programming, Silver Edition, Dorset House, 1998.

[XP] eXtreme Programming, as described on the web: http://extremeprogramming.com, http://armaties.com/extreme.html, http://c2.com/ppr/wiki/ExtremeProgrammingRoadmap/html.zip.

kirsa September 24, 2002 9:39 PM

Комментарии

Сделать комментарий




Запомнить меня?