Экстремальное программирование (Extreme Programming, XP) — это один из фреймворков гибкой разработки (Agile), который сфокусирован на инженерных практиках и повышении качества как самого продукта, так и жизни команды. В отличие от других подходов, XP даёт конкретные рекомендации, как именно писать код, проводить тестирование и организовывать работу, чтобы справляться с постоянно меняющимися требованиями заказчика.

Когда стоит применять XP?

Эта методология особенно эффективна в ситуациях с высокой неопределённостью и риском:

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

Пять ключевых ценностей XP

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

• Коммуникация. Разработка — это командный вид спорта, и успех напрямую зависит от качества общения. Лучший формат — живой диалог у доски, когда можно быстро набросать схему и обсудить идею.
• Простота. Нужно делать только то, что необходимо прямо сейчас, и самым простым из возможных способов. Не стоит усложнять код и добавлять функции, которые могут пригодиться в будущем.
• Обратная связь. Постоянная информация о том, что получилось, а что нет, позволяет команде вовремя корректировать курс. Это касается и отзывов заказчика, и результатов тестирования, и мнения коллег.
• Смелость. Чтобы быть эффективными, нужно не бояться признавать ошибки, отказываться от неудачных решений, экспериментировать и говорить руководству о проблемах.
• Уважение. Каждый член команды уважает коллег, их мнение и вклад в общее дело. Это основа для здоровой коммуникации и продуктивной совместной работы.

Двенадцать ключевых практик XP

Изначально XP включал 12 практик. Некоторые из них со временем трансформировались, но их суть остаётся неизменной.

• Планирование игры. Заказчик описывает нужные функции в виде коротких пользовательских историй, а команда оценивает их сложность и сроки.
• Частые небольшие релизы. Работа разбивается на короткие итерации, а новая версия продукта выходит как можно чаще.
• Метафора. Команда придумывает общий образ системы, чтобы у всех было единое понимание того, что они создают.
• Простой дизайн. Код должен быть максимально простым, без избыточных элементов, которые не нужны для решения текущих задач.
• Тестирование. Разработчики сначала пишут автоматические тесты, а только потом код, который должен эти тесты пройти.
• Рефакторинг. Постоянное улучшение структуры кода без изменения его поведения: удаление дублирования, упрощение логики.
• Парное программирование. Два разработчика работают за одним компьютером. Один пишет код, а второй анализирует его в реальном времени.
• Коллективное владение кодом. Любой член команды может взять на себя доработку любого участка кода, что позволяет распределять задачи гибко.
• Непрерывная интеграция. Код вливается в общий репозиторий несколько раз в день, и после каждого вливания автоматически запускаются тесты.
• 40-часовая рабочая неделя. Команда не должна работать сверхурочно. Выгорание и усталость убивают качество и производительность.
• Заказчик в команде. Представитель бизнеса постоянно находится в команде и оперативно отвечает на все вопросы, связанные с требованиями.
• Единый стандарт кода. Все пишут в едином стиле, поэтому код легко читать и поддерживать любому члену команды.

Практики XP в современном прочтении

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

• Работайте вместе. Поскольку живое общение — главный инструмент, вся команда должна сидеть в одном пространстве без перегородок.
• Полная команда. В команду входят все, кто необходим для создания продукта: от заказчика и аналитиков до тестировщиков и разработчиков.
• Прозрачное рабочее пространство. Информацию о прогрессе, планах и проблемах вывешивают на всеобщее обозрение.
• Энергичная работа. Сотрудники должны высыпаться, быть здоровыми и не перегруженными. Только в таком состоянии возможна творческая и продуктивная работа.
• Еженедельный цикл. Команда планирует и выполняет работу недельными итерациями, в конце которых у неё всегда есть работающий продукт для демонстрации заказчику.
• Ежеквартальный цикл. Это горизонт планирования для заказчика. Он определяет, какие возможности продукта будут готовы в ближайшие три месяца.
• Свободное время (слак). В план всегда закладывают небольшой резерв на случай непредвиденных задержек.
• Десятиминутная сборка. Вся система должна собираться, а все тесты прогоняться не дольше 10 минут, чтобы их можно было запускать после каждого изменения.
• Инкрементальный дизайн. Архитектура системы создаётся постепенно, по мере поступления новых требований.

Роли в XP

В экстремальном программировании нет строгих ролей, как, например, в Scrum. Однако выделяют несколько ключевых участников.

• Заказчик. Принимает все бизнес-решения: определяет, что должна делать система, в каком порядке, и на какую сумму бюджета можно рассчитывать.
• Разработчик. Все члены команды, кроме заказчика и вспомогательных ролей, считаются разработчиками. Именно они реализуют пользовательские истории.
• Трекер. Необязательная роль. Один из разработчиков в свободное время отслеживает метрики, например, скорость команды и количество ошибок.
• Коуч. Внешний консультант, который помогает команде освоить практики XP и избежать типичных ошибок новичков.

XP в сравнении с другими подходами

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

Происхождение и влияние

Экстремальное программирование зародилось в середине 1990-х годов, когда Кента Бека пригласили для спасения проекта по расчёту зарплат в Chrysler. Он перестроил процесс разработки, и к команде присоединились Рон Джеффрис и другие известные в будущем специалисты. Опыт этого проекта лёг в основу книг, которые и принесли XP мировую известность. Главный вклад XP в индустрию — это набор дисциплинированных инженерных практик, которые позволяют создавать качественный код, даже когда требования постоянно меняются.

Жизненный цикл проекта в XP

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