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

Если говорить об основах XP постулат о включении представителя заказчика в группу обойти невозможно. В противном случае отцы XP так и говорят: ждите проблем.Или это уже не чистый XP.
Возможно, из
softwarerПоверьте, когда у заказчика есть человек, который может и хочет побыть таким вот толковым представителем, это огромное счастье для разработчика. Вот только встречаются такие - очень редко. Я, скажем, за десять лет наткнулся на такого только однажды. В остальных случаях - либо "нудный сбор требований", либо тот же самый нудный сбор, дополненный "испорченным телефоном" в лице идиота-представителя.
следует
guest_20040621
Guest > Ну чтож так, сразу. А вдруг? :-)

Чудес не бывает. XP и качественный продукт - понятия не совместимые.

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

По существу вопроса: автору топика предлагаю осознать, что его идея - это, например, воплощенный .NET или Oracle в целом.
Сбор требований и "минимум-оптимум" кодирования превращают платформы в продукт, являющийся составной частью РЕШЕНИЯ, а вот оно, как раз и продается.
Сбор требований с попыткой навести статистику и поправку на ветер порождает отраслевое решение (или специализированное по другому признаку) или снова платформу. И опять от требований никуда не уйти.

В ответ на вопрос "что нам стоит" я отвечаю так: отсутствие четкого представления о конечном результате. Начинать проект с поиска ресурсов вместо осознания целей и ограничений не очень разумно.
По этому предлагаю привести коротенький обзор предметной области, под которую планируется система, концепцию (например vision document из RUP) и пару сценариев работы с системой, которые Вы планируете реализовать в качестве задачи-минимум. Глядишь, народ и потянется...