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

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

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

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

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

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

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

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

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

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

Хорошо умереть – это также  важно, как и хорошо жить. Для ХР это является такой же истиной, как и для людей.

Если заказчик больше не может придумать  ни одной новой истории, значит, наступило  время хорошенько посыпать систему  нафталином. Теперь необходимо написать пяти-, может быть, десятистраничное описание системы – документ, который может вам потребоваться в случае, если через пять лет вы захотите что-то изменить внутри.

Это хорошая причина для того, чтобы умереть, – заказчик доволен системой и не может придумать ничего, что можно было бы добавить в систему в обозримом будущем (я никогда с таким не сталкивался, однако я слышал об этом, поэтому я рассматриваю этот вариант для полноты картины).

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

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

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

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