Экстремальное программирование

Петли планирования и обратной связи в экстремальном программировании

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

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

История

Кент Бек разработал экстремальное программирование во время работы над расчета заработной платы Chrysler Comprehensive Compensation System (C3) проектом . C3 Бек стал руководителем проекта в марте 1996 года. Он начал совершенствовать методологию разработки, используемую в проекте, и написал книгу по этой методологии ( Extreme Programming Assessmentd , опубликованную в октябре 1999 года). Chrysler отменил проект C3 в феврале 2000 года, спустя семь лет, когда Daimler-Benz . компанию приобрела Уорд Каннингем оказал еще одно большое влияние на XP.

Многие практики экстремального программирования существуют уже некоторое время; методология доводит « лучшие практики » до экстремального уровня. Например, «практика разработки с упором на тестирование, планирования и написания тестов перед каждым микроприращением» использовалась еще в проекте НАСА «Меркурий » в начале 1960-х годов. Чтобы сократить общее время разработки, некоторые формальные тестовые документы (например, для приемочного тестирования ) разрабатываются параллельно (или незадолго до) подготовки программного обеспечения к тестированию. Независимая группа тестирования НАСА может написать процедуры тестирования, основанные на формальных требованиях и логических ограничениях, прежде чем программисты напишут программное обеспечение и интегрируют его с оборудованием. XP доводит эту концепцию до крайнего уровня, создавая автоматические тесты (иногда внутри программных модулей), которые проверяют работу даже небольших участков программного кода, а не только тестируют более крупные функции.

Происхождение

На разработку программного обеспечения в 1990-е годы повлияли два основных фактора:

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

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

Комплексная система вознаграждения Chrysler (C3) была создана с целью определить лучший способ использования объектных технологий, используя системы расчета заработной платы Chrysler в качестве объекта исследования, Smalltalk в качестве языка и GemStone в качестве уровня доступа к данным . Крайслер пригласил Кента Бека , известный практик Smalltalk, занимавшийся настройкой производительности системы, но его роль расширилась, поскольку он заметил несколько проблем в процессе разработки. Он воспользовался этой возможностью, чтобы предложить и внедрить некоторые изменения в практику разработки — на основе своей работы со своим постоянным сотрудником Уордом Каннингемом . Бек описывает раннюю концепцию методов:

Когда меня впервые попросили возглавить команду, я попросил их сделать некоторые вещи, которые я считал разумными, например тестирование и обзоры. Во второй раз на кону было гораздо больше. Я подумал: «К черту торпеды, по крайней мере, из этой статьи выйдет хорошая статья», [и] попросил команду выкрутить все ручки до 10 в тех вещах, которые я считал важными, и исключить все остальное.

Бек пригласил Рона Джеффриса в проект, чтобы тот помог разработать и усовершенствовать эти методы. После этого Джеффрис выступал в качестве тренера, прививая эти практики привычкам команде C3.

Информация о принципах и практиках, лежащих в основе XP, распространялась по всему миру посредством дискуссий на оригинальной вики Каннингема , WikiWikiWeb . Различные участники обсудили и расширили эти идеи, в результате чего возникло несколько дополнительных методологий (см. Гибкая разработка программного обеспечения ). Также были объяснены концепции XP. , в течение нескольких лет, используя гипертекстовую карту системы на веб-сайте XP по адресу http://www.extremeprogramming.org c. 1999 .

Бек отредактировал серию книг по XP, начиная с книги « Объяснение экстремального программирования» (1999, ISBN   0-201-61641-6 ), распространяя свои идеи среди гораздо большей аудитории. Авторы этой серии рассмотрели различные аспекты XP и ее практики. В серию вошла книга с критикой этой практики.

Текущее состояние

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

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

Между тем, другие практики гибкой разработки не стоят на месте, и по состоянию на 2019 г. XP продолжает развиваться, усваивая больше уроков из практического опыта и используя другие практики. Во втором издании книги «Объяснение экстремального программирования» (ноябрь 2004 г.), через пять лет после первого издания, Бек добавил больше ценностей и практик и провел различие между основными и дополнительными практиками.

Концепция

Цели

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

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

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

Деятельность

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

Кодирование

Сторонники XP утверждают, что единственным по-настоящему важным продуктом процесса разработки системы является код – программные инструкции, которые может интерпретировать компьютер. Без кода нет работающего продукта.

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

Тестирование

Основная статья: Разработка через тестирование

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

• Модульные тесты определяют, работает ли данная функция должным образом. Программисты пишут столько автоматических тестов, сколько могут придумать, которые могут «сломать» код; если все тесты пройдены успешно, кодирование завершено. Каждый написанный фрагмент кода тестируется перед переходом к следующей функции.
• Приемочные испытания проверяют, что требования, как их понимают программисты, соответствуют фактическим требованиям заказчика.

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

