Доброе время суток.
Хотел бы узнать как организовывается коллективная работа большого количества разроботчиков (большее 1) программного обеспечения (в т.ч. и игр, ОС и так далее)?
Вобщем реальные менеджеры и те у кого просто есть идеи по этому поводу - делитесь. Буду рад вашим ответам!

KaraKum,  Оч просто :
Есть  Project Manager   который  Бог, царь и папа на проекте.   Есть  группки  по 12 (примерно) челов, которые  разрабатывают проект.  Там :   Программер  лидер,  девелоперы и тестеры. 
В общих чертах, это все !   Если что по конкрентнее,  спрашивайте ! 

Вот как раз конкретность меня и удивляет!
Как можно распределить труд между многими программерами, а потом соединить их результаты в один, если, конечно, они не дизайнеры, который делают всякие 3D-модели, картинки или ролики?
Я сам занимаюсь программированием игр, совсем недавно и в-одиночку, и нет почти ни одного элемента, который можно написать без понимания всего механизма игры. - Как я это понимаю. И кажется, что на обговаривание общих моментов они тратят значительно больше времени, чем на само программирование.

Существует эта проектирования, на котором разрабатывается вся система в некоторой детализации. Так что все исполнители осведомлены о системе в целом, но лучше всего знаю только свою часть.

Но остаётся не понятным как организовывается такой коллективный труд именно с программной точки зрения?
Даются указания по созданию конкретных классов или функций, которые должны выполнять определённые операции? - примерно так?
И если можно, пожалуйста, как можно конкретнее.

KaraKum, 
Вобщем  :
Есть задача :   написать   программу    икс (Х) 
Ты собираеш себе команду, которые пишут на разных языках (Си шарп,  донет, джава..)  а потом  ты с помощью  мавена всю  эту крастоу  билдеш !!
Что не понятно ????

Не понятно именно разделение обязанностей.
Допустим такой пример: нужно сделать игровой движок и было решено разделить задачи проектирования циклов игры и организации поддержки лан-игры, соответственно, между двумя программистами. Так вот, как можно создать поддержку лан-игры не зная досканально реализацию и сам код циклов игры? По-моеуму второму придётся его знать настолько досконально, что, наверное, потратится столько времени на его осмысление, почти равноценное его же написанию.
И ещё важным вопросом является принятие организатором решений о сложности некоторых моментов и соотвествующее их распределение между программистами, чтобы каждому - одинакого.
Я в этом деле новичок и хочу узнать как можно больше, поэтому не судите строго   .

Это сообщение отредактировал(а) KaraKum - 22.3.2008, 09:31

приведу простой пример: когда пишешь программу, скажем, под Windows, ты не только без знания структуры системы можешь обойтись, но и даже без интерфейса составляющих систему библиотек: windows API. Ты берешь какую-то абстрактную библиотеку, в которой есть функция "нарисовать окно" и "нарисовать кнопку". хорошо спроектированная система должна иметь такую структуру, чтоб принимать минимально необходимый набор данных и выдавать однозначный результат. в таком случае её просто описать и просто использовать, не зная ничего о её внутреннем устройстве.
возможно, в некоторых случаях, несколько человек могут работать над объемной, но единственной задачей(конкретная подсистема рендеринга или правила поведения ИИ), и в таком случае будут знать код "друг друга"(на самом деле это будет "общий код"), но при правильном руководстве ни к каким проблемам это привести не должно. Даже методология разработки есть такая: "экстремальное программирование". насколько мне известно(в теории, на практике применять не доводилось), одним из китов методологии является "разработка в паре".

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

если чисто технически - обычно выглядит таким образом

система разбивается на подсистемы, которые друг с другом связаны слабее, чем компоненты внутри системы

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

потом специалистам уже менее крутым даётся задача в рамках уже данного скелета добавлять фичи
типа "вот тебе API, вот тебе пример как делать компонент - сделай ещё 20 штук таких же, по функциональной спецификации"

ведущие при этом пасут, что там некрутые себе делают, и по необходимости ими подруливают
по необходимости вносят изменения в "скелет"

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

вот как-то так

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

Это сообщение отредактировал(а) KaraKum - 25.3.2008, 10:15

KaraKum
Если рассматривать с технической точки зрения, то общий код никогда не пишется одновременно (за исключением особых практик, таких как вышеупомянутое парное программирование в XP). Даже если несколько человек пишут близкие по фукциональности вещи - все равно происходит разделение: два человека в один момент времени не изменяют одно и то же место в коде. В дальнейшем все это сводится в системе контроля версий. Т.е. общий код может разрабатываться несколькими людьми, но в разные моменты времени.

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

С точки же зрения управления всей этой толпой - каждый кусок кода должны знать несколько человек. Это обеспечивает выживание проекта в случае ухода одного или нескольких разработчиков, что в более-менее больших проектов случается всегда; нельзя надеяться, что по прошествии нескольких лет команда из 10-50 человек сохранит свой исходный состав.

Как ты правильно заметил, производительность коллектива из N человек не равняется N-кратной производительностью одного человека. Но факторов здесь достаточно много, и они могут влиять как в отрицательную, так и в положительную сторону. 
Так отрицательными фаторами являются затраты на коммуникацию, изучение чужого кода, сложность распараллеливания задач и пр. 
В то же время есть и положительные, например увеличение общей производительности команды за счет разбиения задач согласно квалификации исполнителей (то, что делают опытные разработчики - слишком сложно для джуниоров; то, что делают джуниоры - слишком скучно для опытных), также происходит повышение квалификации разработчиков за счет общения с более опытными коллегами.

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

Мдаа.. сложное это дело - организация коллективного труда.

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

Это сообщение отредактировал(а) KaraKum - 26.3.2008, 00:26

KaraKum, ты реферат пишешь?
это зависит от руководителя и сложности задачи: небольшая casual-игра не требует "сценаристов" и прочие ньюансы.
или ты думаешь, что реально можно получить ответы на все вопросы?

Хочу знать о фактах - может кто-то уже учавствовал вообще в программных проектах - и не особо важно в каких - играх, ОС, простые проги, проги для программистов и так далее - полезна любая информация.