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

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

Экстремальное программирование (XP) это методология разработки программного обеспечения который предназначен для улучшения качество программного обеспечения и отзывчивость к изменяющимся требованиям клиентов. Как вид гибкая разработка программного обеспечения,^[1][2][3] он поддерживает частые «выпуски» в короткие циклы разработки, что предназначено для повышения производительности и введения контрольных точек, в которых могут быть приняты новые требования клиентов.

Другие элементы экстремального программирования включают: программирование в парах или делать обширные обзор кода, модульное тестирование всего кода, не программировать функции, пока они действительно не понадобятся, плоская структура управления, простота и ясность кода, ожидание изменений в требованиях клиентов по прошествии времени и более глубокое понимание проблемы, а также частое общение с заказчиком и программистами.^[2][3][4] Эта методология получила свое название от идеи, что полезные элементы традиционных практик разработки программного обеспечения доводятся до «экстремального» уровня. В качестве примера, обзоры кода считаются полезной практикой; доведенный до крайности, код можно просмотреть непрерывно, т.е. практика парное программирование.

История

Кент Бек разработал экстремальное программирование во время работы над Комплексная система компенсации Chrysler (C3) заработная плата проект.^[5] Бек стал C3 руководитель проекта в марте 1996 года. Он начал совершенствовать методологию разработки, использованную в проекте, и написал книгу по методологии (Объяснение экстремального программирования, опубликовано в октябре 1999 г.).^[5]Chrysler отменил проект C3 в феврале 2000 г., через семь лет, когда Daimler-Benz приобрел компанию.^[6]

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

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

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

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

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

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

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

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

Информация о принципах и практиках XP распространена по всему миру посредством обсуждения оригинала. вики, Каннингема WikiWikiWeb. Различные участники обсудили и расширили идеи, и в результате были получены некоторые дополнительные методологии (см. гибкая разработка программного обеспечения ). Также были объяснены концепции XP.^{[кем? ]}, в течение нескольких лет, используя гипертекст карта системы на сайте XP по адресу http://www.extremeprogramming.org около 1999 года.

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

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

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

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

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

Теория устойчивой разработки программного обеспечения объясняет, почему команды экстремального программирования могут процветать, несмотря на сбои в работе команды.^{[9][неосновной источник необходим ]}

Концепция

Цели

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

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

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

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

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

Кодирование

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

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

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

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

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

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

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

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

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

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

Значения

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

Коммуникация

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

Простота

Экстремальное программирование побуждает начинать с самого простого решения. Дополнительные функции могут быть добавлены позже. Разница между этим подходом и более традиционными методами разработки систем заключается в сосредоточении внимания на проектировании и кодировании для нужд сегодняшнего дня, а не для нужд завтрашнего дня, следующей недели или следующего месяца. Иногда это называют "Тебе это не понадобится "(ЯГНИ) подход.^[11] Сторонники XP признают тот недостаток, что иногда это может повлечь за собой дополнительные усилия по изменению системы; они утверждают, что это более чем компенсируется преимуществом отказа от инвестирования в возможные будущие требования, которые могут измениться до того, как станут актуальными. Кодирование и проектирование с учетом неопределенных будущих требований подразумевает риск потратить ресурсы на то, что может оказаться ненужным, и, возможно, откладывать важные функции. Что касается ценности «коммуникации», простота дизайна и кодирования должна улучшить качество коммуникации. Простая конструкция с очень простым кодом может быть легко понятна большинству программистов в команде.

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

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

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

Обратная связь тесно связана с общением и простотой. Об ошибках в системе легко сообщить, написав модульный тест, который доказывает, что определенный фрагмент кода сломается. Прямая обратная связь от системы говорит программистам перекодировать эту часть. Заказчик может периодически тестировать систему в соответствии с функциональными требованиями, известными как пользовательские истории.^[5] Цитировать Кент Бек, «Оптимизм - это профессиональный риск программирования. Обратная связь - это лечение».^[12]

Храбрость

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

Уважать

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

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

Правила

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

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

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

Кодирование

• Заказчик всегда на связи
• Кодировать модульный тест первый
• Только одна пара интегрирует код за раз
• Покинуть оптимизация до последнего
• Нет через некоторое время

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

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

Принципы

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

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

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

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

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

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

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

Принятие изменений

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

Практики

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

Тонкая обратная связь

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

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

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

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

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

Программист благосостояние

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

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

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

Доски управления изменениями являются признаком того, что есть потенциальные конфликты в целях проекта и ограничения между несколькими пользователями. Ускоренные методы XP в некоторой степени зависят от того, могут ли программисты принять единую точку зрения клиента, поэтому программист может сосредоточиться на кодировании, а не на документации компромиссных целей и ограничений.^[15] Это также применимо, когда задействовано несколько организаций, занимающихся программированием, особенно организаций, которые соревнуются за долю в проектах.^{[нужна цитата ]}

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

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

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

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

ThoughtWorks заявила о разумном успехе в распределенных проектах XP с участием до шестидесяти человек.^{[нужна цитата ]}

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

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

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

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

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

Критика

Первоначальный шум экстремального программирования и противоречивые принципы, такие как парное программирование и непрерывный дизайн, вызвали особую критику, например, со стороны Макбрина^[18] и Бем и Тернер,^[19] Мэтт Стивенс и Дуг Розенберг.^[20] Однако практикующие Agile считают, что многие критические замечания являются неправильным пониманием гибкой разработки.^[21]

В частности, экстремальное программирование было рассмотрено и критиковано Мэттом Стивенсом и Дугом Розенбергом. Реорганизация экстремального программирования.^[6]

Критика включает:

• методология настолько эффективна, насколько эффективны вовлеченные люди, Agile не решает эту проблему.^{[нужна цитата ]}
• часто используется как средство отвода денег от клиентов из-за отсутствия определения конечного продукта^{[нужна цитата ]}
• отсутствие структуры и необходимой документации^{[нужна цитата ]}
• работает только со старшими разработчиками^{[нужна цитата ]}
• включает в себя недостаточный дизайн программного обеспечения^{[нужна цитата ]}
• требует частых встреч с огромными расходами для клиентов^{[нужна цитата ]}
• требует слишком больших культурных изменений, чтобы принять^{[нужна цитата ]}
• может привести к усложнению договорных переговоров^{[нужна цитата ]}
• может быть очень неэффективным; если требования к одной области кода меняются в результате различных итераций, то одно и то же программирование может потребоваться выполнить несколько раз. В то время как, если план должен был быть реализован, ожидается, что одна область кода будет написана один раз.^{[нужна цитата ]}
• невозможно разработать реалистичную оценку трудозатрат, необходимых для предоставления расценок, потому что в начале проекта никто не знает всего объема / требований^{[нужна цитата ]}
• может увеличить риск ползучесть прицела из-за отсутствия подробной документации с требованиями^{[нужна цитата ]}
• Agile ориентирована на особенности; нефункциональные атрибуты качества трудно представить как пользовательские истории.^{[нужна цитата ]}

Смотрите также

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

Рекомендации

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

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

внешняя ссылка

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