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

9

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

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

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

Fanatic23
источник
Должен быть на pm.stackexchange.com
JBRWilkinson
5
@JBRWilkinson Я не согласен. Это о том, чтобы быть техническим лидером младших разработчиков с жестким сроком. Я бы согласился, если речь идет о том, как управлять проектом младших разработчиков, однако быть техническим руководителем - это не то, что быть руководителем проекта.
maple_shaft

Ответы:

13

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

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

chrisaycock
источник
Убедитесь, что у всех в команде есть возможность оценить все задачи, которые им предстоит поручить, чтобы у них был некоторый вклад в сроки. Так как ваша команда все еще изучает веревки, не отдавайте кому-либо больше пяти часов в день, когда вы превращаете оценки в истекшее время. И если сроки не могут быть соблюдены, убедитесь, что руководство знает об этом как можно скорее.
Дауд ибн Карим
1
@ Дэвид - Как вы потратили 5 часов (на самом деле это неплохая цифра, но откуда мы ее знаем)? Просто признайте, что оценивать такой проект - просто дерьмо и рассказать руководству.
Mattnz
3
Я считаю, что большинство людей продуктивно работает от 6 до 6,5 часов в день. Некоторые справляются с этим больше, но я думаю, что это хороший средний показатель. Но поскольку команда нова, на обучение уходит как минимум один час в день. И я верю в оценку - хотя не все хороши в этом, это должно быть лучше, чем просто прыгать и программировать, не зная, сколько времени займет задание.
Дауд ибн Карим
Это помогает принять участие, если вы заставите членов команды разработать свои оценки до того, как увидите запланированное время, и они значительно не превысят план. Наличие их оценки до просмотра других оценок также позволит избежать искажения оценки.
BillThor
@BillThor: Конечно, вы заставляете парня делать работу, чтобы оценить ее, и использовать его цифры в качестве отправной точки. Я только что оценил работу и мне сказали: «Хотя это будет 1/3 от этого». Почему они даже удосужились спросить меня, если бы знали, сколько времени это займет?
Mattnz
7

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

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

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

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

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

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

Брайан Оукли
источник
2
+1 за контроль версий и рецензирование кода рано и часто.
JMQ
2
Я придерживаюсь мнения, что контроль источников является настолько необходимым процессом, что его следует выполнять независимо от состава команды, независимо от чего-либо.
maple_shaft
6

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

mattnz
источник
+1 на выделение времени для наставничества и обучения. Эффективный технический лидер делает молодых разработчиков продуктивными.
maple_shaft
«Вы не программный ресурс для проекта». Интересно, чувствует ли его руководство то же самое, хех. Я надеюсь, что вы не станете программистом-героем проекта.
JMQ
У меня сложилось впечатление, что ОП был просто самым старшим разработчиком и не имел никакого специального названия или обязанностей (то есть он не «технический руководитель» или «архитектор»). В этом случае он, безусловно, является ресурсом разработки, и, вероятно, ожидается, что он будет наиболее продуктивным.
TMN
@ TMN: я отражал реальность того, что происходит в команде с одним опытным / опытным парнем, а все остальные значительно менее опытными. Без сомнения, опытный парень, если он кодирует, будет наиболее продуктивным, и ожидается, что он будет кодировать. КОМАНДА будет наиболее продуктивной, если он этого не сделает. В непросветленной организации менеджеры измеряют индивидуальные показатели, поэтому ведущий выглядит плохо, выполняя то, что лучше всего - заставляя КОМАНДУ выступать, и получает за это небольшое вознаграждение. Ему лучше вывешивать юниоров в сухом виде и выглядеть великолепно.
Mattnz
1

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

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

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

наркоман
источник
0

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

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

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

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

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

Джейсон Себринг
источник
Divide & Conquer имеет свои подводные камни. Я видел, что в итоге каждый подгруппа изобретает колесо (плохо) для подобных проблем, с которыми сталкивается вся команда.
NWS
Да, если вы находитесь в отдельных зданиях, особенно, поэтому я стараюсь держать всех на открытом пространстве и регулярно гулять. Что я делаю, так это создаю основные сигнатуры API и собираю команды для их создания, чтобы все это соединялось.
Джейсон Себринг,