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

• новую эволюцию системы можно выполнить своими силами;

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

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

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

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

Наверное, вам показалось, что я не в восторге от выполнения разработки чужими руками. Дело в том, что если разработка выполняется на стороне, это, как правило, означает, что существует некоторый акт приема-сдачи работы. Проект передается заказчику в виде большого единого продукта, готового к употреблению. Это нарушает принцип постепенного изменения. Однако существует некоторая весьма удобная вариация на эту тему, которую можно реализовать благодаря использованию ХР. Что, если вы постепенно будете заменять членов команды, занимающейся разработкой, техническими специалистами, которые являются сотрудниками фирмы-заказчика? Именно это я и называю выполнением разработки своими силами (insourcing).

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

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

Давайте рассмотрим пример простого соглашения между некоторым заказчиком и командой из десяти (10) разработчиков. Контракт заключается на 12 месяцев. Изначальная разработка осуществляется в течение 3 месяцев. Затем первая версия продукта начинает эксплуатироваться на производстве. После этого каждая очередная версия выпускается с периодичностью раз в месяц в течение 9 месяцев. На время изначальной разработки заказчик вводит в состав команды разработчиков одного своего представителя, который является техническим специалистом. После этого каждый очередной месяц заказчик вводит в состав команды по одному новому своему техническому специалисту, а исполнитель выводит из состава команды разработчиков одного из своих людей. В конце работы над заказом половина команды разработчиков – это люди заказчика, которые готовы осуществлять поддержку кода программы и продолжать дальнейшую разработку, правда, с меньшей скоростью.

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

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

В контрактах категории время и материалы (Time and Materials, T&M) команда ХР получает почасовую оплату. Все остальное работает так, как описывалось ранее.

Проблема контрактов Т&М состоит в том, что мотивы исполнителя идут в разрез с мотивами заказчика. Исполнитель желает в течение как можно более длительного времени задействовать в работе над проектом как можно больше людей для того, чтобы максимизировать прибыль. Кроме того, исполнитель имеет тенденцию принуждать разработчиков работать сверхурочно, чтобы увеличить ежемесячную прибыль. Заказчик желает реализовать как можно больший объем функциональности за как можно более короткий срок с использованием как можно меньшего количества людей.

Благодаря хорошим отношениям между заказчиком и исполнителем схема Т&М может сработать, однако трение между ними всегда будет существовать.

Отличный способ уладить разногласия между заказчиком и исполнителем в рамках контракта с фиксированной ценой или Т&М – это учреждение премии за завершение проекта в срок. В некотором смысле премия за завершение проекта к сроку – это легкая добыча для команды ХР. Игра в планирование предоставляет команде столь удобный контроль над проектом, что, скорее всего, она без труда сможет получить эту премию.

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

Когда премия за завершение в срок или штраф за опоздание используются в рамках ХР, необходимо обратить внимание на важную особенность: игра в планирование подразумевает, что объем работ, связанных с проектом, неизбежно будет изменяться по мере работы над проектом. В процессе работы неизбежно будет возникать необходимость добавить новые истории и убрать из технического задания некоторые старые истории. Если заказчик горит желанием взять исполнителя за жабры, он может сказать примерно следующее: Сегодня первое марта, а полный набор историй, указанных в изначальном контракте, все еще не реализован. Никаких премий! Теперь вы будете платить неустойку! Заказчик может сказать подобное даже в случае, если система уже успешно эксплуатируется на производстве.

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

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