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

Постоянно продолжающаяся интеграция

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

Однако в ХР:

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

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

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

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

40-часовая рабочая неделя

Вы не можете работать только 40 часов в неделю. Вы не успеете выполнить весь необходимый объем работ.

Однако в ХР:

• игра в планирование заставляет вас делать наиболее важную работу в первую очередь;

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

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

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

Заказчик на месте разработки

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

Однако в ХР:

• представитель заказчика приносит пользу для проекта, так как он пишет функциональные тесты (предприятию-заказчику все равно придется этим заниматься);

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

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

Стандарты кодирования

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

Однако в ХР:

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

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

Заключение

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

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

Рис. 4. Диаграмма, иллюстрирующая взаимодействие всех методик

Глава 12. Стратегия менеджмента

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

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

Мы знаем, что эта стратегия не срабатывает, так как ни один человек в мире не знает достаточно