Читаем Постигая Agile полностью

Но у медали есть и другая сторона. Пользователь или руководитель, просивший в начале проекта одно, а к концу изменивший свои требования, делает это вовсе не с целью дезорганизовать команду. Мы уже знаем, что раздробленное видение приводит к плохим результатам, так что давайте попробуем взглянуть на эту проблему со стороны пользователя. Ему нужно программное обеспечение, позволяющее выполнять свои задачи, а это означает, что он должен сотрудничать с командой разработчиков. Теперь его просят ответить на вопросы, которые ему не совсем понятны: «Кто должен иметь доступ к этой функции?»; «Сколько людей будут использовать эту систему одновременно?»; «Каково допустимое время между нажатием кнопки “начать” и отображением результатов?»; «Какова правильная последовательность действий?»

То, что начиналось как встреча, на которой пользователь пытался объяснить свою проблему, каким-то образом превратилось в бесконечный поток обращенных к нему технических вопросов, на которые он не знает ответов. А время-то идет, и он чувствует: если не дать ответы на все вопросы, то команда отложит выполнение проекта и обвинит в этом его. (Будем честны: именно так она, скорее всего, и поступит.) Все знают, что создание ПО – дорогое удовольствие, а пользователь – не специалист в этом, поэтому дает самый лучший ответ, на который способен. И когда встреча заканчивается, он не мешает команде двигаться вперед и сжигать бюджет.

Как решить эту проблему? Кто прав?

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

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

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

Адаптация к изменениям имеет два аспекта: степень охвата проекта и собственно база кода. Влияние изменений на код иногда бывает значительным – изменение, которое первоначально казалось маленьким, может ошеломить команду, потребовав существенного переписывания. Команды будут говорить о необходимости «разодрать код» и заделать дырки «скотчем, скрепками и жевательной резинкой». Мы рассмотрим тему адаптации к изменениям в главе 7. А пока обсудим, как XP-команды приспосабливаются к изменениям масштабов проекта, функциональности программного обеспечения и его поведения.

Так как же основные практики XP помогают командам делать это?

Планирование

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

Команда

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

Интеграция