Постигая Agile

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

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

Если команды отстают от графика, то они стремятся делать только то, что крайне необходимо, отбросив всякие «украшательства». Обычно они говорят: «Мы опаздываем, поэтому у нас нет времени писать модульные тесты» или «Было бы здорово, если бы мы могли назначить на каждую задачу по два программиста, но тогда мы сорвем сроки сдачи проекта».

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

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

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

Эффективное мышление начинается с ценностей ХР

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

Ценности ХР

Коммуникация

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

Простота

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

Обратная связь

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

Мужество

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

Уважение

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

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

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

Путь, вымощенный благими намерениями

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

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