Экстремальное программирование

стресса люди начинают вести себя по-старому, как бы плохо это ни было.

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

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

Однако для начала вы должны научиться играть в соответствии с правилами. Вот они.

Цель

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

Стратегия

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

И так далее.

Куски

Куски (pieces) в игре в планирование – это карточки историй (story cards). Пример одной из них показан на рис. 6.

Рис. 6. Карточка с историей (story card)

Игроки

В игру в планирование играют два игрока – бизнес (Business) и разработчики (Development). Разработчики – это люди, которые отвечают за реализацию системы. Бизнес – это люди, которые принимают решения о том, что должна делать система.

Иногда сразу ясно, кто именно должен играть на стороне бизнеса. Если компания – биржевой брокер платит деньги за разработку специализированного программного обеспечения, значит, эти люди играют на стороне бизнеса. Именно они должны определить, что необходимо сделать в первую очередь. Но если вы занимаетесь разработкой программного продукта, который предназначен для массового рынка? Кто тогда играет роль бизнеса? Бизнес должен принимать решения относительно объема работ, приоритетов и содержимого версий продукта. Все эти решения, как правило, делаются сотрудниками отдела маркетинга. Если это достаточно умные люди, они будут принимать решения исходя из мнения:

• реальных пользователей продукта;

• заинтересованных в продукте групп;

• людей, занимающихся продажами.

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

Ходы

Игра состоит из трех фаз:

• исследование (exploration) – в этой фазе необходимо определить, что нового должна делать система;

• подтверждение (commitment) – в этой фазе необходимо решить, какое подмножество всех возможных требований необходимо удовлетворить в следующую очередь;

• управление (steer) – в этой фазе необходимо управлять разработкой по мере того, как реальность вносит свои коррективы в план.

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

Фаза исследования

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

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

• Оценка истории – разработчики делают оценку времени, которое потребуется для реализации истории. Если разработчики не могут оценить историю, они просят бизнес предоставить дополнительные разъяснения либо разделить историю. Чтобы оценить историю, можно спросить самого себя: Какое время потребовалось бы мне для того, чтобы реализовать историю, если эта история была бы всем, что мне необходимо реализовать, и при этом меня никто не отвлекал бы и мне не надо было бы ходить на совещания? В рамках ХР мы обозначаем данный показатель термином идеальное время разработки (Ideal Engineering Time). Как будет показано позже (в разделе Определение скорости), прежде чем приступить к составле нию графика работ, вы определяете коэффициент между идеальным временем и календарным.

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

Фаза подтверждения

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

• Сортировка в соответствии с ценностью – бизнес разделяет истории на три категории: (1) истории, без которых система не сможет функционировать, (2) истории, которые являются менее важными, но обеспечивают значительную полезность для бизнеса, (3) истории, которые было бы неплохо реализовать в рамках программного продукта.

• Сортировка в соответствии с риском – разработчики разделяют истории на три категории: (1) истории, которые можно оценить с высокой степенью точности, (2) истории, которые