Постигая Agile

(Существует еще одна практика-следствие, о которой мы будем много говорить, – анализ первопричин и метод пяти «почему», который поможет уловить за внешними проявлениями суть проблемы. Мы вернемся к этому в главе 8.)

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

Практик-следствий действительно 11? Почему их так много?

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

В главе 7 вы узнаете о том, как XP-практики работают вместе и оказывают значительное влияние на то, как команда проектирует и создает код. Пока вы будете ее читать, постарайтесь найти варианты совместной работы практик и понять, как они при этом взаимно усиливаются. Это позволит вам выйти за рамки формального мышления и воспринять ХР как целостную систему.

Что вы можете сделать сегодня

Предлагаем несколько вариантов действий, которые вы можете предпринять уже сегодня (самостоятельно или вместе с командой).

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

• Если вы разработчик, попробуйте непрерывную интеграцию. Вам даже не нужно привлекать к этому остальную команду (пока). В следующий раз, когда вы достигнете ключевой точки, в чем бы она ни заключалась, возьмите последний код из хранилища контроля версий, поместите его в вашу песочницу и проведите тестирование, чтобы убедиться: код интегрирован. Сделайте это снова через несколько часов. Насколько часто вы сталкиваетесь с проблемой интеграции, которую легко решить сейчас, но гораздо сложнее позднее?

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

Где вы можете узнать больше

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

• Вы можете узнать больше о методах, ценностях и принципах XP в книге Кента Бека и Синтии Андрес Extreme Programming Explained: Embrace Change (Addison-Wesley, 2004).

• Узнайте больше о модульном тестировании и разработке через тестирование в книге Энди Ханта и Дэйва Томаса Pragmatic Unit Testing (Pragmatic Bookshelf: Java version 2003, C# version 2007).

Подсказки

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

• Это один из самых сложных аспектов agile-коучинга, особенно для agile-тренеров, которые не имеют опыта программирования. Сосредоточьтесь на ХР-ценностях и принципах и помогите команде выяснить, как они влияют на код.

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