Советы / рекомендации по управлению новой командой с новым кодом [закрыто]

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

Руководство настаивает на повышении производительности всей команды, и вы, как старший разработчик, несете ответственность.

Какие-либо советы для выхода козыри в такой ситуации? Очевидно, что всей команде нужно время, чтобы учиться, и давайте не будем забывать о новой команде. Однако сроки еще впереди ...

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

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

Перво-наперво, начните использовать систему контроля исходного кода с самой первой строки кода. Привыкайте проверять код рано и часто.

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

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

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

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

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

В дополнение к ответу @chrisaycock ... Не стоит недооценивать время, которое вам нужно будет выделить для наставничества / обучения и т. Д. В качестве лидера вам нужно научиться отпускать детали и доверять своей команде. Ваша работа заключается в том, чтобы стать инициатором, средством для устранения препятствий на дорогах и создавать помехи, когда руководство идет туда. В «нормальной» команде примерно 7 или 8 лидерство больше не программирует. В вашей ситуации это уменьшается до 3 или 4 (Может быть, даже меньше), Вы не программистский ресурс для проекта.

Сосредоточьтесь на общении в двух областях.

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

2) Межкомандное общение. Установите формальные практики, как Брайан и другие рекомендуют. Убедитесь, что вы регулярно встречаетесь в команде, например, один раз в неделю в дополнение к ежедневным беспорядкам. Получите уважение и доверие, слушая , ваш самый важный инструмент. Убедитесь, что вы сосредоточены на помощи. Избегайте негативной критики любой ценой. Когда необходимо, используйте положительную критику и поддержку, например, «это здорово, если вы захотите рассмотреть вопрос о том, что X« закончен », это не то, что нам нужно, вместо этого вам нужно сделать X».

Что я сделал, так это определил способных, разделяй и властвуй. Я беру топ 2 или 3 и делаю их капитанами. Остальные затем равномерно делятся на команды, следуя за капитанами в их собственные маленькие команды.

Я даю капитанам куски или модули для выполнения программы.

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

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

Это хорошо работает для 10-20 программистов. Меньшие группы просто лучше быть в одной группе, и я еще не работал с чем-то большим.