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

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

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

В общем, черт его знает, как правильно командно писать большие проекты. Особенно когда народу мало, ТЗ военная тайна заказчика, и в общей сложности члены команды зеленые и их постоянно нужно учить и контролировать. У XP много достоинств, многие из них я использую, однако в области кодирования его методология никак под наши бух учетные задачи не лезет, если бы я 3-звенные приложения строил, она может быть и была бы полезна. Я видел пример XP программирования моими двумя друзьями, которые пытались реализовать довольно сложный проект с использованием 3-звенки, следуя всем рекомендациям XP. Не скажу, что опыт у них был удачный или не удачный, однако проблем возникало не меньше, кое где я бы сказал больше -
тот же пункт XP о реализации наиболее простых решений и парном программировании у них привел к тому, что вроде и проект писался последовательно и ТЗ было более менее определено, однако на середине пути они столкнулись с изменениями требований ТЗ заказчиком и потратили довольно много времени на изменения модели системы, рефакторинг кода и отладку системы. В моем например случае изменение ТЗ обычно не грозит пишущемуся проекту большими неприятностями, так как при его проектировке я изначально изучаю историю динамики изменения его ТЗ и закладываюсь на наиболее критичные моменты сразу в серверной и клиентских частях.

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