Прослушивание

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

Проектирование

С точки зрения простоты, конечно, можно сказать, что для разработки системы не требуется ничего, кроме кодирования, тестирования и прослушивания. Если эти действия выполняются хорошо, результатом всегда должна быть работающая система. На практике это не сработает. Можно пройти долгий путь без проектирования, но в какой-то момент застрянешь. Система становится слишком сложной, и зависимости внутри системы перестают быть очевидными. Избежать этого можно, создав структуру проектирования, которая организует логику в системе. Хороший дизайн позволит избежать многих зависимостей внутри системы; это означает, что изменение одной части системы не повлияет на другие части системы.

Ценности

В 1999 году экстремальное программирование изначально признавало четыре ценности: общение, простота, обратная связь и смелость. была добавлена ​​новая ценность — уважение Во втором издании книги «Объяснение экстремального программирования» . Эти пять ценностей описаны ниже.

Общение

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

Простота

Экстремальное программирование поощряет начинать с самого простого решения. Дополнительные функции могут быть добавлены позже. Разница между этим подходом и более традиционными методами разработки систем заключается в том, что основное внимание уделяется проектированию и кодированию для нужд сегодняшнего дня, а не потребностей завтрашнего дня, следующей недели или следующего месяца. Иногда это называют подходом « Вам это не понадобится » (YAGNI). Сторонники XP признают тот недостаток, что иногда завтра это может повлечь за собой дополнительные усилия по изменению системы; они утверждают, что это более чем компенсируется преимуществом отсутствия инвестиций в возможные будущие требования, которые могут измениться до того, как станут актуальными. Кодирование и проектирование с учетом неопределенных будущих требований влечет за собой риск потратить ресурсы на что-то, что может не понадобиться, и, возможно, задержать важные функции. Что касается ценности «коммуникации», простота проектирования и кодирования должна улучшить качество связи. Простой дизайн с очень простым кодом может быть легко понятен большинству программистов в команде.

Обратная связь

В рамках экстремального программирования обратная связь относится к различным аспектам разработки системы:

• Обратная связь от системы: путем написания модульных тестов , или запуская периодические интеграционные тесты, программисты получают прямую обратную связь о состоянии системы после внесения изменений.
• Обратная связь от заказчика: Функциональные тесты (также известные как приемочные тесты ) пишутся заказчиком и тестировщиками. Они получат конкретную информацию о текущем состоянии своей системы. Этот обзор планируется один раз в две или три недели, чтобы заказчик мог легко управлять разработкой.
• Обратная связь от команды: когда клиенты выдвигают новые требования в процессе планирования, команда напрямую дает оценку времени, которое потребуется на их реализацию.

Обратная связь тесно связана с общением и простотой. О недостатках системы легко сообщить, написав модульный тест, который доказывает, что определенный фрагмент кода сломается. Прямая обратная связь от системы подсказывает программистам перекодировать эту часть. Клиент может периодически тестировать систему в соответствии с функциональными требованиями, известными как пользовательские истории . Цитируя Кента Бека : «Оптимизм — это профессиональный риск программирования. Обратная связь — это лечение».

Мужество

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

Уважение

Ценность уважения включает в себя уважение к другим, а также самоуважение. Программистам никогда не следует вносить изменения, которые нарушают компиляцию, приводят к сбою существующих модульных тестов или иным образом задерживают работу их коллег. Участники уважают свою работу, всегда стремятся к высокому качеству и ищут лучший дизайн для имеющегося решения посредством рефакторинга.

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

Правила

Первая версия правил для XP была опубликована в 1999 году Доном Уэллсом. на сайте XP. 29 правил даны в категориях планирования, управления, проектирования, кодирования и тестирования. Планирование, управление и проектирование явно призваны опровергнуть утверждения о том, что XP не поддерживает эти действия.

Еще одну версию правил XP предложил Кен Ауэр. в XP/Agile Universe 2003. Он считал, что XP определяется своими правилами, а не практиками (которые подвержены большему количеству вариаций и двусмысленности). Он определил две категории: «Правила взаимодействия», которые определяют среду, в которой может эффективно осуществляться разработка программного обеспечения, и «Правила игры», которые определяют поминутные действия и правила в рамках Правил взаимодействия.

Вот некоторые правила (неполные):

Кодирование

• Клиент всегда доступен
• напишите модульный тест Сначала
• Только одна пара интегрирует код одновременно
• Оставьте оптимизацию напоследок
• Никаких сверхурочных

Тестирование

• Весь код должен иметь модульные тесты
• Весь код должен пройти все модульные тесты, прежде чем его можно будет выпустить.
• При обнаружении ошибки тесты создаются до ее устранения (ошибка — это не ошибка в логике; это тест, который не был написан).
• Приемочные испытания проводятся часто, а результаты публикуются.

