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

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

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

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

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

Очень часто вам сообщают, что нужно изменить курс, после того как вы его выбрали.

Если этот человек уже объяснил, что именно нужно делать, и вы наполовину выполнили его требования, то вас очень огорчит его неожиданное заявление: «Я подумал вот о чем – а не можем ли мы создать что-то совсем другое?» Он не уважает ваш труд. Теперь вам придется внести изменения в уже сделанное. Трудно при этом не испытать возмущения! И хуже всего приходится тому, кто несет ответственность за результат и не соблюдает сроки.

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