Поможет ли новичкам выделять отдельный подпроект от опытных разработчиков быстрее новичков?

У нас в команде 7 разработчиков, и нам необходимо удвоить скорость разработки за короткий период времени (около месяца). Я знаю, что есть правило здравого смысла, что «если вы нанимаете больше разработчиков, вы теряете производительность только в течение первых нескольких месяцев». Проект представляет собой веб-сервис электронной коммерции и содержит около 270 тыс. Строк кода.

Моя идея сейчас состоит в том, чтобы разделить проект на два более или менее независимых подпроекта и позволить новой команде работать над меньшим из двух подпроектов, в то время как текущая команда работает над основным проектом. А именно, новая команда будет работать над функциональностью оформления заказа, которая в конечном итоге станет независимым веб-сервисом для уменьшения связи. Таким образом, новая команда работает над проектами только с 100K строк кода.

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

=======

ОБНОВИТЬ

Это предприятие полностью провалилось, но не по причинам, которые вы, ребята, упомянули. Прежде всего, меня дезинформировали о размере и возможностях новой команды. Я должен был оценить их сам. Во-вторых, найм на этом месте оказался тяжелой работой. На месте главного офиса найма было намного проще, но в городе второй команды явно не хватало разработчиков с необходимой квалификацией. В результате вместо запланированных 1,5 месяцев работа была продлена примерно до 4,5 месяцев и была в середине ее отменена высшим руководством.

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

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

Хотя я согласен, как и все здесь, что:

«... добавление новых разработчиков в отложенный проект, создание проекта, задержка более ...»

У меня такое чувство, что ты собираешься сделать это где угодно, так что ...

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

То, что вы можете попробовать, это дать им небольшие кусочки / модули / формы / классы вашего проекта для работы вместо всего проекта.

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

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

Есть ли у вас документация по применению, например: UML, ER, Codd-Yourdon, что угодно?

Удачи.

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

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

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

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

• Как я уже говорил выше, нанимайте людей, которые имеют опыт создания системы, которую вы хотите.

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

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

• У вас есть четко определенный процесс разработки? Ошибка базы данных? Контроль версий? Процесс проверки кода? Гид по стилю? Получить эти вещи на месте.

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

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

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

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

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

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

Итак, вы пытаетесь стать командой, которая не станет жертвой Мифического Месяца Человека . У вас будет несколько проблем, кто-то из команды должен будет провести технические собеседования, а затем вам придется подождать несколько недель после того, как они примут позицию, прежде чем они смогут начать. Это может быть два месяца, прежде чем новые разработчики перед своими клавиатурами.

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

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

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

В своем комментарии к Alex D вы упомянули: «Это не крайние сроки, которых мы придерживаемся, это демонстрируемая способность предоставлять новые функции». Так что переключайтесь на стиль разработки, который распределяет функции по частям и чаще. Пусть новые члены команды протестируют новые функции, которые помогут им понять кодовую базу.

Вам лучше не нанимать никого нового и смотреть на свои процессы, чтобы увидеть, где можно внести изменения, чтобы ускорить процесс. Чем раньше будут обнаружены ошибки, тем меньше времени потребуется, чтобы их исправить, так как вы тестируете? Вы делаете обзоры кода? Обращаете ли вы внимание на качество требования? Есть ли у вас автоматизированные процессы сборки и развертывания? У вас есть автоматизированные тесты? Проводите ли вы ежедневные встречи в режиме ожидания (Удивительно, насколько быстрее может идти разработка, когда кто-то каждый день будет просить вас о вашем прогрессе!)? Вы используете гибкие процессы? Есть ли у вас какие-то основные недостатки в дизайне, которые нужно устранить, чтобы ускорить остальную часть разработки (плохой дизайн может невероятно замедлить проект разработки).

Пожалуйста, прочитайте Мифический Человек-месяц. Вам, безусловно, понадобится, чтобы рассказать старшему руководству, почему они делают выбор в пользу ускорения проекта. ,

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