Слишком много пожилых людей в одной команде? [закрыто]

Может ли слишком много старших программистов в одной команде оказаться плохой вещью?

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

Может ли это привести к чрезмерной философии и спорам об идеях?

У кого-нибудь был такой опыт, которым можно поделиться со мной?

Если бы я мог выбрать, у меня было бы 6-7 старших в команде (при условии, что проекту нужно столько).

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

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

РЕДАКТИРОВАТЬ : Многие другие ответы сказали, что слишком много лидеров является проблемой - но почему существует мнение, что старший должен руководить? Старший должен быть достаточно зрелым, чтобы выбрать лидера и следовать за ним. Это проект, который имеет значение - выбери / получи роль и сделай это глупо!

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

Может ли это привести к чрезмерной философии и спорам об идеях?

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

Может ли слишком много старших программистов в одной команде оказаться плохой вещью?

Определенно.

Я большой сторонник модели хирургической команды Фреда Брукса .

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

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

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

Может ли слишком много старших программистов в одной команде оказаться плохой вещью?

Не обязательно. Я работал в небольших командах старших разработчиков, которые были очень продуктивными. Уровень дискурса был очень высок, и не было злобы.

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

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

Оптимальный зависит от ряда переменных, которые вы не раскрываете. Какой показатель вы хотите использовать, понимая, что здесь есть хорошие шансы для игровой системы. Точно так же, какие у вас есть ограничения в вашем мире, которые могут отличать его от того, что Google или Microsoft могут противопоставить.

Я думаю, что слишком много старших разработчиков могут столкнуться с проблемой отсутствия соглашений или слишком большого количества соглашений. Хотя некоторые старшие разработчики могут хорошо адаптироваться, если ни один из них, вероятно, не введет соглашение, с чего бы команде начать? И наоборот, некоторые старшие разработчики могут быть фанатами некоторых соглашений, для решения которых может потребоваться разрешение конфликта.

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

В настоящее время я работаю в команде из 8 человек, где 5 или 6 человек старше, и это очень хорошо работает для нас. Мы хорошо ладим, учимся друг у друга, и это отличная среда для наставничества для новых ребят, которые у нас есть.

Я работал в команде, в которой было 1 ведущий разработчик, 4 старших разработчика и 1 средний разработчик. И из-за того, что один «старший» член команды не был действительно зрелым человеком (хотя и хорошим разработчиком), это оказалось кошмаром. Он все время пытался доказать (неявно или явно), что другие члены команды недостаточно взрослые. Кроме того, он не в состоянии понять основные принципы разработки программного обеспечения и особенности нашего продукта, и, следовательно, высокомерно и упорно пытался доказать , что он прав. В результате это серьезно сказалось на эффективности команды. Грустная часть состоит в том, что это даже не было слишком много спора об идеях / решениях - это был спор ни о чем . Например:

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

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