В подобной ситуации самым правильным решением будет заменить тестирование длительным предварительным размышлением. Однако в этом случае то, что вы делаете, нельзя будет назвать ХР. Когда я программирую в рабочей среде подобной категории, я не чувствую себя способным свободно видоизменять дизайн системы. Я обязан сформировать необходимую гибкость заранее. В этом случае вы по-прежнему можете производить качественное программное обеспечение, однако при этом вы не должны использовать ХР.
Помните историю о программистах, офисы которых размещались в разных концах здания? Если вы работаете в неподходящих физических условиях, ХР не будет работать. Как было отмечено, для целей ХР я использовал большую общую комнату с мощными компьютерами в центре и с небольшими отделениями вдоль стен. Однако это только один из возможных вариантов. Вард Каннингхэм (Ward Cunningham) рассказывал мне о проекте WyCach, при работе над которым каждому программисту выделили по отдельному небольшому рабочему месту, отделенному от внешнего мира перегородками из ДСП. Однако каждый такой мини-офис был достаточно просторным для того, чтобы вместить двух человек. Если два человека хотели работать в паре, они выбирали один из офисов. Если вы абсолютно точно не можете передвигать столы, если уровень шума высок настолько, что сильно мешает разговору, если вы не можете расположиться достаточно близко для того, чтобы обеспечить хорошую коммуникацию, вы не сможете использовать ХР с максимальной эффективностью.
Что не сработает абсолютно точно? Если ваши программисты размещаются на двух этажах, вы можете забыть об ХР. Если программисты расположены на одном этаже, но далеко друг от друга, вы тоже можете забыть об ХР. Если программисты географически удалены друг от друга, то, вы можете попытаться использовать ХР при условии, что над разными логически связанными частями проекта будут работать две команды и что они смогут работать в условиях ограниченной коммуникации между собой. Можно начать работу над проектом при помощи одной команды, выпустить первую версию, затем разделить команду согласно географическим границам, поручить каждой из команд реализацию одной из логически отдельных частей приложения и развивать каждую из частей по отдельности.
Наконец, вы абсолютно точно не сможете работать в стиле ХР, если в одной комнате с вами кричит ребенок. В этом вы мне можете абсолютно точно довериться.
Глава 26.
Заключение
Словарь терминов
Помните историю о программистах, офисы которых размещались в разных концах здания? Если вы работаете в неподходящих физических условиях, ХР не будет работать. Как было отмечено, для целей ХР я использовал большую общую комнату с мощными компьютерами в центре и с небольшими отделениями вдоль стен. Однако это только один из возможных вариантов. Вард Каннингхэм (Ward Cunningham) рассказывал мне о проекте WyCach, при работе над которым каждому программисту выделили по отдельному небольшому рабочему месту, отделенному от внешнего мира перегородками из ДСП. Однако каждый такой мини-офис был достаточно просторным для того, чтобы вместить двух человек. Если два человека хотели работать в паре, они выбирали один из офисов. Если вы абсолютно точно не можете передвигать столы, если уровень шума высок настолько, что сильно мешает разговору, если вы не можете расположиться достаточно близко для того, чтобы обеспечить хорошую коммуникацию, вы не сможете использовать ХР с максимальной эффективностью.
Что не сработает абсолютно точно? Если ваши программисты размещаются на двух этажах, вы можете забыть об ХР. Если программисты расположены на одном этаже, но далеко друг от друга, вы тоже можете забыть об ХР. Если программисты географически удалены друг от друга, то, вы можете попытаться использовать ХР при условии, что над разными логически связанными частями проекта будут работать две команды и что они смогут работать в условиях ограниченной коммуникации между собой. Можно начать работу над проектом при помощи одной команды, выпустить первую версию, затем разделить команду согласно географическим границам, поручить каждой из команд реализацию одной из логически отдельных частей приложения и развивать каждую из частей по отдельности.
Наконец, вы абсолютно точно не сможете работать в стиле ХР, если в одной комнате с вами кричит ребенок. В этом вы мне можете абсолютно точно довериться.
Глава 26.
ХР в работе
ХР может применяться при любой форме контракта, однако разные формы предусматривают использование разных вариаций ХР. В частности, контракты с фиксированной ценой и фиксированным объемом работ благодаря игре в планирование становятся контрактами с фиксированной ценой, фиксированной датой и приблизительно фиксированным объемом работ.
Как ХР вписывается в общераспространенные разновидности бизнес-практики? Неправильная форма контракта может легко разрушить проект вне зависимости от инструментов, технологии и таланта. В данной главе анализируются некоторые бизнес-аспекты разработки программного обеспечения, а также то, как вы можете использовать их совместно с ХР.
Каждый проект с фиксированной ценой и фиксированным объемом работ, с которым мне приходилось иметь дело, заканчивался тем, что обе стороны говорили друг другу: Требования неясны. В результате работы над проектом с фиксированной ценой и фиксированным объемом работ две стороны начинают двигаться в противоположных направлениях. Поставщик продукта желает сделать как можно меньше, а заказчик желает получить как можно больше. В условиях подобного трения обе стороны желают успешного выполнения проекта, поэтому они отказываются от своих изначальных целей, но трение остается.
В рамках ХР взаимоотношения меняются малозаметным, но важным образом. Изначально разговор об объеме работ обсуждается с использованием слова например. Например, за 5 000 000 немецких марок мы могли бы реализовать все эти истории за 12 месяцев. Заказчик должен решить, стоят ли эти истории пяти миллионов немецких марок. Если эти истории – это все, что должна реализовать команда, то это хорошо. Существует вероятность, что заказчик заменит некоторые из историй более полезными для него. Никто не станет жаловаться, если вместо чего-либо он получит что-либо другое, более ценное. Однако недовольство и жалобы возникают тогда, когда кто-либо получает что-либо, о чем он просил, но при этом оказалось, что это не то, что ему нужно.
Вместо фиксированных цены/даты/объема работ команда ХР предлагает нечто наподобие подписки. Команда обязуется работать на заказчика с максимальной скоростью в течение определенного промежутка времени. Они будут следить за мнением заказчика относительно направления развития разработки. В начале каждой итерации заказчик получает формальную возможность изменить направление развития разработки и добавить совершенно новые истории.
Еще одно различие, связанное с применением ХР, заключается в использовании небольших версий. Вы никогда не должны работать над проектом ХР в течение 18 или даже 12 месяцев, не внедрив его в производственных условиях. Когда команда заключает контракт на реализацию историй в течение 12 месяцев, они играют с заказчиком в игру в планирование для того, чтобы определить объем работ, связанных с первой версией. Таким образом, когда речь идет о 12-месячном контракте, система начнет эксплуатироваться в производственных условиях спустя три или четыре месяца после начала работ, после этого новые версии будут выпускаться с периодичностью в один или два месяца. Постепенное введение системы в эксплуатацию обеспечивает заказчику возможность расторгнуть контракт в случае, если процесс разработки идет медленнее, чем планировалось, или если в результате изменения бизнес-условий реализация всего проекта потеряла смысл. Кроме того, так как проект развивается от итерации к итерации, на шкале времени у заказчика появляются точки, в которых он получает возможность изменить направление развития проекта.
• новую эволюцию системы можно выполнить своими силами;
• можно нанять для выполнения модификации системы тех же самых разработчиков, которые работали над ее созданием (однако они могут попросить за это слишком много денег);
• можно обратиться к другим разработчикам, которые плохо знакомы с кодом.
Если вы этого хотите, вы можете сделать это с использованием ХР. В этом случае либо команда идет работать к заказчику, либо заказчик посылает своих представителей к разработчикам. Они играют в игру в планирование для того, чтобы решить, что делать. Когда контракт завершается, команда уходит и оставляет заказчику код.
В некотором роде это может быть лучше, чем общепринятая форма соглашения о выполнении работ на стороне. У заказчика есть набор функциональных тестов и тестов модулей, которые позволяют ему удостовериться в том, что любые внесенные в систему изменения не нарушают существующей функциональности. Для заказчика будет удобно, если какой-либо его представитель будет стоять за спиной у программистов и вникать в то, как система устроена внутри. При этом заказчик получит возможность более точно руководить разработкой.
Разработка своими силами – это подчас малоэффективное занятие, так как собственные технические сотрудники подчас не обладают необходимыми для этого знаниями и опытом. Если разработка выполняется силами сторонних специалистов, заказчик получает в свое распоряжение систему, разработанную с использованием опыта и навыков специалистов действительно высокого класса, однако при этом он не знает, как устроена система и что делать, если возникает надобность в ее модификации.
Однако если в процессе работы вы постепенно заменяете чужих разработчиков своими, вы со временем постепенно перекладываете ответственность за разработку с чужих плеч на свои плечи. В результате у заказчика появляются знания об устройстве и функционировании системы, благодаря чему снижается риск того, что заказчик получит программу, которую он не сможет поддерживать.
Давайте рассмотрим пример простого соглашения между некоторым заказчиком и командой из десяти (10) разработчиков. Контракт заключается на 12 месяцев. Изначальная разработка осуществляется в течение 3 месяцев. Затем первая версия продукта начинает эксплуатироваться на производстве. После этого каждая очередная версия выпускается с периодичностью раз в месяц в течение 9 месяцев. На время изначальной разработки заказчик вводит в состав команды разработчиков одного своего представителя, который является техническим специалистом. После этого каждый очередной месяц заказчик вводит в состав команды по одному новому своему техническому специалисту, а исполнитель выводит из состава команды разработчиков одного из своих людей. В конце работы над заказом половина команды разработчиков – это люди заказчика, которые готовы осуществлять поддержку кода программы и продолжать дальнейшую разработку, правда, с меньшей скоростью.
В отличие от ситуации, когда разработка целиком и полностью возлагается на сторонних разработчиков, в условиях, когда состав команды разработчиков изменяется, разработка не может выполняться с такой же скоростью, как если бы состав команды оставался бы неизменным. Однако получаемое при этом снижение риска, возможно, стоит того.
ХР обеспечивает нормальное исполнение такой схемы за счет того, что команда постоянно измеряет скорость, с которой она работает. По мере того как происходит замена членов команды, скорость работы команды может меняться как в худшую, так и в лучшую сторону. Измеряя получаемую производительность, команда может вносить изменения в план итераций и влиять на объем работ в ходе игры в планирование. По мере того как эксперты будут уходить, а на их место будут приходить менее опытные люди, команда может выполнять переоценку оставшихся историй.
Проблема контрактов Т&М состоит в том, что мотивы исполнителя идут в разрез с мотивами заказчика. Исполнитель желает в течение как можно более длительного времени задействовать в работе над проектом как можно больше людей для того, чтобы максимизировать прибыль. Кроме того, исполнитель имеет тенденцию принуждать разработчиков работать сверхурочно, чтобы увеличить ежемесячную прибыль. Заказчик желает реализовать как можно больший объем функциональности за как можно более короткий срок с использованием как можно меньшего количества людей.
Благодаря хорошим отношениям между заказчиком и исполнителем схема Т&М может сработать, однако трение между ними всегда будет существовать.
Обратной стороной премии за завершение работы в срок является штраф за опоздание. Если разработчики не успевают доделать проект к назначенной дате, заказчик платит им меньше, чем договаривались. И вновь благодаря игре в планирование команда ХР получает преимущество. Команда всегда уверена в том, что завершит работу в срок, поэтому ей вряд ли придется терять деньги.
Когда премия за завершение в срок или штраф за опоздание используются в рамках ХР, необходимо обратить внимание на важную особенность: игра в планирование подразумевает, что объем работ, связанных с проектом, неизбежно будет изменяться по мере работы над проектом. В процессе работы неизбежно будет возникать необходимость добавить новые истории и убрать из технического задания некоторые старые истории. Если заказчик горит желанием взять исполнителя за жабры, он может сказать примерно следующее: Сегодня первое марта, а полный набор историй, указанных в изначальном контракте, все еще не реализован. Никаких премий! Теперь вы будете платить неустойку! Заказчик может сказать подобное даже в случае, если система уже успешно эксплуатируется на производстве.
Как правило, подобной проблемы не возникает. Если наступает Рождество, а под елкой уже лежат подарки, у заказчика вряд ли возникает желание сверять точное соответствие этих подарков со списком, который он указал в письме к Сайта-Клаусу, особенно если сам заказчик просил о тех или иных заменах.
Если вы опасаетесь, что заказчик будет придираться, указывая вам на изначально составленный им список историй с целью отказать вам в премии, лучше вообще не иметь дело с таким заказчиком. Я не рекомендую вам подписывать с ним какие-либо контракты.
Можно ли использовать ХР для разработки программных инфраструктур? Одно из правил ХР гласит, что вы должны удалять из системы любую функциональность, которая в данный момент не используется, если следовать этому правилу, то вы должны удалить всю инфраструктуру ХР не очень хорошо приспособлена для разработки кода, использование которого планируется не сейчас, а в дальнейшем. В рамках ХР-проекта вы не можете потратить шесть месяцев на разработку инфраструктуры, а затем приступить к ее использованию. Подход, подразумевающий разделение команды на группу разработки инфраструктуры и группу разработки приложения, тоже не подходит. В ХР мы занимаемся разработкой конкретных приложений. Если после нескольких лет постоянных переработок дизайна начинают вырисовываться некоторые универсальные абстракции общего использования, значит, настало время подумать о том, как сделать их более широко доступными.
Если цель проекта – разработка инфраструктуры для внешнего использования, вы по-прежнему можете использовать ХР. В игре в планирование на стороне бизнеса играет программист, который занимается разработкой приложений на базе инфраструктуры, которую вы разрабатываете. Возможности инфраструктуры превращаются в истории.
После того как инфраструктура начинает использоваться вне команды, вы можете применять более консервативный подход к переработке кода.
Вы предупреждаете заказчиков о предстоящем изменении или отказе от использования той или иной возможности и продолжаете эволюцию интерфейса вашей инфраструктуры, в течение некоторого времени сохраняя в ней как старую, так и новую версию интерфейса.
Иногда бывает полезно включить в состав игроков, играющих на стороне бизнеса, пользователя-эксперта. Например, компании, занимающиеся разработками компьютерных игр, могут нанять в качестве экспертов заядлых игроков в компьютерные игры, которые будут тестировать производимые ими игры. Производители финансовых программ могут нанять в качестве пользователей-экспертов профессиональных финансистов. Если вы производите музыкальный редактор, вы можете пригласить к себе в качестве эксперта профессионального композитора или музыканта. Пользователь-эксперт – это именно тот человек, который будет определять, какую из историй следует в первую очередь реализовать в следующей версии вашего программного продукта.
Как ХР вписывается в общераспространенные разновидности бизнес-практики? Неправильная форма контракта может легко разрушить проект вне зависимости от инструментов, технологии и таланта. В данной главе анализируются некоторые бизнес-аспекты разработки программного обеспечения, а также то, как вы можете использовать их совместно с ХР.
Фиксированная цена
Практика показывает, что наибольшие проблемы с использованием ХР возникают в случае, если работа идет над контрактом с фиксированной ценой. Можно ли играть в игру в планирование, если вы имеете дело с контрактом фиксированной цены/фиксированной даты/фиксированного объема работ? В результате получается контракт фиксированной цены/фиксированной даты/несколько варьируемого объема работ.Каждый проект с фиксированной ценой и фиксированным объемом работ, с которым мне приходилось иметь дело, заканчивался тем, что обе стороны говорили друг другу: Требования неясны. В результате работы над проектом с фиксированной ценой и фиксированным объемом работ две стороны начинают двигаться в противоположных направлениях. Поставщик продукта желает сделать как можно меньше, а заказчик желает получить как можно больше. В условиях подобного трения обе стороны желают успешного выполнения проекта, поэтому они отказываются от своих изначальных целей, но трение остается.
В рамках ХР взаимоотношения меняются малозаметным, но важным образом. Изначально разговор об объеме работ обсуждается с использованием слова например. Например, за 5 000 000 немецких марок мы могли бы реализовать все эти истории за 12 месяцев. Заказчик должен решить, стоят ли эти истории пяти миллионов немецких марок. Если эти истории – это все, что должна реализовать команда, то это хорошо. Существует вероятность, что заказчик заменит некоторые из историй более полезными для него. Никто не станет жаловаться, если вместо чего-либо он получит что-либо другое, более ценное. Однако недовольство и жалобы возникают тогда, когда кто-либо получает что-либо, о чем он просил, но при этом оказалось, что это не то, что ему нужно.
Вместо фиксированных цены/даты/объема работ команда ХР предлагает нечто наподобие подписки. Команда обязуется работать на заказчика с максимальной скоростью в течение определенного промежутка времени. Они будут следить за мнением заказчика относительно направления развития разработки. В начале каждой итерации заказчик получает формальную возможность изменить направление развития разработки и добавить совершенно новые истории.
Еще одно различие, связанное с применением ХР, заключается в использовании небольших версий. Вы никогда не должны работать над проектом ХР в течение 18 или даже 12 месяцев, не внедрив его в производственных условиях. Когда команда заключает контракт на реализацию историй в течение 12 месяцев, они играют с заказчиком в игру в планирование для того, чтобы определить объем работ, связанных с первой версией. Таким образом, когда речь идет о 12-месячном контракте, система начнет эксплуатироваться в производственных условиях спустя три или четыре месяца после начала работ, после этого новые версии будут выпускаться с периодичностью в один или два месяца. Постепенное введение системы в эксплуатацию обеспечивает заказчику возможность расторгнуть контракт в случае, если процесс разработки идет медленнее, чем планировалось, или если в результате изменения бизнес-условий реализация всего проекта потеряла смысл. Кроме того, так как проект развивается от итерации к итерации, на шкале времени у заказчика появляются точки, в которых он получает возможность изменить направление развития проекта.
Разработка чужими силами
Когда разработка осуществляется руками сторонних исполнителей (outsourcing), в результате у заказчика оказывается кусок кода, который неизвестно как поддерживать и модифицировать. В этом случае есть три варианта:• новую эволюцию системы можно выполнить своими силами;
• можно нанять для выполнения модификации системы тех же самых разработчиков, которые работали над ее созданием (однако они могут попросить за это слишком много денег);
• можно обратиться к другим разработчикам, которые плохо знакомы с кодом.
Если вы этого хотите, вы можете сделать это с использованием ХР. В этом случае либо команда идет работать к заказчику, либо заказчик посылает своих представителей к разработчикам. Они играют в игру в планирование для того, чтобы решить, что делать. Когда контракт завершается, команда уходит и оставляет заказчику код.
В некотором роде это может быть лучше, чем общепринятая форма соглашения о выполнении работ на стороне. У заказчика есть набор функциональных тестов и тестов модулей, которые позволяют ему удостовериться в том, что любые внесенные в систему изменения не нарушают существующей функциональности. Для заказчика будет удобно, если какой-либо его представитель будет стоять за спиной у программистов и вникать в то, как система устроена внутри. При этом заказчик получит возможность более точно руководить разработкой.
Разработка своими силами
Наверное, вам показалось, что я не в восторге от выполнения разработки чужими руками. Дело в том, что если разработка выполняется на стороне, это, как правило, означает, что существует некоторый акт приема-сдачи работы. Проект передается заказчику в виде большого единого продукта, готового к употреблению. Это нарушает принцип постепенного изменения. Однако существует некоторая весьма удобная вариация на эту тему, которую можно реализовать благодаря использованию ХР. Что, если вы постепенно будете заменять членов команды, занимающейся разработкой, техническими специалистами, которые являются сотрудниками фирмы-заказчика? Именно это я и называю выполнением разработки своими силами (insourcing).Разработка своими силами – это подчас малоэффективное занятие, так как собственные технические сотрудники подчас не обладают необходимыми для этого знаниями и опытом. Если разработка выполняется силами сторонних специалистов, заказчик получает в свое распоряжение систему, разработанную с использованием опыта и навыков специалистов действительно высокого класса, однако при этом он не знает, как устроена система и что делать, если возникает надобность в ее модификации.
Однако если в процессе работы вы постепенно заменяете чужих разработчиков своими, вы со временем постепенно перекладываете ответственность за разработку с чужих плеч на свои плечи. В результате у заказчика появляются знания об устройстве и функционировании системы, благодаря чему снижается риск того, что заказчик получит программу, которую он не сможет поддерживать.
Давайте рассмотрим пример простого соглашения между некоторым заказчиком и командой из десяти (10) разработчиков. Контракт заключается на 12 месяцев. Изначальная разработка осуществляется в течение 3 месяцев. Затем первая версия продукта начинает эксплуатироваться на производстве. После этого каждая очередная версия выпускается с периодичностью раз в месяц в течение 9 месяцев. На время изначальной разработки заказчик вводит в состав команды разработчиков одного своего представителя, который является техническим специалистом. После этого каждый очередной месяц заказчик вводит в состав команды по одному новому своему техническому специалисту, а исполнитель выводит из состава команды разработчиков одного из своих людей. В конце работы над заказом половина команды разработчиков – это люди заказчика, которые готовы осуществлять поддержку кода программы и продолжать дальнейшую разработку, правда, с меньшей скоростью.
В отличие от ситуации, когда разработка целиком и полностью возлагается на сторонних разработчиков, в условиях, когда состав команды разработчиков изменяется, разработка не может выполняться с такой же скоростью, как если бы состав команды оставался бы неизменным. Однако получаемое при этом снижение риска, возможно, стоит того.
ХР обеспечивает нормальное исполнение такой схемы за счет того, что команда постоянно измеряет скорость, с которой она работает. По мере того как происходит замена членов команды, скорость работы команды может меняться как в худшую, так и в лучшую сторону. Измеряя получаемую производительность, команда может вносить изменения в план итераций и влиять на объем работ в ходе игры в планирование. По мере того как эксперты будут уходить, а на их место будут приходить менее опытные люди, команда может выполнять переоценку оставшихся историй.
Время и материалы
В контрактах категории время и материалы (Time and Materials, T&M) команда ХР получает почасовую оплату. Все остальное работает так, как описывалось ранее.Проблема контрактов Т&М состоит в том, что мотивы исполнителя идут в разрез с мотивами заказчика. Исполнитель желает в течение как можно более длительного времени задействовать в работе над проектом как можно больше людей для того, чтобы максимизировать прибыль. Кроме того, исполнитель имеет тенденцию принуждать разработчиков работать сверхурочно, чтобы увеличить ежемесячную прибыль. Заказчик желает реализовать как можно больший объем функциональности за как можно более короткий срок с использованием как можно меньшего количества людей.
Благодаря хорошим отношениям между заказчиком и исполнителем схема Т&М может сработать, однако трение между ними всегда будет существовать.
Премия за завершение
Отличный способ уладить разногласия между заказчиком и исполнителем в рамках контракта с фиксированной ценой или Т&М – это учреждение премии за завершение проекта в срок. В некотором смысле премия за завершение проекта к сроку – это легкая добыча для команды ХР. Игра в планирование предоставляет команде столь удобный контроль над проектом, что, скорее всего, она без труда сможет получить эту премию.Обратной стороной премии за завершение работы в срок является штраф за опоздание. Если разработчики не успевают доделать проект к назначенной дате, заказчик платит им меньше, чем договаривались. И вновь благодаря игре в планирование команда ХР получает преимущество. Команда всегда уверена в том, что завершит работу в срок, поэтому ей вряд ли придется терять деньги.
Когда премия за завершение в срок или штраф за опоздание используются в рамках ХР, необходимо обратить внимание на важную особенность: игра в планирование подразумевает, что объем работ, связанных с проектом, неизбежно будет изменяться по мере работы над проектом. В процессе работы неизбежно будет возникать необходимость добавить новые истории и убрать из технического задания некоторые старые истории. Если заказчик горит желанием взять исполнителя за жабры, он может сказать примерно следующее: Сегодня первое марта, а полный набор историй, указанных в изначальном контракте, все еще не реализован. Никаких премий! Теперь вы будете платить неустойку! Заказчик может сказать подобное даже в случае, если система уже успешно эксплуатируется на производстве.
Как правило, подобной проблемы не возникает. Если наступает Рождество, а под елкой уже лежат подарки, у заказчика вряд ли возникает желание сверять точное соответствие этих подарков со списком, который он указал в письме к Сайта-Клаусу, особенно если сам заказчик просил о тех или иных заменах.
Если вы опасаетесь, что заказчик будет придираться, указывая вам на изначально составленный им список историй с целью отказать вам в премии, лучше вообще не иметь дело с таким заказчиком. Я не рекомендую вам подписывать с ним какие-либо контракты.
Раннее закрытие проекта
Одним из преимуществ ХР является то, что заказчик получает возможность видеть, что именно выходит из рук исполнителя по мере работы над проектом. Что, если на полдороге заказчик придет к выводу, что весь проект потерял для него актуальность? В этом случае, очевидно, для заказчика будет удобнее отказаться от дальнейшей разработки. На этот случай в контракте следует предусмотреть специальный параграф, который позволяет заказчику остановить работу над проектом и выплатить часть общей стоимости проекта пропорционально сделанной работе. Возможно, следует предусмотреть дополнительную выплату для компенсации исполнителю, так как в подобной ситуации исполнитель будет вынужден некоторое время тратить на поиск нового контракта.Программные инфраструктуры
Программная инфраструктура (framework) – это некоторый универсальный исходный код, который может использоваться в качестве основы при разработке разнообразных приложений определенной категории. В программную инфраструктуру могут входить библиотека классов, шаблоны программ и т. п. Программная инфраструктура может быть коммерческим продуктом, но это может быть и продукт для внутреннего пользования.Можно ли использовать ХР для разработки программных инфраструктур? Одно из правил ХР гласит, что вы должны удалять из системы любую функциональность, которая в данный момент не используется, если следовать этому правилу, то вы должны удалить всю инфраструктуру ХР не очень хорошо приспособлена для разработки кода, использование которого планируется не сейчас, а в дальнейшем. В рамках ХР-проекта вы не можете потратить шесть месяцев на разработку инфраструктуры, а затем приступить к ее использованию. Подход, подразумевающий разделение команды на группу разработки инфраструктуры и группу разработки приложения, тоже не подходит. В ХР мы занимаемся разработкой конкретных приложений. Если после нескольких лет постоянных переработок дизайна начинают вырисовываться некоторые универсальные абстракции общего использования, значит, настало время подумать о том, как сделать их более широко доступными.
Если цель проекта – разработка инфраструктуры для внешнего использования, вы по-прежнему можете использовать ХР. В игре в планирование на стороне бизнеса играет программист, который занимается разработкой приложений на базе инфраструктуры, которую вы разрабатываете. Возможности инфраструктуры превращаются в истории.
После того как инфраструктура начинает использоваться вне команды, вы можете применять более консервативный подход к переработке кода.
Вы предупреждаете заказчиков о предстоящем изменении или отказе от использования той или иной возможности и продолжаете эволюцию интерфейса вашей инфраструктуры, в течение некоторого времени сохраняя в ней как старую, так и новую версию интерфейса.
Продукты широкого использования
ХР можно использовать также для разработки программных продуктов для широкого потребительского рынка. В этом случае роль бизнеса в игре в планирование играет отдел маркетинга. Его сотрудники идентифицируют, в каких историях нуждается рынок, какой объем каждой из историй необходимо реализовать и в каком порядке следует реализовать эти истории.Иногда бывает полезно включить в состав игроков, играющих на стороне бизнеса, пользователя-эксперта. Например, компании, занимающиеся разработками компьютерных игр, могут нанять в качестве экспертов заядлых игроков в компьютерные игры, которые будут тестировать производимые ими игры. Производители финансовых программ могут нанять в качестве пользователей-экспертов профессиональных финансистов. Если вы производите музыкальный редактор, вы можете пригласить к себе в качестве эксперта профессионального композитора или музыканта. Пользователь-эксперт – это именно тот человек, который будет определять, какую из историй следует в первую очередь реализовать в следующей версии вашего программного продукта.
Заключение
Все методики основаны на страхе. Вы пытаетесь развить у себя привычки, которые помогут вам не допустить, чтобы ваши страхи воплотились в реальность. В этом отношении ХР ничем не отличается от любой другой методики. Разница состоит в том, что страхи запечатлены в ХР.
Методика ХР – это мое детище, и поэтому она отражает мои собственные страхи. Я боюсь:
• делать бессмысленную работу;
• останавливать проекты из-за того, что я не достиг достаточного технического прогресса;
• делать плохие бизнес-решения;
• иметь дело с плохими техническими решениями, которые сделаны за меня бизнесменами;
• прийти к концу карьеры разработчика программных систем и понять, что было бы лучше, если бы я больше времени проводил с детьми;
• делать работу, которой я не могу гордиться.
ХР также отражает вещи, которых я не боюсь:
• кодировать;
• изменять мой взгляд на вещи;
• продолжать работу, ничего не зная о будущем;
• надеяться на других людей;
• изменять анализ и дизайн функционирующей системы;
• писать тесты.
Я должен был научиться не бояться этих вещей. Это не пришло ко мне само собой, особенно если учесть, что так много людей говорили мне о том, что именно этих вещей и следует бояться и что я должен прилагать все свои усилия для того, чтобы избежать этих вещей.
Ой!
Я же сказал, в любой момент. Тык!
Ой!
Молодой человек схватил свой деревянный меч и грозно посмотрел на мастера.
О, я не буду тыкать в тебя сейчас, потому что сейчас ты только этого и ждешь.
В течение следующих нескольких дней ученик постепенно покрывался ссадинами и синяками. Он пытался сосредоточивать свое внимание на всем, что его окружало, но каждый раз, когда его внимание ослабевало, тык!
Ученик не мог спокойно есть, он не мог спокойно спать. Он стал параноиком. Он с величайшей осторожностью выглядывал из-за угла и постоянно замирал, пытаясь определить источник малейшего шума. Но каждый раз, когда он в изнеможении опускал глаза или забывал прислушаться, тык!
В скором времени он сел на землю и закричал в отчаянии: Я больше не могу этого вынести! Я никогда не стану фехтовальщиком! Я иду домой! В этот момент, еще не успев понять, что произошло, юноша самопроизвольно выхватил свой меч и молниеносно отразил удар мастера. Тут мастер сказал ему: Теперь ты готов к обучению.
Мы можем довести себя до безумия благодаря ожиданию. Но подготавливая себя к любому исходу дела, который мы только можем себе представить, мы оставляем себя беззащитными перед неожиданностями, о которых не подумали.
Существует другой путь. Команда может быть отлично подготовлена в любой момент идти в любом из направлений, куда потребуется двигаться бизнесу или системе. Отказавшись от намеренных приготовлений к изменениям, как это ни парадоксально, члены команды становятся полностью готовыми к любым изменениям. Они ничего не ждут. Их ничем невозможно удивить.
Методика ХР – это мое детище, и поэтому она отражает мои собственные страхи. Я боюсь:
• делать бессмысленную работу;
• останавливать проекты из-за того, что я не достиг достаточного технического прогресса;
• делать плохие бизнес-решения;
• иметь дело с плохими техническими решениями, которые сделаны за меня бизнесменами;
• прийти к концу карьеры разработчика программных систем и понять, что было бы лучше, если бы я больше времени проводил с детьми;
• делать работу, которой я не могу гордиться.
ХР также отражает вещи, которых я не боюсь:
• кодировать;
• изменять мой взгляд на вещи;
• продолжать работу, ничего не зная о будущем;
• надеяться на других людей;
• изменять анализ и дизайн функционирующей системы;
• писать тесты.
Я должен был научиться не бояться этих вещей. Это не пришло ко мне само собой, особенно если учесть, что так много людей говорили мне о том, что именно этих вещей и следует бояться и что я должен прилагать все свои усилия для того, чтобы избежать этих вещей.
Ожидание
Один юноша пришел к мастеру фехтования. Когда они сидели на солнышке рядом с хижиной мастера, мастер преподнес молодому человеку свой первый урок: Вот твой деревянный меч для тренировок. У меня тоже есть деревянный меч, и я могу ткнуть им в тебя в любой момент – при этом ты должен блокировать мой удар. Тык!Ой!
Я же сказал, в любой момент. Тык!
Ой!
Молодой человек схватил свой деревянный меч и грозно посмотрел на мастера.
О, я не буду тыкать в тебя сейчас, потому что сейчас ты только этого и ждешь.
В течение следующих нескольких дней ученик постепенно покрывался ссадинами и синяками. Он пытался сосредоточивать свое внимание на всем, что его окружало, но каждый раз, когда его внимание ослабевало, тык!
Ученик не мог спокойно есть, он не мог спокойно спать. Он стал параноиком. Он с величайшей осторожностью выглядывал из-за угла и постоянно замирал, пытаясь определить источник малейшего шума. Но каждый раз, когда он в изнеможении опускал глаза или забывал прислушаться, тык!
В скором времени он сел на землю и закричал в отчаянии: Я больше не могу этого вынести! Я никогда не стану фехтовальщиком! Я иду домой! В этот момент, еще не успев понять, что произошло, юноша самопроизвольно выхватил свой меч и молниеносно отразил удар мастера. Тут мастер сказал ему: Теперь ты готов к обучению.
Мы можем довести себя до безумия благодаря ожиданию. Но подготавливая себя к любому исходу дела, который мы только можем себе представить, мы оставляем себя беззащитными перед неожиданностями, о которых не подумали.
Существует другой путь. Команда может быть отлично подготовлена в любой момент идти в любом из направлений, куда потребуется двигаться бизнесу или системе. Отказавшись от намеренных приготовлений к изменениям, как это ни парадоксально, члены команды становятся полностью готовыми к любым изменениям. Они ничего не ждут. Их ничем невозможно удивить.
Словарь терминов
Там, где это возможно, ХР использует общеупотребительные, общепринятые и широко распространенные термины. Если некоторые используемые в рамках ХР концепции в значительной степени отличаются от концепций в других областях знаний, отличие подчеркивается за счет использования нового термина. Далее перечисляются наиболее важные термины из лексикона ХР.
Автоматизированный тест (automated test) – тестовый случай, который работает без какого-либо вмешательства со стороны человека. Тест проверяет способность системы выполнять вычисления и получать ожидаемые значения.
Версия (release) – набор историй, которые вместе обладают смыслом с точки зрения бизнеса.
График выполнения работ (commitment schedule) – дата выпуска очередной версии продукта. В ходе каждой итерации график выполнения работ пересматривается. Модификация графика выполняется при помощи переоценки и регенерации.
Заказчик (customer) – роль в команде ХР. Заказчик выбирает, какие истории должны быть реализованы в системе, какие из историй необходимо реализовать в первую очередь, а какие могут быть отложены. Заказчик также определяет тесты, благодаря которым можно убедиться в том, что истории корректно выполняются.
Игра в планирование (Planning Game) – процесс планирования в рамках ХР. Бизнес должен указать, что должна делать система. Разработчики указывают, сколько стоит каждая возможность и какой бюджет доступен в день/неделю/месяц.
Идеальное время программирования (Ideal programming time) – измерение времени работы во время формирования предварительной оценки. Вы задаете себе вопрос: Сколько может мне потребоваться времени для того, чтобы сделать это, если меня не будут отвлекать, если не будет никаких неприятностей, форс-мажорных обстоятельств, катастроф и аварий?
Инженерная задача (engineering task) – некоторая вещь, о которой программист знает, что ее должна делать система. Для реализации задачи необходимо отводить от одного до трех идеальных дней программирования. Большинство задач можно сформулировать напрямую на основании историй.
Инструктор (coach) – роль в команде ХР. Инструктор наблюдает за процессом как за единым целым и обращает внимание команды на надвигающиеся проблемы или на возможности улучшить процесс.
Исследование (exploration) – фаза разработки, на которой заказчик сообщает о том, что в общих чертах должна делать система.
История (story) – некоторая вещь, которую по желанию заказчика должна делать система. Работу над реализацией истории можно оценить в период от одной до пяти идеальных недель программирования. Истории должны быть подвержены тестированию.
Итерация (iteration) – период длительностью от одной до четырех недель. В начале этого периода заказчик выбирает истории, которые необходимо реализовать в течение итерации. В конце итерации заказчик может запустить свои функциональные тесты для того, чтобы убедиться, что итерация выполнена успешно.
Менеджер (manager) – роль в команде ХР. Менеджер занимается распределением ресурсов.
Партнер (partner) – человек, являющийся вашим напарником при программировании в паре.
Переоценка (reestimation) – ход во время игры в планирование, когда команда заново оценивает все оставшиеся истории, еще не реализованные в рамках текущей версии.
Переработка (refactoring) – внесение в систему изменений таким образом, что при этом поведение системы не меняется, однако улучшаются некоторые ее нефункциональные качества – простота, гибкость, понятность, производительность.
План итерации (iteration plan) – набор историй и набор задач. Программисты выбирают задачи и оценивают их.
Программирование парами (pair programming) – техника программирования предусматривает, что два человека в одно и то же время занимаются программированием одной задачи за одним компьютером, используя одну клавиатуру, одну мышь и один монитор. В ХР состав пар меняется, как правило, два раза в день.
Программист (programmer) – роль в команде ХР. Программист анализирует, проектирует, тестирует, программирует и интегрирует.
Производство (production) – фаза разработки, на которой заказчик реально использует систему для зарабатывания денег.
Ревизор (tracker) – роль в команде ХР. Ревизор измеряет текущее состояние процесса в численном выражении.
Регенерация (recovery) – ход во время игры в планирование, когда заказчик сокращает объем работ над текущей версией продукта, желая сохранить дату выпуска этой версии в случае, если либо предварительные оценки оказываются заниженными, либо скорость работы команды по тем или иным причинам снижается.
Системная метафора (system metaphor) – история, описывающая логику работы системы, которую могут рассказать любые участники проекта – заказчики, программисты и менеджеры.
Скорость команды (team speed) – количество идеальных недель программирования, которое может быть обеспечено командой за заданный промежуток календарного времени.
Тест модуля (unit test) – тест, написанный с точки зрения программиста.
Тестовый случай (test case) – набор воздействий на систему и соответствующих реакций системы. Воздействия на систему выполняются автоматически, так же автоматически выполняется проверка корректности реакций. Каждый тест должен оставлять систему в том состоянии, в котором она находилась до тестирования, благодаря этому тесты могут выполняться независимо друг от друга.
Фактор (коэффициент) нагрузки (load factor) – измеренное отношение между реальным календарным временем и идеальным временем программирования. Как правило, находится в пределах от 2 до 4.
Функциональный тест (functional test) – тест, написанный с точки зрения заказчика.
Энтропия (entropy) – тенденция системы к накоплению ошибок с течением времени и к существенному росту стоимости внесения в нее изменений.
Автоматизированный тест (automated test) – тестовый случай, который работает без какого-либо вмешательства со стороны человека. Тест проверяет способность системы выполнять вычисления и получать ожидаемые значения.
Версия (release) – набор историй, которые вместе обладают смыслом с точки зрения бизнеса.
График выполнения работ (commitment schedule) – дата выпуска очередной версии продукта. В ходе каждой итерации график выполнения работ пересматривается. Модификация графика выполняется при помощи переоценки и регенерации.
Заказчик (customer) – роль в команде ХР. Заказчик выбирает, какие истории должны быть реализованы в системе, какие из историй необходимо реализовать в первую очередь, а какие могут быть отложены. Заказчик также определяет тесты, благодаря которым можно убедиться в том, что истории корректно выполняются.
Игра в планирование (Planning Game) – процесс планирования в рамках ХР. Бизнес должен указать, что должна делать система. Разработчики указывают, сколько стоит каждая возможность и какой бюджет доступен в день/неделю/месяц.
Идеальное время программирования (Ideal programming time) – измерение времени работы во время формирования предварительной оценки. Вы задаете себе вопрос: Сколько может мне потребоваться времени для того, чтобы сделать это, если меня не будут отвлекать, если не будет никаких неприятностей, форс-мажорных обстоятельств, катастроф и аварий?
Инженерная задача (engineering task) – некоторая вещь, о которой программист знает, что ее должна делать система. Для реализации задачи необходимо отводить от одного до трех идеальных дней программирования. Большинство задач можно сформулировать напрямую на основании историй.
Инструктор (coach) – роль в команде ХР. Инструктор наблюдает за процессом как за единым целым и обращает внимание команды на надвигающиеся проблемы или на возможности улучшить процесс.
Исследование (exploration) – фаза разработки, на которой заказчик сообщает о том, что в общих чертах должна делать система.
История (story) – некоторая вещь, которую по желанию заказчика должна делать система. Работу над реализацией истории можно оценить в период от одной до пяти идеальных недель программирования. Истории должны быть подвержены тестированию.
Итерация (iteration) – период длительностью от одной до четырех недель. В начале этого периода заказчик выбирает истории, которые необходимо реализовать в течение итерации. В конце итерации заказчик может запустить свои функциональные тесты для того, чтобы убедиться, что итерация выполнена успешно.
Менеджер (manager) – роль в команде ХР. Менеджер занимается распределением ресурсов.
Партнер (partner) – человек, являющийся вашим напарником при программировании в паре.
Переоценка (reestimation) – ход во время игры в планирование, когда команда заново оценивает все оставшиеся истории, еще не реализованные в рамках текущей версии.
Переработка (refactoring) – внесение в систему изменений таким образом, что при этом поведение системы не меняется, однако улучшаются некоторые ее нефункциональные качества – простота, гибкость, понятность, производительность.
План итерации (iteration plan) – набор историй и набор задач. Программисты выбирают задачи и оценивают их.
Программирование парами (pair programming) – техника программирования предусматривает, что два человека в одно и то же время занимаются программированием одной задачи за одним компьютером, используя одну клавиатуру, одну мышь и один монитор. В ХР состав пар меняется, как правило, два раза в день.
Программист (programmer) – роль в команде ХР. Программист анализирует, проектирует, тестирует, программирует и интегрирует.
Производство (production) – фаза разработки, на которой заказчик реально использует систему для зарабатывания денег.
Ревизор (tracker) – роль в команде ХР. Ревизор измеряет текущее состояние процесса в численном выражении.
Регенерация (recovery) – ход во время игры в планирование, когда заказчик сокращает объем работ над текущей версией продукта, желая сохранить дату выпуска этой версии в случае, если либо предварительные оценки оказываются заниженными, либо скорость работы команды по тем или иным причинам снижается.
Системная метафора (system metaphor) – история, описывающая логику работы системы, которую могут рассказать любые участники проекта – заказчики, программисты и менеджеры.
Скорость команды (team speed) – количество идеальных недель программирования, которое может быть обеспечено командой за заданный промежуток календарного времени.
Тест модуля (unit test) – тест, написанный с точки зрения программиста.
Тестовый случай (test case) – набор воздействий на систему и соответствующих реакций системы. Воздействия на систему выполняются автоматически, так же автоматически выполняется проверка корректности реакций. Каждый тест должен оставлять систему в том состоянии, в котором она находилась до тестирования, благодаря этому тесты могут выполняться независимо друг от друга.
Фактор (коэффициент) нагрузки (load factor) – измеренное отношение между реальным календарным временем и идеальным временем программирования. Как правило, находится в пределах от 2 до 4.
Функциональный тест (functional test) – тест, написанный с точки зрения заказчика.
Энтропия (entropy) – тенденция системы к накоплению ошибок с течением времени и к существенному росту стоимости внесения в нее изменений.