10.01.08: Разработка AstroMenace. Распределённая разработка.

Сейчас я хочу немного рассказать о процессе разработки игры AstroMenace, как я уже говорил, речь пойдёт об особенностях разработки с привлечением удалённых специалистов, т.е. фактически о распределённой разработке игры.

Прежде всего, давайте рассмотрим какие программы мы использовали для «обеспечения» распределенной разработки:

1) Пожалуй, прежде всего стоит написать о почтовом клиенте, в моем случае Mozilla Thunderbird. Именно через электронную почту идет первоначальное общение и передача промежуточных результатов работы.

2) Клиент для передачи мгновенных сообщений Gaim (теперь уже Pingin), использовались протоколы ICQ и jabber. Очень удобно для каждодневного общения, когда нужно обменяться небольшим количеством информации и обговорить какой-то момент в работе.

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

4) В очень редких случаях использовался фтп клиент gFTP. Передача больших объемов информации (вводные материалы для задания или конечные результаты работы) строилась через наш фтп сервер.


Теперь я хочу вам рассказать о некоторых «ограничениях» примененного метода разработки. В нашем случае, при разработке AstroMenace, получилось «колесо» (по структуре внутренних связей конечно :-) ). Я был в середине, и ко мне вели все «спицы» (т.е. внутренние связи между каждым специалистом), с другой стороны связей непосредственно между специалистами небыло. Плюс данного подхода – никакой демократии, вы четко знаете что и как. Однако, могут быть проблемы с центром «колеса» (один человек может тормозить всю работу). Случаи, когда не стоит использовать «колесо»:

1) Если у вас нет опыта, т.е. вы не можете/знаете как правильно ставить задания 3D моделеру, художнику, музыканту, и в добавок у вас нет знаний проверить выполнение и/или скорректировать направление их работы.

2) Если проект большой (управлять более 7-8 людьми разной специализации очень тяжело) – лучше выделить людей в группы по направлению работы и поставить каждой группе своего лида (от lead).

3) Каждый удаленный специалист должен делать свою работу до законченного вида, изготовление «полуфабрикатов» для доработки другим специалистом желательно избегать. Лучше сразу объединить этих людей в группу и назначить ответственного. Например: 3D моделер+текстурщик (у нас это не понадобилось – все моделеры рисовали текстуры сами).


Собственно сам процесс разработки в нашем случае строился таким образом (с небольшими комментариями для тех, кто захочет повторить):

1) Определится с необходимыми специалистами для разработки проекта и найти их. Это может показаться смешным на первый взгляд, но найти хорошего специалиста не так и легко. Тут стоит сразу оценить что вам нужно, возможно, имеет смысл переложить часть работы на специализированную компанию (в частности, для разработки музыки, звуковых эффектов и записи голоса мы прибегали к услугам компании «the SandS»).
Советую подойти к этому пункту очень серьезно, чтобы потом не было проблем (некачественная работа за которую вы не хотите платить, или срыв сроков). Сообщества специалистов (художников, 3д моделеров, программистов и т.д.) очень небольшие, заиметь плохую репутацию очень легко, а заработать хорошую – довольно проблематично (особенно это актуально для удаленной работы).

2) Правильная постановка задачи. Фактически, вы должны каким-то образом донести до специалиста что именно вы хотите от него получить, что должно быть в результате. Хочу сразу предостеречь – не пытайтесь «учить» человека как и что делать, наверняка он знает предмет гораздо глубже вас и сможет сам предложить массу вещей (главное – дайте ему такую возможность).

3) Ожидание. Старайтесь не мешать человеку работать. Т.к. вы не сможете наблюдать за процессом выполнения постоянно, старайтесь не поддаваться желанию отвлекать специалиста вопросами о текущем состоянии выполнения. Если работа большая, обговорите сразу передачу вам промежуточных данных, скажем раз в 1, 2 или 3 дня.

4) Проверка результата. После получения конечного результата – внимательно его изучите прежде чем сказать конечное «работа принята, претензий нет», чтобы потом не было недоразумений и нюансов из серии «вот тут надо подправить». Помните, человек будет работать уже над чем-то другим (возможно на другого человека), доделка/переделка может потребовать значительного времени, человек может просто отказаться что-либо делать бесплатно (и будет совершенно прав).

No comments yet