В конечном счете, экстремальное программирование - это набор практик и методологий, которые ведут к повышению ценности бизнеса. Лучшая иллюстрация этого, которую я нашел, взята с http://c2.com/cgi/wiki?ExtremeProgrammingEnablingChart
Все в синем является частью ядра XP.
Есть его части, которые находятся за его пределами, которые помогают включить вещи в синей области и являются частью XP в целом, но не критичны для этого. Обратите внимание, что я лично не практикующий XP, и я прочитал довольно много критики людей "почти" после XP, которые, как говорили разные люди, не являются XP. Давайте немного отложим этот аспект догмы XP и посмотрим, что у нас есть.
Поймите, что одним из первых и для большинства вещей является обязательство клиента к процессу. Ключевым компонентом XP является участие клиентов. Это проявляется во многих местах, таких как планирование выпуска, небольшие выпуски, оценка клиента за пределами сайта. Это вещи, на которые ваши клиенты должны будут подписаться, если вы собираетесь добиться успеха в XP в качестве индивидуального разработчика. Если вместо этого они попросят проект, а затем период разработки, затем тестирование и тому подобное, у вас не будет обязательства идти дальше.
ХР не означает никакого планирования. В этом есть несколько моментов, в которых планирование является его частью - расстановка приоритетов, оценка пользовательских историй, планирование итераций и определение задач. Несмотря на то, что вы являетесь одним из разработчиков, это то, что вам нужно для работы с вашим клиентом.
Точки, такие как коллективное владение кодом и парное программирование, - это вещи, которые затрагивают более одного. Выбор таких вещей, как стандарты кодирования, намного проще, но это не значит, что вам не нужно им следовать. Коллективное владение кодом остается в силе - просто правообладатель также является следующим разработчиком - не пишите код, предназначенный для вас и для вас одного. Обратите внимание, что это в некоторой степени противоречит тому, что «код раскрывает все намерения», что обеспечивается парным программированием - у вас нет этого человека, который бы проверял, что вы пишете обслуживаемый код, поэтому документирование кода также важно.
Помимо этих предостережений, многие принципы проектирования XP все еще применяются. Такие вещи, как тестирование первого дизайна, непрерывная интеграция, встречи с заказчиком, рефакторинг, YAGNI, шип решения - эти вызовы могут быть выполнены в одиночку.
Поймите, что соло XP требует столько же или больше дисциплины, как и обычный XP. XP часто считают методологией высокой дисциплины, поскольку она требует от людей неукоснительного соблюдения лучших практик, которые она пытается воплотить. Когда у вас нет тренера или других людей, которые бы поддерживали эту дисциплину, это может превратиться в мешанину практик, которые имеют некоторое сходство с XP.
Связанное чтение:
Я хотел бы получить цитату из первой ссылки c2:
Известный специалист по языку Perl и безумный ученый Дамиан Конуэй считает, что экстремальное программирование на самом деле неправильно. Поскольку он воплощает в себе многие из хороших методов программирования, которым программисты учат, но почти наверняка их игнорируют, он считает, что это действительно нужно было назвать ультраконсервативным программированием.