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

Обслуживание и поддержка

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

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

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

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

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

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

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

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

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

Оглавление книги