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

Грубо говоря, представьте себе, что проектируя самолет, Вы сажаете несколько групп: одна "от балды" проектирует фюзеляж, другая - крылья, третья - начинку, а потом соединяете все вместе, решая проблемы наподобие "два ряда кресел из спроектированного пассажирского торчат из спроектированного фюзеляжа на три метра вбок". При этом, если выяснится, что требования к скорости (обусловившей узкий фюзеляж) и к пассажировместимости (обусловившей широкий салон) одновременно не реализуемы, то выяснится это в последний момент, когда все уже "сделано".

student2007ВАРИАНТ 1
1 аналитик/архитектор - ни чего не пишет.
2-е пишут по спецификациям аналитика

ВАРИАНТ 2
1 аналитик/архитектор/главный программист - делает 60% работы
2-е помогают в написании вспомогательных модулей
Это по сути один вариант. Выбор деталей зависит от того, что за люди. Если команда до того вместе не работала, я бы посоветовал так:

1 аналитик/архитектор - проектирует, ставит задачи (спецификации или как - отдельный вопрос), делает review кода остальных, при необходимости реализует ключевые фрагменты (особо сложные итп). По мере того, как команда срабатывается, необходимость в review уменьшается, соответственно он может уделять больше времени другим вопросам, в том числе при желании - кодировать.

2-е - оппонируют идеям архитектора, выдвигают советы, реализуют порученные им задачи (возможно, в том числе, проектируют решения относительно мелких задач - на усмотрение архитектора).

student2007Получается мелкие/средние проги проще поручить ОДНОМУ программисту, чем команде?
Именно так. С одной поправкой: когда программа более-менее готова, стоит познакомить с ней одного-двух других программистов (например, поручая им сопровождение и мелкие доработки под надзором).