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

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

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

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

История [ править ]

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

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

Истоки [ править ]

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

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

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

Комплексная система компенсации Chrysler (C3) была запущена с целью определения наилучшего способа использования объектных технологий с использованием систем расчета заработной платы Chrysler в качестве объекта исследования, языка Smalltalk и уровня доступа к данным GemStone . Chrysler привез в Кент Бек , ^[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 г.), через пять лет после первого издания, Бек добавил больше ценностей и практик и провел различие между первичными и побочными практиками.

Концепция [ править ]

Цели [ править ]

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

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

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

Действия [ править ]

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

Кодирование [ править ]

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

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

Тестирование [ править ]

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

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

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

Прослушивание [ править ]

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

Проектирование [ править ]

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

Ценности [ править ]

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

Связь [ править ]

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

Простота [ править ]

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

Отзыв [ править ]

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

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

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

Смелость [ править ]

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

Уважение [ править ]

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

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

Правила [ править ]

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

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

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

Кодирование

• Заказчик всегда на связи
• Закодировать тестовый модуль первого
• Только одна пара интегрирует код за раз
• Оставьте оптимизацию до последнего
• Без сверхурочной работы

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

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

Принципы [ править ]

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

Отзыв [ править ]

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

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

Предполагая простоту [ править ]

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

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

Принятие изменений [ править ]

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

Практики [ править ]

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

Подробная обратная связь [ править ]

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

Непрерывный процесс [ править ]

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

Общее понимание [ править ]

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

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

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

Спорные аспекты [ править ]

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

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

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

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

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

Масштабируемость [ править ]

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

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

Делимость и ответы [ править ]

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

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

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

Критика [ править ]

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

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

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

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

См. Также [ править ]

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

Ссылки [ править ]

Дальнейшее чтение [ править ]

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

Внешние ссылки [ править ]

Викискладе есть медиафайлы, связанные с экстремальным программированием .

В Wikiquote есть цитаты, связанные с: Экстремальное программирование.

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