Як це працювати у великій команді програмування?

Мені завжди пощастило працювати в невеликій команді програмування. Я думаю, що найбільше я працював з 11 програмістами. Як це працювати над проектом із сотнями розробників? Тисячі? Що означає масштаб, а що ні?

EDIT: Дякую за всі відповіді! Здається, що позитивів дуже мало:

• можливо працювати на мега-великих кодових базах
• кращий внутрішній кар’єрний розвиток
• захист співробітників від зловживань (це більше - мало на ніж + більше на великих)

Чи є якась інша користь для великих команд?

Я дуже добре знаходжу масштаби бюрократії.

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

Найбільший проект, над яким я працював, мав 70 або більше розробників на 5 різних сайтах. Навіть одна зміна рядка займала щоденний мінімум, хоча це частково пояснювалося тим, що збірка зайняла 45+ хвилин через мережеве з'єднання від Цюріха до Лондона, а запуск програми зайняв ще 45 хвилин. Записки займали близько 5 хвилин на файл. Я не жартую. Лондонські розробники могли це зробити за частину часу.

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

Частиною різниці є також різниця між малими та великими компаніями: більші компанії, як правило, мають більше процесу, більше правил, меншу гнучкість тощо. Але це аж ніяк не гарантується.

Хоча це може бути корисним і для кар’єрного розвитку. У невеликій компанії хтось повинен покинути або померти, перш ніж отримати акцію (або компанія повинна зростати таким чином, що команда розширюється, а ви рухаєтеся вгору), тоді як у більших відділах розробників ви можете переходити між командами тощо.

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

Комунікація - це те, що я вважаю найбільшою справою, яка починає погіршуватись із зростанням розміру команди. Зробити спілкування стає важче, і важче переконатися, що всі залишаються на одній сторінці. Я опосередковано працюю над командою з близько 75 розробників, ми використовуємо загальну кодову базу, але багато хто з 75 розпадаються на менші групи для індивідуальних "заходів". Для нас спілкування - це просто повний кошмар.

Управління більшими групами також складніше, оскільки в більшості середовищ після 8-12 людей включаються додаткові члени управління, на жаль, це просто перебільшує проблему зв'язку, оскільки, як правило, створює середовище типу "силос", коли окремі підмножини починають відриватися від велика група та намагайтеся зберегти знання всередині своєї групи.

Ще коли я робив програмне забезпечення для систем озброєнь, у нас були ВЕЛИКІ команди розробників програмного забезпечення. Оскільки ніхто не може обернути голову навколо вимог (деякі з яких були класифіковані), мова йшла про команди і про те, як команди взаємоділи один з одним.

1. Управління конфігурацією - нічний процес збирання - було дуже великою справою. У ті часи знадобився великий розподілений обчислювальний кластер, щоб перекомпілювати світ щовечора.

2. Дозвіл на роботу - і заряджати час на правильну позицію у загальному графіку загального проекту - було великим болем у шиї. До 0,1 години. прирости.

Але найбільшою справою було повідомлення про зміни. Особливо зміни інтерфейсу.

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

Після того, як запит було затверджено, фактичне повідомлення більш-менш зменшилось. Це означає, що це дійсно одношаровий процес і запит фактично був повідомленням. Але коли ви займаєтеся розробкою водоспадів, все потрібно продумати довго, перш ніж з’являться будь-які розробники.

Оскільки стільки людей паралельно працювало, була рада управління конфігурацією. Всі різні менеджери колективів, а також група людей, котрі мали завдання просто координувати зміни.

Моя перша "справжня" робота з програмування полягала в тому, щоб співпрацювати з іншими арміями з розробки міжнародних систем управління повітряним рухом. Це було дуже успішним починанням, і нас вважали середовищем зрілості моделі здібності 5 рівня. З тих пір я був у середніх і маленьких магазинах. Отже, яке найкраще місце бути? Особисто я б зайняв менший магазин за величезним у будь-який день. Хоча деякі можуть вважати рівень 5 святим Граалем, для мене це було задушливим. Все має бути задокументовано, затверджено, підписано тощо. Не помиляйтесь, я точно бачу цінність у ньому, особливо для систем, настільки критичних, як контроль повітряного руху, але питання полягає в тому, як ви хочете витратити свої кошти день? Чи хочете ви свободу мати можливість омріяти речі, а потім реалізовувати їх, чи ви хочете написати до вимог? Можливо, якби я довше залишився з системою УВД, я міг би піднятися до рівня вміння проектувати, а також розробляти, але навіть для цього потрібно X кількість років, Y кількість схвалень, Z кількість рекламних акцій - все добре прописано без шансів відхилення. Це було задушно.

І останнє, в цілому я вважаю, що якість розробників є значно вищою у менших компаніях просто тому, що вони не можуть приховати. Бути посереднім у дуже великій компанії не важко, але в малій стає болісно очевидним, і вони часто не тривають довго.

Я працював (коротко) в організації, принаймні сотні розробників. Але звичайно (?) Організація розподілена внутрішньо, так що ви як один працівник не маєте прямого контакту з усіма іншими, що було б дуже важко йти в ногу.

У цьому конкретному місці програмне забезпечення було розбито на компоненти, навколо яких склалися команди. Деякі команди працюють лише з одним (великим) компонентом, тоді як багато команд відповідали за купу (менших) компонентів.

Звичайно, це означає все, що робить робота з дуже великою базою коду; такі речі, як управління конфігурацією, побудова, інтеграція тощо, стають важливими, великими, речі, які в свою чергу виробляються спеціалізованими спеціалізованими відділами. І ви їх вдячні за те, що змогли збирати результати всіх відділів розробників і регулярно (раз на тиждень, де я працював) інтегрувати все це в одне ціле ціле, яке фактично працювало.

Я ніколи не працював над великою командою програмістів , але результатом організації, що збільшується в розмірі, зазвичай є більше правил. Це не обов'язково завжди погано! Окрім правил, які ускладнюють життя кожного, існує також більше правил для захисту працівників та забезпечення хорошого процесу.

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

Єдина відмінність, яку я помітив у великих проектах, - це офісна політика. Чим більше проектів, тим більш домінуючою є політика.

Першим моїм проектом поза школою було пару сотень розробників. Як зухвалий і наївний розробник, ще зі школи, я насправді був не готовий до цього. Єдине, що врятувало мою гінею (і це єдине, що коли-небудь по- справжньому захистить вас) - це кількість друзів, які я створив.

Це найбільший урок, який я навчився з цього. Спробуйте подружитися з усіма . Навіть ривки. Зокрема, якщо у вас є шанс припинити роботу на хвилину і поговорити з тим, з ким ви ніколи не спілкувалися, зробіть це.

Я одного разу провів рік, працюючи над командою, в якій понад 500 людей, приблизно 200 - це розробники. Ми пропонували EOA, інтегруючи кілька різних рішень SOA.

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

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

Я не хотів би працювати в команді з більш ніж 8 або 10 розробниками, 15 було занадто багато для однієї команди (команду можна було легко розділити на дві, не на жаль, на мій виклик), 3 або 4 розробника - це приємний розмір IMHO