Как добавить нового разработчика в команду

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

Теперь этот клиент получил важное спонсорство, и они организуют мероприятия, связанные с этим проектом. Так что теперь у нас есть срок в 2 месяца, и мы не можем его пропустить.

Мы думаем о добавлении нового разработчика в команду, и мне интересно, что мы можем сделать, чтобы помочь его интеграции.

Это ситуация:

• Мы приближаемся к порогу закона Брукса - момент, когда добавление новых разработчиков будет контрпродуктивным.
• Приложение относительно хорошо разработано, но реализация в некоторых моментах хаотична (особенно старый код).
• Есть модульные тесты только для более свежего кода. Когда начался этот проект, мы не проводили регулярные тесты.
• Документация и комментарии являются неполными.
• Приложение является как большим, так и сложным.
• Клиент записал почти каждую деталь своего проекта в очень понятной и «дружественной к программисту» форме.

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

РЕДАКТИРОВАТЬ:

Спонсор организует спортивное мероприятие в Интернете на весну следующего года. Это должно начаться в определенный день года. Мы не можем это изменить.

Что мы, разработчики (я один из двух), должны сделать так:

• Завершение существующего приложения (около 25% работы предстоит сделать).

• Создание нового модуля, необходимого для организации этого мероприятия (около 75% работы предстоит сделать). Этот новый модуль не может быть разработан без понимания основного API программы.

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

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

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

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

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

Это хорошая идея, чтобы добавить человека сейчас?

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

Добавление человека таким поздно добавит значительный риск, и срок не может быть перенесен (насколько я понял).

Не делай этого.

Еще.

Традиционный вид

В своем вопросе вы ссылаетесь на закон Брукса из « Мифического человека» .

Добавление рабочей силы в поздний программный проект делает это позже.

Игнорировать закон Брука несет цену. Не многозадачность. Сосредоточьтесь на доставке вашего минимально жизнеспособного продукта (MVP). Затем сфокусируйте свою энергию на подборе, предоставлении ресурсов, обучении и управлении новым членом команды.

Два месяца так коротко. Запланируйте рекрутинг со списком выгорания, и вы увидите, как много времени это может занять.

Ларри Пейдж и Сергей Брин провели два года, выбирая команду для Google. Ваш выбор для сотрудника номер три также должен быть осторожным.

Agile, New Millenium View

Конкуренция стимулирует динамичное объединение сейчас больше, чем в эпоху, когда был написан «Мифический человеко-месяц» (середина 1960-х). Долгая карьера в одной компании ушла. Сейчас мы часто мигрируем между проектами и компаниями. Быстрое построение команды создает успех. Медленное наращивание является серьезным ограничивающим фактором. Хорошие примеры - проекты с открытым исходным кодом, стартапы и более широкое использование командных проектов на курсах по информатике.

Потенциально гибкие команды учитывают ограничения в своих графиках. Они не опаздывают, потому что они оптимизированы для доступных ресурсов. Интеграция новых сотрудников является еще одним препятствием и рассматривается как компромисс между краткосрочными и долгосрочными целями. Команда Agile постоянно интегрирует код, так почему бы и не люди?

Техническая и социальная интеграция Agile команды для новых сотрудников может использовать:

• ежедневные ссоры
• парное программирование
• рефакторинг
• добавление недостающих юнит-тестов
• откармливание скудной документации
• код отзывы

Жертвенный Агнец

В « Организационных моделях гибкой разработки программного обеспечения» Джеймс Коплиен обсуждает групповую динамику и затраты на добавление новых членов команды. Его паттерн «Жертвенный ягненок» назначает все наставничество и обучение одному человеку, защищая остальную команду от перерыва.

Это стратегия, которую вы можете захотеть реализовать.

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

В настоящее время наставничество осуществляется одним человеком, в основном во время и сразу после утренних разборок (с 8:30 до 9:15, вместе взятых), а во второй половине дня с 12 до 3:30 (он работает с 7:00 до 3:30. вечера).

Я рад, что вы упомянули закон Брука. Красиво сделано. Основная проблема с добавлением другого разработчика - это накладные расходы на их ускорение и накладные расходы на синхронизацию с ними информации о том, где вы находитесь в проекте. Поэтому, если вы решите получить третьего разработчика, я бы попробовал это:

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

Если вы строго следуете закону Брука, вы, скорее всего, никогда не увеличите свою команду.

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

В твоем случае? Я бы порекомендовал новому человеку написать все эти недостающие юнит-тесты.

1. Это крайне необходимо в качестве защиты от ошибок регрессии, которые сожгут вас быстрее, чем любое замедление Брукса.
2. Новый человек будет изучать внутренности вашей системы. Это что-то вроде испытания в огне - но их вывод не входит в производственный код, так что там небольшой риск.
3. Установите жесткое ограничение на количество времени, которое могут занять другие члены команды. Например, пусть они ставят в очередь вопросы и позволяют общаться с другими членами команды только 30 минут в день, пока не будет соблюден конечный срок.

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

Эд Йедон отлично прокомментировал закон Брука. Он сказал: конечно, добавление людей заставит вас идти медленнее - но когда проект находится в опасности, единственное управление временем привлечет новых людей. Итак: возьмите их, сведите к минимуму влияние на текущую версию и избавьтесь от плохих исполнителей, как только сможете. Таким образом, со временем вы сможете построить сильную команду.

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

Вы говорите, что вам нужно выполнить 25% оригинальной работы, плюс новую работу. И вам нужно сделать это за два месяца - когда вам потребовалось 18 месяцев, чтобы выполнить 75% работы. Чтобы быть очень грубым, это указывает на то, что ваши способности оценивания являются средними для программиста, ориентированного на код, то есть, вы думаете, что на это у вас уйдет примерно половина или треть, пока они действительно это делают.

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

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

Моя рекомендация:

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

Редактировать Только что видел дату здесь. Так как же это закончилось? (Спасибо Ars Technica за размещение трехмесячного вопроса;)

Есть несколько способов, которые я хотел бы рассмотреть:

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

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

Дата уже прошла, но для тех, кто читает это позже.

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

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

Если они не хотят договариваться о снижении объема, то вы можете потерпеть неудачу.

Нет шансов полностью реализовать этот проект в установленные сроки. Если вы думаете, что у вас осталось 25% на проекте, который занял 18 месяцев, то у вас осталось как минимум 6 месяцев (из ~ 2 разработчиков). Добавление другого человека не изменит это значительно.

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

Я надеюсь, что это сработало для вас.