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