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

Это один из Agile подходов к организации процесса разработки ПО. В основе подхода лежит ряд важных ценностей (например, коммуникация) и специфических практик (например, парное программирование).

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

Начать можно как "снизу" (новые практики, такие как парное программирование), так и "сверху" (внедрение ценностей XP и Agile). Дайте команде время на изменения и позвольте им совершать ошибки.

Как и у каждого фреймворка, в экстремальном программировании есть свои ценности, практики, принципы работы, роли.

Давайте разберем этот фреймворк более детально.

В экстремальном программировании выделяются пять ценностей. Они — основа, на котором держится этот фреймворк.

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

• Коммуникация [Communication]

• Простота [Simplicity]

• Обратная связь [Feedback]

• Смелость [Courage]

• Уважение [Respect]

Целью реализации XP является более качественный код и, соответственно, более качественный продукт.

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

Эти две цели — качество продукта и качество жизни — являются ключевыми. Однако, конечно, ими не исчерпываются преимущества XP.

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

В XP довольно много практик и рекомендаций, как организовать рабочий процесс.

В принципе, их можно практиковать и изолированно, что иногда и делается. При такой изолированной реализации отдельных практик может быть сложно сказать, когда у вас именно Extreme Programming, а когда — нет. Здесь нет четких рамок.

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

Давайте разберем некоторые ключевые практики, которые наиболее явно характеризуют этот подход к разработке.

«Одна голова хорошо, а две — лучше». В экстремальном программировании работа ведется двумя людьми за одной машиной.

Идея такого метода в том, чтобы ускорить работу и сделать её более сфокусированной.

Так при написании кода сразу можно получить обратную связь и корректировать путь. За счет этого приходится писать меньше кода.

Здесь вся команда работает над достижением нужного результата. В экстремальном программировании команда кроссфункциональна, при этом могут быть разные роли.

У вас может быть «Заказчик» (Customer), который определяет требования и то, что нужно сделать. Хорошо, если это конечный пользователь, который разбирается в том, что нужно. Также могут быть программисты, тестировщики, аналитики, менеджеры, коучи.

Ни одна из этих ролей не является обязательной — скорее такое распределение возможно.

Стремиться же стоит к максимальной кроссфункциональности, когда каждый член команды помогает тем, чем может, и что у него получается лучше всего.

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

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

Так с одной стороны поощряется коммуникация, с другой — дается безопасное пространство.

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

Хотя эта практика про энергичность, она значит не то, чем может показаться с первого раза.

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

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

Чтобы работать хорошо, программисту нужно быть в ресурсном состоянии. В таком состоянии, в котором он может работать больше всего.

Эта практика относится как к менеджменту, и означает, что не следует перегружать сотрудника чрезмерно. Она относится также и к самим специалистам — им не следует позволять перегружать себя, они должны открыто говорить, если им требуется отдых.

В экстремальном программировании используются «пользовательские истории» (User Story) для описания требуемого функционала в терминах, понятных любому человеку или по крайней мере конечному пользователю.

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

Также User Story помогают собирать обратную связь, поскольку на этом языке проще говорить с пользователем.

В экстремальном программировании работа происходит итерациями — конкретными промежутками времени.

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

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

Также такая работа является более сфокусированной, за счет того, что в работу берутся наиболее приоритетные элементы.

Ежеквартальный цикл — это итерация более длительного порядка. Этот цикл нужен, чтобы не потерять стратегическую перспективу — видение того, каким вообще должен быть релиз и что там должно быть.

Таким образом, каждая еженедельная итерация осуществляется с пониманием того, что должно быть реализовано в квартал.

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

Однако, если такие изменения есть, их можно обсуждать в начале каждой еженедельной итерации.

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

Это хорошо для сбора обратной связи и максимально быстрого внесения корректировок, если они требуются.

А бизнес и клиент максимально быстро получают ценность.

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

Это улучшает качество кода и снижает количество дефектов.

Почему?

Если каждый отвечает только за «свой код», это приводит к тому, что если человеку нужно добавить код туда, куда он не может, он делает это там, где этого делать не нужно — в той части, за которую отвечает он.

Кроме того, коллективное владение кодом приводит к тому, что все неясности проясняются через коммуникацию (парное программирование). Если возникает ошибка — непрерывная интеграция на это укажет.

В экстремальном программировании считается ценным мгновенное выявление всех ошибок. И интеграция кода — не исключение.

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

Extreme Programming исповедует другой принцип: «Если это больно — делай это чаще».

За счет того, что все конфликты выявляются максимально быстро, их можно раньше исправить — до того, как будет проделана большая работа, которая может уйти в пустую.

Как видно из перечисленного, основу XP составляют ценности и практики.

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

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