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

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

Программные инфраструктуры
Программная инфраструктура (framework) – это некоторый универсальный исходный код, который может использоваться в качестве основы при разработке разнообразных приложений определенной категории. В программную инфраструктуру могут входить библиотека классов, шаблоны программ и т. п. Программная инфраструктура может быть коммерческим продуктом, но это может быть и продукт для внутреннего пользования.
Можно ли использовать ХР для разработки программных инфраструктур? Одно из правил ХР гласит, что вы должны удалять из системы любую функциональность, которая в данный момент не используется, если следовать этому правилу, то вы должны удалить всю инфраструктуру ХР не очень хорошо приспособлена для разработки кода, использование которого планируется не сейчас, а в дальнейшем. В рамках ХР-проекта вы не можете потратить шесть месяцев на разработку инфраструктуры, а затем приступить к ее использованию. Подход, подразумевающий разделение команды на группу разработки инфраструктуры и группу разработки приложения, тоже не подходит. В ХР мы занимаемся разработкой конкретных приложений. Если после нескольких лет постоянных переработок дизайна начинают вырисовываться некоторые универсальные абстракции общего использования, значит, настало время подумать о том, как сделать их более широко доступными.
Если цель проекта – разработка инфраструктуры для внешнего использования, вы по-прежнему можете использовать ХР. В игре в планирование на стороне бизнеса играет программист, который занимается разработкой приложений на базе инфраструктуры, которую вы разрабатываете. Возможности инфраструктуры превращаются в истории.
После того как инфраструктура начинает использоваться вне команды, вы можете применять более консервативный подход к переработке кода.
Вы предупреждаете заказчиков о предстоящем изменении или отказе от использования той или иной возможности и продолжаете эволюцию интерфейса вашей инфраструктуры, в течение некоторого времени сохраняя в ней как старую, так и новую версию интерфейса.

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

Заключение
Все методики основаны на страхе. Вы пытаетесь развить у себя привычки, которые помогут вам не допустить, чтобы ваши страхи воплотились в реальность. В этом отношении ХР ничем не отличается от любой другой методики. Разница состоит в том, что страхи запечатлены в ХР.
Методика ХР – это мое детище, и поэтому она отражает мои собственные страхи. Я боюсь:
• делать бессмысленную работу;
• останавливать проекты из-за того, что я не достиг достаточного технического прогресса;
• делать плохие бизнес-решения;
• иметь дело с плохими техническими решениями, которые сделаны за меня бизнесменами;
• прийти к концу карьеры разработчика программных систем и понять, что было бы лучше, если бы я больше времени проводил с детьми;
• делать работу, которой я не могу гордиться.
ХР также отражает вещи, которых я не боюсь:
• кодировать;
• изменять мой взгляд на вещи;
• продолжать работу, ничего не зная о будущем;
• надеяться на других людей;
• изменять анализ и дизайн функционирующей системы;
• писать тесты.
Я должен был научиться не бояться этих вещей. Это не пришло ко мне само собой, особенно если учесть, что так много людей говорили мне о том, что именно этих вещей и следует бояться и что я должен прилагать все свои усилия для того, чтобы избежать этих вещей.

Ожидание
Один юноша пришел к мастеру фехтования.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61