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

у кого есть опыт коллективной работы над флэш проектами?

С SVN я разобрался - тут всё четко и понятно.
Гораздо больше меня волнует вопрос планирования и постановки задач.
1. Как планировать архитектуру проекта, в каком виде оформлять проект?
2. Как разделять обязанности между разработчиками? Как могут звучать конкретные задания?

Я попробую сейчас так, как сам себе это интуитивно представляю, а вы меня порпвьте если я не прав.

Возмём, для примера, простую задачу и разделим ее на двоих:
создать игру крсестики-нолики 3х3 против компьютера.

Это очевидно, что для начала совместной работы нужен общий план.
:umnik2:

ход игры:
- прелоадер
- анимация появления игрового поля
- кроме игрового поля на экране есть кнопки "прваила" и "новая партия", а так же итоги предыдущих партий
- первым ходит проигравший, в первой партии первым ходит пользователь
- после окончания партии или клика на кнопку "новая партия" начинается следующая игра
- по клику на кнопку правила открывается окно с правилами и кнопкой "Да знаю я ваши првила!"
- выиграв 3 партии подряд в четвёртой компьютер должен потдаться на втором ходу (для поддержания азарта :~) )

нам понадобятся следующие классы:
Main - основной класс - отвечает за загрузку и анимацию поялвления игры на экране, содержит окно с правилами и игровое поле, слушает события игрового поля, запускает IQ, считает и отображает счёт

GameBoard - игровое поле, отвечает за отображение игрового поля,
анимацию ходов, за клики игрока.

GameData - текущее состояние игры
хранит текущее состояние игры и проверяет не закончилась ли игра

IQ - искуствнный интелект, который будет отвечать за ходы компьютера

всё пишем на AS3 (flex без стандартных компонентов)
вся гафика (анимация) должна быть в отдельных картинках (swf роликах) которые можно легко заменить.

структура проекта:
[bin]
-Main.swf
[src]
-Main.as
-GameBoard.as
-GameData.as
-IQ.as
[assets]
-картинки и swf-ки необходимые для компиляции

Main и GameBoard пишет один человек, GameData и IQ другой

Вроде всё, но как начинать работать?
Как классы будут общаться между друг другом?
Тут я должен расписать все публичноые методы всех классов и все события?

И ещё, что мы будем делать, если заказчик вдруг захочет добавить возможност выбирать язык и поддержку красочных скинов ?

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

вообще, зависит от уровня контроля разработки, количества/качаеста разработчиков и естственно сложности проекта. Если у лидера проекта мало времени, то лучший подход на мой взгляд - это разработка архитектуры + переодические пинки разработчикам дабы направить их талант в нужное русло и уберечь их от углубления в те аспекты которые не являются частью плана.

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

Очень полезные 2 штуки в проекте нужны:
changelog - туда пишутся изминения введенные разработчиками, время изминения, описание оного и имя разработчика.
todo - ту ду, список того что нужно сделать. когда разработчик заканчивает свой небольшой таск над которым он работал, он может прочитать туду и найти себе еще что-нибудь конструктивного дабы занять его драгоценное время.

Общение. Общение очень важная часть разработки. Очень полезно создать форум для разработчиков где бы они могли постить запросы друг другу. Телефон, личный контакт, IM.

надеюсь это поможет, удачи.

Usnul, спасибо за ответ.
Естественно, надо разбивать проект на модули - иначе просто никак.
Меня волнует как с наименьшими трудозатратами и максимально доступно описать эти модули, так чтобы вся команда смогла начать работу без вопросов.

в качестве changelog-а вполне годится сам SVN, просто при commit-e писать комменты
а для todo можно использовать систему вроде Basecamp

что никто больше не сталкивался с работой в команде?

Меня волную такие моменты:
1) в какой форме подготавливать архитектуру проекта?
2) каким образом оформлять задачи для разработчиков?
3) как разделять достаточно тесно связанные задачи?

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

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

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

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

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

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

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

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

cтукнул :~)