pemp,

спасибо за ответ. очень интересно было узнать мнение человека реально работающего в хр команде. А то был наслышан о хр только от теоретиков и "продавцов" агила.
И все же остаюсь при своем мнении - агил и хр в частности выигрывает у классики в редких случаях (полугодовой проект, небольшая сферическая команда, заказчику нечем больше заняться и он просто живет у вас в оффисе) или в случае "клинических заболеваний" управленческого звена.
В принципе ваша тема логична, но я все же главное, к чему стремится любая методология: эффективная быстрая и качественная разработка при минимальных затратах - в ваших топ3 я не увидел, в смысле хр > чем классика. За улучшение одного приходится платить другим. Например с ваших слов: "парное программирование. - ошибок меньше код эффективнее" - ошибок меньше - отчасти согласен. Почему отчасти - речь идет о моментальных ошибках в рамках класса, модуля например, но при состыковке с интерфейсом другой пары, например, ошибки и недочеты возникнут также как при классике и "одиночном" программировании. Код эффективнее - отчасти согласен, но код пишется в два раза медленнее, если не в три (т.к. еще же надо между собой перетереть и прийти к общей концепции чутьли не к каждому методу). В классике та же эффективность и качество достигается другими способами за тот же промежуток времени в конечном итоге.
С ваших слов "..кроме того народ работает вместо того чтобы придти попить кофе, почитать башорг новости, пописать в ПТ, пообедать.." это да, в реале есть такое - но речь идет о хорошей команде, известных сроках, заинтересованности людей. Аналогично можно предположить что в хр обсуждения в паре могут самопроизвольно перекинутся на темы машин, женшин и политики, в понедельник о том как побухали и поклубились, в итоге полдня прошло даром ;-)

"1) изменение требований. с ХР на это почти по-барабану" - ну это тоже спорный вопрос. В принципе рефакторинг он и в африке рефакторинг. Большой он под конец проекта или частый малый - роли не играет с точки зрения метода разработки. В хр можете делать рефакторинг хоть каждый день, но если у заказчика возникает кризис в кармане или в голове, то откат проекта происходит одинаково далеко и одим только "побрейнстормили чуток переделываем" дело не оканчивается. Также приходится тоннами выкидывать эффективный качественный хр код в ящик для потомков и переписывать снова. Когда я работал в скрумкоманде то увидел реальный недостаток "каждо-спринового" изменения требований: при размывчатой конечой цели (даже простого модуля) переписывание кода реально притормаживает процесс. Бывало, что для заказчика незначительные с виду измения требований приводили к большому рефакторингу. Вобщем за гибкость и рефакторинги надо платить так или иначе.

П.С: почему парами а не тройками? ведь будет еще более продуманнее, меньше багов и все такое..