Extreme Programming. 
Управление жизненным циклом информационных систем

Основная особенность методологии экстремального программирования (<eXtreme Programming) состоит в ее эффективности в условиях неопределенных или нечетких требований. Популярность данного подхода увеличивалась, но мере роста числа разработчиков, недовольных традиционным подходом с множеством формальных требований и постоянно готовивших документацию, собиравших информацию о показателях проекта. Напротив, новая методология предлагала простой дизайн, переработку (рефакторинг) кода для контроля затрат, постоянное присутствие заказчика, разработку через тесты и другие аспекты, выгодно отличавшие ее от классических методологий.

Экстремальное программирование опирается на итеративность, взаимодействие внутри команды, взаимодействие с заказчиком, смелость и готовность рисковать. Подход основывается на 12 ключевых практиках.

• 1. Игра в планирование (Planning Game).
• 2. Тестирование (Testing). Практики разработки на основе тестов (TestDriven Development, TDD), т. е. написание тестов до реализации.
• 3. Повторное кодирование (Refactoring).
• 4. Коллективное владение кодом (Collective Code Ownership).
• 5. Простота разработки (Simple Design).
• 6. Парное программирование (Pair Programming).
• 7. Небольшие релизы (Small Release).
• 8. Постоянная интеграция (Continuous Integration).
• 9. Заказчик в команде разработки (On-site Customer).
• 10. Стандарты кодирования (Coding Standards).
• 11. Метафора (Metaphor).
• 12. 40-часовая рабочая неделя (40-hour Work Week).

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

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

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

Данный подход по-своему решает проблему контроля и координации работ. В отличие от Kanban и Scrum, в ХР производится подробное планирование работ и техника небольших релизов. Коммуникационные проблемы решаются за счет формализованных правил, где определяется уровень доступности команды. ХР также использует видеоконференции и различные коммуникационные программные продукты, при помощи которых можно получить доступ к рабочему столу. Время от времени проводятся реальные встречи участников команды.

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

При наличии ряда достоинств, ХР содержит важное ограничение. Применение данного подхода невозможно, если в команде разработчиков более пяти человек. Кроме того, практики менеджмента отсутствуют, а потому заказчик вынужден самостоятельно ставить рамки и контролировать качество готового продукта.