Постигая Agile

Следующая основная практика XP-команд – это информативное рабочее пространство, в котором производственная среда команды устроена таким образом, чтобы важная информация о проекте автоматически передавалась всем участникам. Один из наиболее популярных способов для этого – применение большой доски задач и диаграммы выполняемых работ (диаграммы сгорания), которые висят так, чтобы каждый мог их видеть. Наглядное размещение постоянно обновляемой информации о проекте позволяет каждому члену команды знать, на какой стадии находится проект, и принимать правильные решения. Такие диаграммы и другие способы, которые команда использует для отображения данных, делающие рабочее пространство более информативным, называются излучателями информации. Они автоматически передают текущую информацию о проекте всем, кто на них взглянет.

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

Почему важны информационные рабочие пространства? Суть в том, чтобы помочь команде принимать лучшие решения и дать ей больше контроля над ходом проекта – подобно тому, как доски задач помогают scrum-командам. Главное, что информация предназначается для всей команды, а не только для ее руководителей или менеджеров. Это демократизирует распространение информации и обеспечивает ею всю команду без какой-либо фильтрации. Чем больше сведений о проекте доступно команде, тем сильнее каждый ее участник может влиять на ход событий.

Почему команды противостоят изменениям и чем могут помочь практики

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

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

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

И разве можно их за это винить? Команды сопротивляются этим изменениям, особенно в конце проекта[50], потому что им предстоит дополнительная работа. И не просто работа – а самый плохой ее вариант, самый раздражающий. Изменения заставляют вас возвращаться к тому, что вы считали законченным, разносят сделанное в пух и прах и вынуждают переписывать большие куски кода заново. И это не просто разочаровывающая работа: ваша команда вложила в нее много душевных сил, решила массу проблем и нашла наиболее элегантные решения. А теперь вам говорят, что нужно разрушить созданный командой Тадж-Махал, потому что на самом деле нужна была Эйфелева башня.