Принципы

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

Обратная связь

Экстремальное программирование считает обратную связь наиболее полезной, если она осуществляется часто и быстро. В нем подчеркивается, что минимальная задержка между действием и его обратной связью имеет решающее значение для обучения и внесения изменений. В отличие от традиционных методов разработки системы, контакт с заказчиком происходит более частыми итерациями. Заказчик имеет четкое представление о разрабатываемой системе, может давать отзывы и управлять разработкой по мере необходимости. Благодаря частой обратной связи с заказчиком ошибочное дизайнерское решение, принятое разработчиком, будет замечено и быстро исправлено, прежде чем разработчик потратит много времени на его реализацию.

Модульные тесты способствуют реализации принципа быстрой обратной связи. При написании кода запуск модульного теста обеспечивает прямую обратную связь о том, как система реагирует на внесенные изменения. Это включает в себя запуск не только модульных тестов, проверяющих код разработчика, но и выполнение всех модульных тестов для всего программного обеспечения с использованием автоматизированного процесса, который может быть инициирован одной командой. Таким образом, если изменения, внесенные разработчиком, вызывают сбой в какой-либо другой части системы, о которой разработчик мало или вообще ничего не знает, пакет автоматизированных комплексных тестов немедленно выявит сбой, предупредив разработчика о несовместимости его изменения с другие части системы, а также необходимость удаления или модификации их изменения. В соответствии с традиционными практиками разработки отсутствие автоматизированного комплексного набора модульных тестов означало, что такое изменение кода, которое разработчик считал безобидным, оставалось бы в силе и появлялось только во время интеграционного тестирования — или, что еще хуже, только в рабочей среде; и определить, какое изменение кода вызвало проблему среди всех изменений, внесенных всеми разработчиками за недели или даже месяцы, предшествовавшие интеграционному тестированию, было непростой задачей.

Предполагая простоту

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

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

Принятие перемен

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

Практики

Дополнительная информация: экстремальные практики программирования.

Экстремальное программирование состоит из 12 практик, сгруппированных в четыре области:

Мелкомасштабная обратная связь

• Парное программирование
• Планирование игры
• Разработка через тестирование
• Вся команда

Непрерывный процесс

• Непрерывная интеграция
• Рефакторинг или улучшение дизайна
• Небольшие релизы

Общее понимание

• Стандарты кодирования
• Коллективное владение кодом
• Простой дизайн
• Системная метафора

Благополучие программистов

• Устойчивый темп

Спорные аспекты

Практика XP широко обсуждалась. Сторонники экстремального программирования утверждают, что наличие клиента на месте запросить изменения неформально, процесс становится гибким и экономит формальные накладные расходы. Критики XP утверждают, что это может привести к дорогостоящим переделкам и объема проекта. выходу за рамки ранее согласованного или профинансированного

Советы по контролю изменений являются признаком того, что существуют потенциальные конфликты в целях проекта и ограничения между несколькими пользователями. Ускоренные методы XP в некоторой степени зависят от способности программистов принять единую точку зрения клиента, чтобы программист мог сосредоточиться на кодировании, а не на документировании компромиссных целей и ограничений. Это также применимо, когда в проекте задействовано несколько организаций-программистов, особенно организаций, которые конкурируют за доли в проектах.

Другие потенциально спорные аспекты экстремального программирования включают:

• Требования выражаются в виде автоматизированных приемочных испытаний, а не в виде документов спецификации.
• Требования определяются постепенно, а не пытаются получить их все заранее.
• Разработчикам программного обеспечения обычно приходится работать в парах.
• нет Впереди большого дизайна . Большая часть действий по проектированию происходит на лету и постепенно, начиная с «самой простой вещи, которая может работать» и добавляя сложность только тогда, когда этого требуют неудачные тесты. Критики характеризуют это как « отладку системы до внешнего вида» и опасаются, что это приведет к увеличению усилий по перепроектированию, а не только к перепроектированию при изменении требований.
• представитель заказчика К проекту прикрепляется . Эта роль может стать единственной точкой отказа проекта, а некоторые люди считают ее источником стресса. Кроме того, существует опасность микроуправления со стороны нетехнического представителя, пытающегося диктовать использование технических функций и архитектуры программного обеспечения.

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

Масштабируемость

Thoughtworks добилась значительных успехов в распределенных проектах XP с участием до шестидесяти человек.

В 2004 году индустриальное экстремальное программирование (IXP). был представлен как развитие XP. Он предназначен для того, чтобы дать возможность работать в больших и распределенных командах. Сейчас у него 23 практики и гибкие ценности.

Делимость и ответы

