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

Каждый член команды знает, что делают остальные.

Разработчики стараются создать максимально простое и прямое решение.

Постоянное тестирование и обратная связь держат качество продукта под контролем.

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

Каждый член команды ценен для проекта.

Все это абстрактные азбучные истины. Разве можно с ними не соглашаться?

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

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

Потом приходит реальность. Нам кажется излишеством, когда кто-то сидит рядом с нами, пока мы обдумываем и пишем код. Если единственная польза от парного программирования – дополнительная пара глаз, высматривающая ошибки, то для нее есть более эффективное применение. Анализ кода после его написания позволяет отлавливать ошибки с такой же вероятностью (точно такой же анализ можно провести после сессии парного программирования). Но если у вас мало времени из-за приближающегося срока сдачи, то легко убедить себя в том, что обзор кода почти так же хорош, как и парное программирование. «Это разновидность парного программирования, потому что я подключаю кого-то еще!»

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

Все эти утверждения справедливы. Но в каждом случае это означает делать «лучше-чем-ничего» и, соответственно, получать такие же результаты.

Вернемся к цитате Кента Бека, приведенной выше: «Сами по себе практики непродуктивны. Вне связи с поставленными целями они становятся пустым звуком». Примерно то же самое Кен Швабер сказал о Scrum, самоорганизации и коллективной ответственности: каждая ХР-практика делает гораздо больше, чем просто обеспечивает лишний взгляд на код, заставляет людей сидеть в одной комнате или добавлять тесты в базу кода. Они помогают команде привнести XP-ценности в проект.

Вот почему упрощения, которые делают, казалось бы, то же самое, что XP-практики, дадут лишь результат «лучше-чем-ничего». Они меняют методику работы команды, но не влияют на ее намерения и образ мышления.

Обычно при знакомстве с ХР команды не обращают внимания на ценности, потому что практики кажутся им интереснее. Многие разработчики открывают книгу об ХР, быстро просматривают раздел, посвященный ценностям, а затем ищут практики.

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

Воспринять ценности командам гораздо сложнее. Они более абстрактны, оказывают влияние на весь проект и на то, как каждый его воспринимает. Можно механически добавить практики в проект, не понимая ценности (что дает результат «лучше-чем-ничего»). Но разобраться в ценностях без предварительного опыта работы с практикой – труднее.

Для XP в этом нет ничего особенного. Это же относится и к Scrum. Для вводных курсов по Scrum типично показать ценности на паре слайдов и рассказать о них в двух словах, а затем сразу перейти к «сути» тренинга – практикам. Но не стоит слишком многого требовать от тренеров. Гораздо проще обучать применению отдельных практик XP или Scrum, чем пытаться изменить мировоззрение слушателей. Большинство тренеров знают, что, если они уделяют много внимания ценностям, то слышат от разработчиков такие упреки: «слишком много теории» и «это не дает им информации, которую мы можем применить в своих проектах». Эта реакция вполне объяснима: трудно понять, почему ценности имеют практическое значение, пока вы их не усвоите. И невозможно сразу понять, почему практики не работают по-настоящему без ценностей, так что разработчики попадают в ловушку.

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

Вот несколько примеров.

Даниэль и Джастин не говорили о проблемах с применением нужной практики. И они точно не рассказывали Бриджит о реальном состоянии дел, так что в случае проблем с проектом она легко обвинила бы их в том, что они скрывали правду.

Код Джастина становится все сложнее и запутанней. Он способен работать лучше, но у него не хватает времени.

Когда Джастин и Даниэль перестали работать в паре, они почти прекратили общаться. Если бы Даниэль продолжала просматривать его код и давала ему обратную связь, то, возможно, не было бы такого беспорядка. И несмотря на то, что рабочее пространство дает больше информации, она не помогала людям принимать более обоснованные решения. Выяснение, «насколько глубоко команда освоила ХР», не делает программное обеспечение лучше.

Если команда не надеется закончить проект вовремя и понимает это, то требуется много мужества, чтобы рассказать правду, – особенно если за это грозит увольнение. У Даниэль и Джастина не хватило мужества.

Требовать от команды выполнить проект в заведомо нереальные сроки – это верх неуважения к ней. Бриджит неоднократно устанавливала невероятно жесткие сроки. Хуже то, что она не чувствовала потребности быть рядом с людьми и знать, чем они живут. Например, как в случае, когда она назначила встречу вечером в пятницу и потребовала от команды внести множество исправлений к утру понедельника. И пока разработчики все выходные трудились в поте лица, она отдыхала. (Это не вошло в главу, но нам доподлинно известно, что так все и было.)

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

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

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

Как это помогает команде познакомиться с XP-ценностями?

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

Вот как использование ХР-практик помогает формировать мышление команды.

Но вам не обязательно приступать к внедрению практик, чтобы узнать, совместимо ли мышление команды с ХР. Для этого достаточно ответить на несколько вопросов.

• Как воспримет команда ситуацию, когда часть написанного кода придется выбросить, потому что он не работает? Как отнесется к этому руководство?

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

• Если младший программист получает задачу, то дает ли ему команда полномочия довести ее до конца? Что если она не согласна с его подходом или кто-то считает, что он выполнит ее быстрее? Допустимо ли, что разработчик может не справиться с заданием, но извлечет из этого урок?

Так что же вы предпринимаете, когда ваша команда не до конца освоила ХР-ценности?