Давайте рассмотрим пример простого соглашения между некоторым заказчиком и командой из десяти (10) разработчиков. Контракт заключается на 12 месяцев. Изначальная разработка осуществляется в течение 3 месяцев. Затем первая версия продукта начинает эксплуатироваться на производстве. После этого каждая очередная версия выпускается с периодичностью раз в месяц в течение 9 месяцев. На время изначальной разработки заказчик вводит в состав команды разработчиков одного своего представителя, который является техническим специалистом. После этого каждый очередной месяц заказчик вводит в состав команды по одному новому своему техническому специалисту, а исполнитель выводит из состава команды разработчиков одного из своих людей. В конце работы над заказом половина команды разработчиков – это люди заказчика, которые готовы осуществлять поддержку кода программы и продолжать дальнейшую разработку, правда, с меньшей скоростью.
В отличие от ситуации, когда разработка целиком и полностью возлагается на сторонних разработчиков, в условиях, когда состав команды разработчиков изменяется, разработка не может выполняться с такой же скоростью, как если бы состав команды оставался бы неизменным. Однако получаемое при этом снижение риска, возможно, стоит того.
ХР обеспечивает нормальное исполнение такой схемы за счет того, что команда постоянно измеряет скорость, с которой она работает. По мере того как происходит замена членов команды, скорость работы команды может меняться как в худшую, так и в лучшую сторону. Измеряя получаемую производительность, команда может вносить изменения в план итераций и влиять на объем работ в ходе игры в планирование. По мере того как эксперты будут уходить, а на их место будут приходить менее опытные люди, команда может выполнять переоценку оставшихся историй.
Время и материалы
В контрактах категории время и материалы (Time and Materials, T&M) команда ХР получает почасовую оплату. Все остальное работает так, как описывалось ранее.
Проблема контрактов Т&М состоит в том, что мотивы исполнителя идут в разрез с мотивами заказчика. Исполнитель желает в течение как можно более длительного времени задействовать в работе над проектом как можно больше людей для того, чтобы максимизировать прибыль. Кроме того, исполнитель имеет тенденцию принуждать разработчиков работать сверхурочно, чтобы увеличить ежемесячную прибыль. Заказчик желает реализовать как можно больший объем функциональности за как можно более короткий срок с использованием как можно меньшего количества людей.