Забагато старших людей в одній команді? [зачинено]

Чи може занадто багато старших програмістів в одній команді виявитися поганою справою?

Як сказати, 4-5 старших програмістів у команді з 6-7 осіб. Яке оптимальне число / співвідношення у подібних ситуаціях?

Чи може це призвести до занадто великої філософії та аргументів щодо ідей?

Хтось мав такий досвід, що може поділитися ним зі мною?

Якби я міг обрати, я мав би 6-7 людей похилого віку в команді (якщо припустити, що проект потребує багатьох).

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

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

EDIT : Багато інших відповідей говорили про те, що занадто багато лідерів є проблемою - але чому існує думка, що старший повинен вести? Старший повинен бути досить зрілим, щоб вибрати лідера і слідувати. Саме проект важливий - виберіть / отримайте роль і розкачайте це нерозумно!

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

Чи може це призвести до занадто великої філософії та аргументів щодо ідей?

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

Чи може занадто багато старших програмістів в одній команді виявитися поганою справою?

Безумовно.

Я великий прихильник хірургічної команди Фреда Брукса .

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

PS Потреба розробника в "головному хірурзі" аналогічна потребі оркестру в диригенті. У будь-якому випадку у вас, швидше за все, буде багато ветеранів; але у вас буде безладний безлад без однієї людини, яка безперечно відповідає.

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

Чи може занадто багато старших програмістів в одній команді виявитися поганою справою?

Не обов'язково. Я працював над невеликими командами старших розробників, які були високопродуктивними. Рівень дискурсу був дуже високим, і не було ранку.

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

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

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

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

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

Зараз я працюю в команді 8, де старше 5 або 6, і це працює дуже добре для нас. Ми добре ладимо, вчимось один у одного, і це чудове середовище для наставників для нових хлопців, які у нас є.

Я працював у команді, де було 1 головний розробник, 4 старші розробники та 1 середній розробник. І тому, що один «старший» член команди не був справді зрілою людиною (хоча хороший розробник), це виявилося кошмаром. Він увесь час намагався довести (неявно або явно), що інші члени команди недостатньо старші. Крім того, він не зміг зрозуміти основні принципи розробки програмного забезпечення та специфіку нашого продукту, а тому зухвало і вперто намагався довести, що він правий. Як результат, це серйозно позначилося на ефективності команди. Сумно полягає в тому, що це навіть не було занадто багато аргументів щодо ідей / рішень - це було аргументом ні про що . Наприклад:

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

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