Экстремальное программирование (или XP, от англ. eXtreme Programming) - это гибкая методология разработки программного обеспечения. В рамках этой методологии, как и в других agile-методологиях, используются специальные инструменты, процессы и роли. Создатель XP не изобрел ничего нового, но взял лучшие практики гибкой разработки и усилил их до предела, отсюда и название "экстремальное программирование".

Методология была создана американским разработчиком Кентом Беком. В конце 90-х годов он руководил проектом Chrysler Comprehensive Compensation System, где впервые применил практики экстремального программирования. Он описал свой опыт и созданную концепцию в книге "Extreme Programming Explained", опубликованной в 1999 году. После этого были выпущены другие книги, подробно описывающие практики XP. К созданию методологии также причастны Уорд Каннингем, Мартин Фаулер и другие.

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

Принципы

1. Игра в планирование - в настоящее время известна как SCRUM. Это идея создания программного обеспечения небольшими частями, основанными на приоритетном списке задач.
2. Малые выпуски - идея, что развертывания должны быть частыми и поэтапными.
3. Метафора - концепция Эрика Эванса из его книги "Дизайн, управляемый предметной областью". Это представление о том, что структура системы основана на простой модели проблемной области.
4. Простой дизайн - идея, что систему всегда следует поддерживать максимально простой, вне зависимости от возможных будущих проблем.
5. Тестирование - идея, что программисты и клиенты пишут автоматические тесты, проверяющие, что программа действительно делает то, что она должна. Сейчас это называется разработкой через тестирование (TDD) и разработкой через приемочное тестирование (ATDD).
6. Рефакторинг - идея о том, что внутреннюю структуру программного обеспечения можно и нужно постоянно улучшать.
7. Парное программирование - концепция, что члены команды должны работать вместе, а не отдельно. Они должны регулярно сотрудничать за одной клавиатурой, обмениваясь знаниями и поддерживая друг друга.
8. Коллективное владение - идея, что код принадлежит всей команде, а не одному человеку.
9. 40-часовая неделя - идея, что команды, которые постоянно работают сверхурочно, не эффективны.
10. Заказчик на месте - идея о том, что представитель бизнеса, отвечающий за требования, должен быть всегда доступен команде программистов.
11. Стандарты кодирования - идея о том, что команда должна придерживаться единого стиля кодирования, чтобы подчеркнуть чистоту и общение.
12. Адаптация к изменениям - только при частом получении обратной связи от пользователей и быстром реагировании на неё, мы можем создать действительно лучшее ПО для наших клиентов. Обратная связь не воспринимается как плохие новости, которые всегда сопровождаются поиском виновника. Вместо этого, мы приветствуем изменения и стремимся к их внедрению.

Работающий программный продукт важнее исчерпывающей документации

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