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

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

Разработка программного обеспечения – это игра на понимание, и прозрение приходит к подготовленному, отдохнувшему, расслабленному разуму. Кент Бек. Extreme Programming Explained: Embrace Change

Разработка программного обеспечения – это игра на понимание, и прозрение приходит к подготовленному, отдохнувшему, расслабленному разуму.

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

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

Чтобы разработчик вошел в состояние «потока», включающее в себя высокую концентрацию и максимальную продуктивность[67], требуется время (обычно от 15 до 45 минут). Перерывы и отвлекающие факторы могут вывести его из этого состояния. Но когда он находится под давлением необходимости поставить код в немыслимые сроки, войти в «поток» невозможно. Он так стремится поскорее разделаться с кодом, что ему некогда думать.

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

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