Читать онлайн «Экстремальное программирование». Страница 19

Конечно же, для этого необязательно, чтобы рабочих часов в неделе было бы ровно 40. Разные люди способны эффективно работать в течение различного времени. Один человек не может концентрировать свое внимание дольше, чем в течение 35 рабочих часов, другой способен успешно действовать в течение 45 часов в неделю. Но никто не способен работать по 60 часов в неделю на протяжении многих недель и при этом оставаться свежим, творческим, внимательным и уверенным в своих силах. Ни в коем случае не делайте этого!

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

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

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

Основным препятствием для воплощения этого правила является то обстоятельство, что реальные пользователи разрабатываемой системы обходятся для заказчика слишком дорого в смысле рабочего времени. Иногда менеджерам заказчика жалко жертвовать одним из реальных служащих компании только для того, чтобы он постоянно находился вместе с разработчиками и отвечал на их вопросы. Менеджеры должны решить, что является для них более важным – ускорение и повышение качества разработки или рабочее время одного или двух сотрудников. Если программная система не приносит бизнесу больше, чем приносит ему один из сотрудников предприятия, скорее всего, такая система не стоит того, чтобы ее разрабатывать и внедрять на производстве.

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

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

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

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

Стандарт должен требовать от разработчиков приложения минимально возможных усилий для реализации той или иной возможности. Он должен способствовать воплощению на практике правила трех О – Once and Only Once (запрет на дублирование кода). Стандарт должен способствовать коммуникации. Наконец, стандарт должен быть добровольно воспринят всей командой разработчиков. 

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

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

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

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

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

Однако в ХР:

• заказчики выполняют обновление плана самостоятельно, на основании оценок, которые делаются программистами;

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

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

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

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

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

Однако в ХР:

• игра в планирование помогает вам работать над наиболее важными историями, поэтому даже небольшая система в состоянии приносить пользу бизнесу;

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