Jump to content

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

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

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

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

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

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

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

Происхождение [ править ]

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

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

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

Когда меня впервые попросили возглавить команду, я попросил их сделать некоторые вещи, которые я считал разумными, например тестирование и обзоры. Во второй раз на кону было гораздо больше. Я подумал: «К черту торпеды, по крайней мере, из этой статьи выйдет хорошая статья», [и] попросил команду выкрутить все ручки до 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 утверждают, что единственным по-настоящему важным продуктом процесса разработки системы является код – программные инструкции, которые может интерпретировать компьютер. Без кода нет работающего продукта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обратная связь [ править ]

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

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

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

Мужество [ править ]

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

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

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

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

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

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

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

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

Кодирование

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

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

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

Обратная связь [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. ^ «Семинар по человекоцентрированным технологиям 2006 г.», 2006 г., PDF, Семинар по человекоцентрированным технологиям 2006 г.
  2. ^ Jump up to: Перейти обратно: а б UPenn-Lectures-design-patterns «Шаблоны проектирования и рефакторинг», Пенсильванский университет, 2003 г. Архивировано 2 августа 2010 г. в Wayback Machine .
  3. ^ Jump up to: Перейти обратно: а б USFCA-edu-601-lection Экстремальное программирование .
  4. ^ «Манифест гибкой разработки программного обеспечения» . Agilemanifesto.org. 2001 . Проверено 26 марта 2019 г.
  5. ^ Jump up to: Перейти обратно: а б с д и ж г час я дж к л м Computerworld-appdev-92 «Экстремальное программирование», Computerworld (онлайн), декабрь 2001 г.
  6. ^ Jump up to: Перейти обратно: а б с Розенберг, Дуг; Стивенс, Мэтт (2003). Рефакторинг экстремального программирования: аргументы против XP . Апресс. ISBN  978-1-59059-096-6 .
  7. ^ Ларман и Базили 2003 .
  8. ^ Интервью с Кентом Беком и Мартином Фаулером . 23 марта 2001 г. {{cite book}}: |work= игнорируется ( помогите )
  9. ^ Лиза Криспин; Тип Хаус (2003). Тестирование экстремального программирования . ISBN  9780321113559 .
  10. ^ «Каждый программист» Клера Тристрама. Обзор технологий , ноябрь 2003 г. с. 39.
  11. ^ Бек, К. (1999). Объяснение экстремального программирования: примите изменения . Аддисон-Уэсли. ISBN  978-0-321-27865-4 .
  12. ^ «Правила экстремального программирования» . сайт Extremeprogramming.org .
  13. Кен Ауэр. Архивировано 20 сентября 2008 г., в Wayback Machine.
  14. ^ Джон Кэрролл; Дэвид Моррис (29 июля 2015 г.). Гибкое управление проектами: простые шаги, 2-е издание . В простых шагах. п. 162. ИСБН  978-1-84078-703-0 .
  15. ^ Консорциум резчиков. «Промышленный XP: заставить XP работать в крупных организациях - Консорциум Cutter» . Cutter.com .
  16. ^ Экстремальное программирование (XP) Six Sigma CMMI .
  17. ^ МакБрин, П. (2003). Вопросы экстремального программирования . Бостон, Массачусетс: Аддисон-Уэсли. ISBN  978-0-201-84457-3 .
  18. ^ Бём, Б. ; Р. Тернер (2004). Баланс между ловкостью и дисциплиной: руководство для растерянных . Бостон, Массачусетс: Аддисон-Уэсли. ISBN  978-0-321-18612-6 .
  19. ^ Стивенс, Мэтт ; Дуг Розенберг (2004). Ирония экстремального программирования . МА: Журнал доктора Доббса.
  20. ^ sdmagazine. Архивировано 16 марта 2006 г. в Wayback Machine.

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

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

Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: eba6dd6240d552afc3683ba5b8b75a3f__1715701920
URL1:https://arc.ask3.ru/arc/aa/eb/3f/eba6dd6240d552afc3683ba5b8b75a3f.html
Заголовок, (Title) документа по адресу, URL1:
Extreme programming - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)