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

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

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

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

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

Организация команды

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

Методы управления

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

ствии со спецификациями.1 Компетентные инженеры%программисты получают больше самостоятельности и ответственности.

Задачи могут распределяться с помощью долгосрочных планов, рас% считанных на многие месяцы (и часто становящихся устаревшими и неточными), либо путем оперативного назначения очередного зада% ния разработчику, как только он завершает предыдущее. Программи% сты могут работать самостоятельно над отдельными частями системы либо совместно в парах, объединяя ответственность и знания.

Разделение ответственности

Основная задача заключается в разделении каждого направления раз% работки между программистами:

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

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

Все встали парами!

Программирование парами – это метод совместной разработки программного обеспечения, особенно модный среди поклонни% ков ускоренного программирования (agile development). Утвер% ждают, что оно приводит к росту эффективности: код создается быстрее и с меньшим количеством ошибок.

Два разработчика пишут код вместе: в одно и то же время, за од# ним терминалом. Пока один (водитель) пишет, другой (штур% ман) обдумывает сделанное и осуществляет контроль, устраняя замеченные ошибки до того, как они проявятся в действии. Пе% риодически роли в паре меняются. Штурман видит ошибки, ко% торые допускает водитель, сосредоточенный на вводимом коде,

и устраняет опасные последствия.

1 Здесь управление предполагает наличие заменяемого товара – рядовых программистов. См. «Кодер (Code Monkey)» на стр. 386.

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

Согласно отчетам после тренировки два программиста в решении любой задачи показывают совместную продуктивность, которая более чем вдвое превышает продуктивность каждого. В журнале «The Economist» были опубликованы следующие данные: «Лори Уильямс из Университета Юты в Солт%Лейк%Сити показал, что пара программистов лишь на 15% медленнее, чем два независи% мо работающих программиста, но ошибок у нее на 15% меньше. Поскольку тестирование и отладка часто во много раз более тру% доемки, чем первичное программирование, этот результат впе% чатляет». (Economist 01)

У программирования парами много достоинств. Оно способствует передаче знаний и помогает обучению, концентрирует внимание (менее вероятно, что вы будете предаваться мечтательности, дол% го болтать по телефону или отключитесь), поднимает дисципли% ну и сокращает отвлечения (когда два человека заняты совмест% ным делом, вы вряд ли станете им мешать; другое дело – одино% кий программист, бессмысленно уставившийся в пространство). Этот метод действует как оперативный механизм предваритель% ного контроля – моментальной проверки кода – и способствует повышению качества кода. Это социальный процесс: при пра% вильном выборе напарников он способствует укреплению мо% рального духа (хотя он может быть ужасен, если эти двое вызыва% ют друг у друга раздражение). Программисты ближе знакомятся между собой и лучше понимают, как работать вместе. Програм% мирование парами укрепляет коллективные права на код, содей% ствует распространению правильной культуры кодирования, придает выразительность процессу разработки.

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

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

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

работки так, чтобы каждый в нужное время мог проявить соответст%

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

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

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

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

Организация и структура кода

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

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

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