Здравствуйте, Gaperton, Вы писали:
G>С логикой что-то не так? 
Теперь понятно.
Практически, спорить не буду, потому что не имею (кто знает, может тоько пока) опыта работы в таких огромных командах.
Теоретически... не согласен, потому что читаю труды людей, которых уважаю, которые вроде бы имеют такой опыт и говорят противоположные вам вещи.
G>При том, что работать большими командами все-таки необходимо, нравится это кому-то, или нет, а подход ХР противоречит основным принципам работы больших команд — он практически гарантирует провал на большой команде.
Аналогично: не знаю, но сомневаюсь.
G>Вопрос — чему равно-равно ХР, и чем оно отличается от "обычной разработки"? Прототипирование на стадии "эскизного проекта" (вы писали там выше, что оно с прототипированием связано) прописано еще в древних ГОСТ-ах аж семидесятых годов. Практика review разработана Фаганом тоже в 70-х. Где
А здесь не согласен: вы пропустили основной акцент, уцепившись за частность в стиле "в XP нет ничего принципиально нового". Почему вы пропустили главное: прототипирование в XP/Scrum не догма в виде автономно летающего в вакууме сферического коня, а именно фактор повышения эффективности планирования по сравнению с водопадом? Ведь самое важное в любом agile: иной, нежели стандартный, подход к планированию.
G>А что, XP разве не предполагает продвижение к результату через чередующиеся сессии кодирования и рефакторинга (т.е. через серию причесанных прототипов)? Не так? Поправьте меня 
И вы спрашиваете меня, почем я решил, что XP == code and fix? А что — разве в ХР изобрели какой-то новый способ программировать? Без традиционных стадий дизайна, но при этом и без кодирования с отладкой? Who the fuckin guy XP is тогда?
Разницу между XP и code and fix Фаулер описывает в статье, ссылку на которую давал выше. В его аргументации нашел параллели с обстоятельствами своей работы, потому считаю его позицию отчасти своей, но, честно говоря, начинаю чувствовать себя попкой-дураком, приводя краткое содержание его мыслей; думаю, лучше прочитать первоисточник.
