C>У нас наверно разное понимание терминов разработка и простой кодинг.
Скорее разное понимание звездности.

C>Простой кодинг может быть нужен только в случае, если кто-то уже составил подробные требования, архитектуру и разжевал все возможные сложности "простому кодеру". Т.е. опять таки нужен или ведущий разработчик\тим лид\архитектор (давайте не будем говорить о звёздах — т.к. это настоящая звезда — очень редкое явление) уровнем выше остальной команды.
Хм... А если их не будет, то и разговора нет. Я не говорю, что старших не должно быть, я говорю про случаи присутствия "звезд" на проекте. Звезда — это понятие очень сложное.

C>Единственная ситуация где предложенный вами подход возможен — это самая примитивная версия аутсорса, когда здесь набираются только junior/middle разработчики и тестеры. Т.е. это у заказчика болит голова о возможном уходе специалистов.
Странный вывод. У Заказчика в любом случае болеть голова не должна. А эта схема нормально работает там, где есть действительно четкое разделение между ролями. Если разработчик и разрабатывает архитектуру и реализовывает ее и пишет тестовые сценарии и прочее и прочее, тогда действительно нужны звезды. Хотя я не особенно много видел в том числе и звезд, которым бы нравилось все это делать. Обычно все-таки разработчик напирает на то, что он должен разрабатывать, а все остальное пусть делают другие.

C>А любая, сколь угодно большая толпа из junior/middle программистов никогда не сделает хорошего продукта даже по лучшему в мире процессу.
Хм. Не согласен. Если собрать звезд в такой проект тоже лучше не станет. Нужен баланс. В тех частях проекта, где нужен быстрый результат — пожалуйста звезду (но опять-же надо смотреть какую...), там где уже все четко прописано и продумано — звезда будет только мешать.

C>Может надо признать, что упрощение жизни для менеджера (ведь когда можно любого работника заменить другим за неделю — это гораздо проще чем наладить работу команды, в которой есть ценные специалисты) — это не самоцель?
А что тут признавать — это и так все прозаично. Мы говорим не о том, что сложнее или не сложнее а о реальных рисках. И Ваше право мириться с ними или предупреждать.

C>Настоящая цель — это быстрая разработка конкурентноспособного ПО. Помоему, эта цель часто теряется за многочисленными ложными целями (а на самом деле — всего лишь средствами) вроде: формализованных процессов, управлениями рисками, повышением значения LoC, и прочее и прочее.
У бизнеса цель одна — заработать денег. И чем меньше рисков при большей отдаче, тем лучше. А вот все остальное, как раз и подчинено это основной цели.