коллективная работа над проектом

[Usnul]

для этого нужен програмный архитектор
эта задача обычно выпадает лидеру проекта, когда команда довольно маленькая, твоя задача оценить обьем работы и структуризировать его по времени разработки, тоесть таким образом чтобы не возникала ситуация "я не могу делать мою часть ибо для этого мне нужно чтобы было сделано то и то". Это целая наука, вообще, кроме этого нужно держать в голове обьемы задач, чтобы они были пропорциональны скорости разработчиков которым они отведены. Очень не рекомендую давать задание кому-то без уверенности что человек способен его выполнить, особенно если оно является одним из критических элементов разработки, тоесть таким на котором будет основоваться другое(ие) задание(я).

Очень важна мотивация, порой лучше дать разработчику больше свободы, это положительно действует на молодых (не опытных) разработчиков в плане мотивации.

Я говорил про знания раньше, парой проще разделить задание на 2 части:
1) обучение разработчика для выполнения задание
2) само задание

такие компромисы отнимают намного меньше драгоценного времени у ключевых фигур и позволяют менее опытным разработчикам выполнить задание. Скажем Вася ничего не знает об озвучке игр, Коля, который игры делает уже не первый год и очень занят написанием ядра, тратит 15-20 минут на обьяснение процесса Васе что позволяет последнему выполнить задание, если бы Коля делал задание сам, у него ушло бы на это 3-5 часов (положим игра большая ).

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

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

3)Тесно связанные зададачи.. такие ситуации в принципе довольно редки, в таком случае я бы рекомендовал создание групп для более тесного контакта между разработчиками, это максимально ускоряет разработку такого вида задач.

я немного сонный, если что лучше в аську стукни.