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

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

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