Что такое XP (eXtreme Programming) и кому оно подходит
Рассказываем о самой экстремальной методологии из семейства Agile и ее особенностях
В разработке легко оказаться перед жестким выбором: быстро или качественно, просто или надежно. Экстремальное программирование предлагает радикальный ответ: довести полезные практики до предела. В этой статье мы разберем, чем такой подход отличается от привычных процессов и почему он подойдет не каждой команде.
Что такое экстремальное программирование
Экстремальное программирование (англ. eXtreme Programming, XP) — это методология гибкой разработки, в основе которой короткие циклы, частая обратная связь и постоянное взаимодействие внутри команды.
Название «экстремальное» связано с тем, что уже существующие практики довели до предела. Вот как суть экстремальности интерпретирует автор методики Кент Бек:
- Если код-ревью приносит пользу, мы будем проверять код на постоянной основе — через парное программирование.
- Если тестирование дает результат, тестировать станут все и всегда: разработчики — с помощью модульных тестов, заказчики — через функциональное тестирование.
- Если проектирование действительно важно, оно войдет в ежедневную практику каждого — в форме регулярного рефакторинга.
Методология XP входит в семейство подходов и инструментов гибкой разработки Agile. Подробнее об этом можно прочитать в этой статье. Но, несмотря на популярность гибких процессов, экстремальное программирование редко встречается в компаниях.
У экстремального программирования есть 2 основные практики
И это парное программирование и разработка через тестирование:
Парное программирование. Это подход, при котором два разработчика сидят за одним компьютером или созваниваются по видеосвязи. Один печатает код, второй следит за логикой и подсказывает. Через некоторое время они меняются ролями.
На первый взгляд кажется, что команда теряет скорость: два человека делают работу одного. Но на деле — меньше багов, а значит, уходит меньше времени на исправления.
Например, при разработке интернет-магазина один разработчик пишет логику корзины, а второй замечает, что забыли про проверку наличия товара. Ошибку исправляют сразу, а не через неделю тестирования.
Разработка через тестирование (англ. Test-Driven Development, TDD). Это методика разработки, при которой автоматизированные тесты пишут раньше самого кода. Описать такой подход можно через цикл red → green → refactor. Он устроен так:
- Программист формулирует, что функция должна делать.
- Пишет тест, который описывает действия функции.
- Тест сразу падает, потому что кода еще нет.
- После этого пишут самый простой код, чтобы тест прошел.
- Когда тест «позеленел», можно улучшить внутреннюю структуру кода (рефакторинг), при этом тесты гарантируют, что поведение осталось правильным.
Другие особенности XP, которые связаны с технической частью
Простая архитектура. Методология XP не требует строить идеальный фундамент «на все времена». Команда делает ровно столько, сколько нужно для текущей задачи. Если завтра бизнес меняет требования, архитектуру можно переработать. Это же может касаться и дизайна: сначала создаем что-то максимальное простое и рабочее и только при необходимости улучшаем его в будущем.
Рефакторинг. Команда постоянно улучшает структуру существующего кода без изменения его логики. Это делает код чище и понятнее.
Непрерывная интеграция. Код до нескольких раз в день объединяют в общую ветку и сразу проходит автоматические тесты. Благодаря этому ошибки выявляются быстро, и система остается в рабочем состоянии.
Программирование по стандартам. Команда договаривается о правилах: как называть переменные, как форматировать код. Это упрощает чтение и поддержку. Пример: разработчик открывает чужой файл и сразу понимает, где описаны классы, а где методы, потому что везде единый стиль.
Особенности командной работы при eXtreme Programming
Эти особенности помогают синхронизировать команду и обеспечить нужный ритм разработки:
Небольшие команды. Экстремальное программирование подразумевает, что в команде работают не более 12 человек. Если людей будет больше, наладить между ними коммуникацию и сделать разработку гибче будет сложнее.
Коллективное владение кодом. Любой разработчик может внести изменения в любую часть системы. Это избавляет от ситуации, когда «этот модуль знает только Вася». Например, если Вася заболел, а именно в его модуле нашли критичный баг, команда не ждет его возвращения. Любой другой разработчик заходит в код, вносит исправления и выкатывает релиз.
40-часовая рабочая неделя. XP избегает хронических переработок: усталость ведет к ошибкам и снижает качество кода. Команда работает в устойчивом ритме, что важно для долгосрочной продуктивности.
Клиент доступен в любой момент. Заказчик или его представитель работает рядом с командой и отвечает на вопросы в реальном времени. Это уменьшает риск недопонимания и ускоряет принятие решений.
Достигнуть цели помогает соблюдение ценностей XP
В основе методологии 5 ценностей:
Коротко про каждую ценность:
- Обратная связь — команды получают ее как можно чаще, чтобы корректировать методы работы.
- Смелость — сотрудникам должно хватать решимости говорить о сложностях или организационных проблемах, а также признавать неудачные решения.
- Простота решений — важно избегать перегруженных решений, которые может быть сложно поддерживать в будущем. Это помогает предотвратить потери. Такой принцип близок к подходу Lean.
- Уважение — сотрудники должны уважать мнение остальных, чтобы выстраивать с ними конструктивный диалог.
- Коммуникация — для успешной работы сотрудникам важно чаще взаимодействовать и обсуждать задачи лично, поэтому XP часто подразумевает работу в одном пространстве. Альтернатива — работа в единой системе для управления проектами, где видно список задач и их статусы.
Сравнение eXtreme Programming и Scrum
Короткие циклы поставки, адаптивность к новым требованиям и частая обратная связь — все это напоминает Scrum, популярный фреймворк Agile. И если начать работу в новом проекте, который работает по Agile, может быть сложно понять, какой именно подход использует команда. Однако несмотря на сходство, у них есть различия. Собрали их в таблицу:
Ограничения и недостатки eXtreme Programming
Экстремальное программирование — специфичная методика, которая подходит не всем. Дело не только в ориентированности на IT-команды, но и в сложности, которые XP может доставить командам. Вот некоторые из них:
Трудно организовать работу с заказчиком. XP требует, чтобы заказчик или его представитель был доступен ежедневно. Он должен отвечать на вопросы, приоритизировать задачи и принимать решения. На практике это сложно. Если заказчик занят другими делами, команда теряет ритм: разработчики ждут ответа, работа останавливается.
Сложности масштабирования. XP хорошо работает в небольших командах. Но если проект разрастается, появляется больше десятка разработчиков, синхронизировать всех становится проблемой. Например, если над системой одновременно работают три команды, коллективное владение кодом превращается в хаос: правки пересекаются, багов становится больше, чем пользы.
Конфликты из-за «коллективного кода». В XP нет «моего» и «твоего» участка системы — любой разработчик может менять любой модуль. Но это требует высокого уровня доверия и единого стиля кода. Если в команде нет договоренности, один пишет так, другой иначе, кодовая база быстро теряет целостность.
Неравномерный эффект для разных типов проектов. XP лучше всего проявляет себя там, где продукт можно выкатывать часто и быстро проверять гипотезы. В долгосрочных и тяжеловесных проектах с жесткой регуляцией методика вызывает больше проблем, чем пользы. Для них больше подойдет каскадная модель.
Парное программирование подходит не всем. Работать в паре с другим разработчиком — лишь один из элементов экстремального программирования, но он может негативно сказаться на команде. Если кто-то из сотрудников не хочет работать в таком формате, то есть риск, что со временем он захочет уйти из проекта.
Что такое экстремальное программирование: саммари
- Экстремальное программирование — это Agile-подход, который доводит полезные практики до максимума.
- Ключевые практики: парное программирование и разработка через тестирование снижают количество ошибок и упрощают поддержку кода.
- Технические принципы: простая архитектура, постоянный рефакторинг и непрерывная интеграция поддерживают качество продукта.
- Командные правила: небольшие группы, коллективное владение кодом, устойчивая нагрузка и постоянная доступность заказчика.
- Ценности XP: обратная связь, смелость, простота решений, уважение и коммуникация формируют культуру команды.
- Ограничения: XP сложно масштабировать, требует высокой вовлеченности клиента и не подходит для длительных проектов с фиксированными требованиями.
