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

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

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

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

Agile-команды иногда забывают, что бизнесмены завалены работой. Это приводит к естественной потере связи между командами-разработчиками и предпринимателями, для которых они создают программное обеспечение.

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

Рис. 3.4. Некоторые функции более значимы для компании, чем остальные. Команде нужно сбалансировать ценности (сколько стоит функция) по отношению к затратам (сколько потребуется работы для ее создания) при определении, какие из них следует включить в каждую итерацию

Команды между тем хотят иметь как можно больше контактов с предпринимателями.