В 2003 году Мэтт Стивенс и Дуг Розенберг опубликовали книгу «Extreme Programming Refactored: The Case Against XP» , в которой ставилась под сомнение ценность процесса XP и предлагались способы его улучшения. Это вызвало длительные дебаты в статьях, группах новостей в Интернете и чатах на веб-сайтах. Основной аргумент книги заключается в том, что практики XP взаимозависимы, но лишь немногие практические организации готовы/способны перенять все практики; поэтому весь процесс терпит неудачу. В книге также содержится и другая критика, а также негативное сходство модели «коллективной собственности» XP с социализмом.

Некоторые аспекты XP изменились со времени публикации Extreme Programming Refactored ; в частности, XP теперь позволяет вносить изменения в практику при условии, что необходимые цели по-прежнему достигаются. XP также использует все более общие термины для обозначения процессов. Некоторые утверждают, что эти изменения сводят на нет предыдущую критику; другие утверждают, что это просто размывает процесс.

Другие авторы пытались согласовать XP со старыми методологиями, чтобы сформировать единую методологию. Некоторые из этих XP пытались заменить, например методологию водопада ; пример: Жизненные циклы проекта: водопад, быстрая разработка приложений (RAD) и все такое. JPMorgan Chase & Co. попыталась объединить XP с методами компьютерного программирования интеграции модели зрелости возможностей (CMMI) и шестью сигмами . Они обнаружили, что три системы хорошо подкрепляют друг друга, приводя к лучшему развитию, и не противоречат друг другу.

Критика

Первоначальный ажиотаж и противоречивые принципы экстремального программирования, такие как парное программирование и непрерывное проектирование , вызвали особую критику, исходящую, например, от МакБрина, Бём и Тернер, Мэтт Стивенс и Дуг Розенберг. Однако многие критические замечания, по мнению практиков Agile, являются неправильным пониманием гибкой разработки.

Мэтта Стивенса и Дуга Розенберга В частности, экстремальное программирование было рассмотрено и подвергнуто критике в книге «Рефакторинг экстремального программирования» .

См. также

• Гибкая разработка программного обеспечения
• Постоянное устаревание
• Экстремальное производство
• Экстремальное управление проектами
• Экстремальные практики программирования
• Кайдзен
• Список философий разработки программного обеспечения
• Парное программирование
• Скрам (разработка)
• Мастерство программного обеспечения
• Стенд-ап встреча
• Таймбоксинг

Дальнейшее чтение

• Кен Ауэр и Рой Миллер. Прикладное экстремальное программирование: игра на победу , Аддисон-Уэсли.
• Кен Ауэр; Рон Джеффрис ; Джефф Канна; Глен Б. Аллеман; Лиза Криспин; Джанет Грегори (2002). «Вымерли ли тестировщики? Как тестировщики могут внести свой вклад в команды XP?». Экстремальное программирование и гибкие методы — XP/Agile Universe 2002 . Конспекты лекций по информатике. Том. 2418. Шпрингер-Верлаг. п. 287. дои : 10.1007/3-540-45672-4_50 . ISBN  978-3-540-44024-6 .
• Кент Бек : Объяснение экстремального программирования: примите перемены , Аддисон-Уэсли. Первое издание, 1999 г. Второе издание, с Синтией Андрес, 2004 г.
• Кент Бек и Мартин Фаулер : Планирование экстремального программирования , Аддисон-Уэсли.
• Алистер Кокберн : Гибкая разработка программного обеспечения , Аддисон-Уэсли.
• Мартин Фаулер : Рефакторинг: улучшение конструкции существующего кода . Совместно с Кентом Беком, Джоном Брантом, Уильямом Опдайком и Доном Робертсом (1999). Аддисон-Уэсли.
• Харви Херела (2005). Практический пример: Комплексная система вознаграждений Chrysler . Лаборатория Галена, Калифорнийский университет в Ирвайне.
• Джим Хайсмит . Гибкие экосистемы разработки программного обеспечения , Аддисон-Уэсли.
• Рон Джеффрис , Энн Андерсон и Чет Хендриксон (2000), Установленное экстремальное программирование , Аддисон-Уэсли.
• Ларман, К. ; Базили, В.Р. (июнь 2003 г.). «Итеративные и постепенные разработки. Краткая история» (PDF) . Компьютер . 36 (6): 47–56. дои : 10.1109/MC.2003.1204375 .
• Мэтт Стивенс и Дуг Розенберг (2003). Рефакторинг экстремального программирования: аргументы против XP , Apress.
• Вальднер, Дж.Б. (2008). «Нанокомпьютеры и роевой интеллект». В: ИСТЕ, 225–256.

Внешние ссылки

• Нежное знакомство
• Промышленное экстремальное программирование
• Проблемы и решения внедрения XP
• Использование гибкого процесса разработки программного обеспечения при оффшорной разработке — опыт ThoughtWorks по внедрению XP в крупных распределенных проектах