Осталась следующая критика:
1. Идея «нахождения представителя заказчика в одной комнате с программистами» по моему мнению, мягко говоря, является фантастическим пожеланием. Никто не спорит, что коммуникация с заказчиком жизненно необходима. Но решение проблемы скорее находится, во-первых, в сфере разработки стандартных форм документов по взаимодействию (ТЗ, ТП). Во-вторых, в более быстрых итерациях (нужно помочь заказчику сформулировать и откорректировать своё видение системы)
2. Отрицание этапа «большого предварительного проектирования» допустимо только при разработке тривиальных систем (несложные сайты с уклоном в сторону дизайна, а не программирования, простейшие однопользовательские программы с минимумом бизнес-логики и т.п.). Цитируя одного из авторов: «Я рассматриваю здесь решения, полезные при разработке сложных систем. Если приложение простое, зачем тратить на него своё время?». В сложном и интересном проекте, с «богатой» предметной областью было бы преступной халатностью не сформировать в самом начале каркас системы, основные принципы его функционирования. Конечно, «настоящие ХР-шники» стоически воспримут информацию в середине проекта о том, что обнаружился прецедент, заставляющий переделать большую часть кода (или ещё хуже выбросить его). Но я считаю это совершенно недопустимым.
3. Десятки userstory (бумажки с несколькими предложениями, характеризующими прецедент пользователя), оставшиеся после завершения проекта, не могут служить в качестве надежной документации. Получается, что ХР нацелена на быструю разработку ПО, но не на его сопровождение. Приведу цитату из книги [4] по поводу неудачи проекта 3C, выполненного посредством ХР (расчет зарплаты для Chrysler – могу подтвердить, что зарплата при своей внешней простоте одна из самых трудных областей бухгалтерии, в которой «утонула» не одна команда программистов). «Когда ушло достаточно много сотрудников, незаписанные сведения о проекте и групповая память были утрачены». Я думаю, что апологеты ХР переусердствовали с минимизацией документации. Что для студентов может выглядеть привлекательным, серьезных разработчиков должно насторожить.
Должен поделиться собственным ощущением от «работы в стиле ХР». В отличие от RUP (или любой другой методики с фиксированием результатов этапов, посредством тех. задания, тех. проекта и т.п.) ХР дает ощущение неуверенности и анархии