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

Мне всегда везло работать в маленькой команде программистов. Я думаю, что больше всего я работал с 11 программистами. Каково это работать над проектом с сотнями разработчиков? Тысячи? Что масштабируется, а что нет?

РЕДАКТИРОВАТЬ: Спасибо за все ответы! Кажется, очень мало позитива:

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

Есть ли какая-то другая польза для больших команд?

Я нахожу бюрократические весы очень хорошо.

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

Самый большой проект, над которым я работал, имел около 70 разработчиков на 5 разных сайтах. Даже изменение одной строки заняло минимум один день, хотя это было отчасти из-за того, что сборка заняла более 45 минут по сетевому каналу из Цюриха в Лондон, а запуск приложения занял еще 45 минут. Регистрация заняла около 5 минут на файл. Я не шучу. Лондонские разработчики могли бы сделать это за короткое время.

В любом случае, вы склоняетесь к тому, что в больших проектах у вас будет куча членов команды, с которыми вы не так уж много общаетесь. Это больше похоже на сборник мини-проектов. Однажды я читал, что разработка Microsoft имела тенденцию разбивать проекты на команды из 5-7 разработчиков, даже для крупных проектов, таких как Microsoft Office.

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

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

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

Общение - это то, что я считаю самой большой вещью, которая начинает ухудшаться по мере роста размера команды. Становится все сложнее общаться, и все труднее следить за тем, чтобы все были на одной странице. Я косвенно работаю в команде из примерно 75 разработчиков, мы используем общую кодовую базу, но многие из 75 разбиваются на более мелкие группы для отдельных «действий». Для нас общение - это просто кошмар.

Управление большими группами также сложнее, так как в большинстве сред после 8-12 человек участвуют дополнительные члены управления, к сожалению, это только преувеличивает проблему связи, поскольку обычно создает среду типа «бункер», где отдельные подмножества начинают разрываться. большая группа и стараться держать знания внутри своей группы.

Когда я создавал программное обеспечение для систем вооружения, у нас была БОЛЬШАЯ команда разработчиков программного обеспечения. Поскольку ни один человек не может обернуть голову вокруг требований (некоторые из которых были классифицированы), все дело было в командах и в том, как команды взаимодействовали друг с другом.

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

2. Разрешения на работу - и начисление времени на правильную позицию в общем графике проекта - было большой болью в шее. До 0,1 часа. приращения.

Но самой большой сделкой было уведомление об изменении. В частности, изменения интерфейса.

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

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

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

Моя первая «настоящая» работа по программированию состояла в том, чтобы работать с армией и другими в разработке международных систем управления воздушным движением. Это было очень успешное начинание, и нас считали средой уровня зрелости Capability Model 5. С тех пор я был в средних и небольших магазинах. Итак, какое место лучше? Лично я бы взял маленький магазин по сравнению с огромным в любой день. В то время как некоторые могли бы считать Уровень 5 Святым Граалем, для меня это удушало. Все должно быть задокументировано, одобрено, подписано и т. Д. Не поймите меня неправильно, я определенно вижу в этом ценность, особенно для таких критических систем, как управление воздушным движением, но вопрос в том, как вы хотите тратить свои деньги? день? Вы хотите свободы, чтобы придумывать вещи, а затем реализовывать их, или ты хочешь написать с требованиями? Возможно, если бы я дольше оставался с системой УВД, я мог бы подняться до уровня способности проектировать, а также разрабатывать, но даже для этого требовалось X лет, Y разрешений, Z повышений - все хорошо прописано без шансов отклонения. Это было душно.

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

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

В этом конкретном месте программное обеспечение было разделено на компоненты, а команды были сформированы вокруг компонентов. Некоторые команды будут работать только с одним (большим) компонентом, в то время как многие группы несут ответственность за несколько (меньших) компонентов.

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

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

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

Единственное отличие, которое я заметил в больших проектах, - это офисная политика. Чем больше проектов, тем больше доминирует политика.

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

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

Однажды я провел год, работая в команде из более чем 500 человек, около 200 из них были разработчиками. Мы поставляли EOA, интегрируя несколько различных SOA-решений.

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

Самая большая команда, над которой я когда-либо работал, составляла около 15 человек (это было всего 3 или 4 месяца в другой компании). Я был техническим руководителем в команде, и приступил к работе в 7 утра, я получил 2 часа до того, как все остальные вошли, это был единственный способ, которым я мог выполнить любую из моих собственных задач.

Я не хотел бы работать в команде с более чем 8 или 10 разработчиками, 15 было слишком много для одной команды (команда могла бы быть легко разделена на две, к сожалению, не мой призыв), 3 или 4 разработчика - это хороший удобный размер ИМХО