Мне нужен этот ребенок через месяц - пришли мне девять женщин!

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

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

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

Есть ряд вещей, которые я считаю необходимыми , но не достаточными, чтобы это произошло (в произвольном порядке):

• Предложенные лица для добавления в проект должны иметь:
  • Как минимум разумное понимание предметной области проекта
  • Быть опытным в языке проекта и конкретных технологиях, которые они будут использовать для задач, которые им будут даны
  • Их уровень должен / не должен быть намного меньше или намного больше, чем у самого слабого или самого сильного существующего члена соответственно. Слабые участники истощают ваш существующий персонал из-за третичных проблем, в то время как новый человек, который слишком силен, нарушит команду тем, что все, что они сделали и делают, неправильно.
  • Иметь хорошие навыки общения
  • Быть мотивированным (например, уметь работать самостоятельно, не подталкивая)
• Существующие члены команды должны иметь:
  • Отличные коммуникативные навыки
  • Отличные навыки управления временем
• Руководитель проекта / руководство должны иметь:
  • Хорошие возможности приоритизации и распределения ресурсов
  • Высокий уровень уважения со стороны существующих членов команды
  • Отличные коммуникативные навыки
• Проект должен иметь:
  • Хорошая, законченная и задокументированная спецификация разработки программного обеспечения
  • Хорошая документация уже реализованных вещей
  • Модульная конструкция, позволяющая распределять четкие фрагменты ответственности
  • Достаточные автоматизированные процессы для обеспечения качества для требуемого уровня дефекта. К ним могут относиться такие вещи, как: модульные тесты, регрессионные тесты, автоматическое развертывание сборки и т. Д.)
  • Система отслеживания ошибок / функций, которая в настоящее время используется и используется командой (например, trac, SourceForge, FogBugz и т. Д.).

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

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

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

• Опоздали, прежде чем начать (больше вещей, чем времени) и / или
• поскользнулся 1 час, 1 день вовремя.

Надеюсь, это поможет!

Это помогает, только если у вас есть ресурсный проект.

Например, рассмотрим это:

Вам нужно нарисовать большой плакат, скажем, 4 на 6 метров. Такой большой плакат, вы, вероятно, можете поставить перед ним двух или трех человек, чтобы они рисовали параллельно. Однако размещение 20 человек перед ним не сработает. Кроме того, вам понадобятся опытные люди, если вы не хотите дерьмовый плакат.

Однако, если ваш проект состоит в том, чтобы заполнить конверты готовыми печатными буквами (как вы МОЖЕТЕ победить! ), То чем больше людей вы добавите, тем быстрее он пойдет. В распределении стеков работы есть некоторые накладные расходы, поэтому вы не можете получать пособия вплоть до того момента, когда у вас будет один человек. конверт, но вы можете получить выгоду от гораздо больше, чем просто 2 или 3 человека.

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

К сожалению, в нашем мире не так много проектов, поэтому совет docgnome о книге «Мифический человеко-месяц» - действительно хороший совет.

Возможно, если применяются следующие условия:

1. Новые программисты уже понимают проект и не нуждаются во времени для его запуска.
2. Новые программисты уже владеют средой разработки.
3. Административное время не требуется, чтобы добавить разработчиков в команду.
4. Почти не требуется общение между членами команды.

Я дам вам знать, когда впервые увижу все это сразу.

Согласно «Мифическому человеку-месяцу», главная причина, по которой добавление людей в поздний проект делает его более поздним, - это O (n ^ 2) коммуникационные издержки.

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

Кроме того, как вы, очевидно, знали, когда публиковали свой вопрос, совет из Mythical Man-Month относится только к поздним проектам. Если ваш проект еще не опоздал, вполне возможно, что добавление людей не сделает это позже. При условии, что вы делаете это правильно, конечно.

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

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

В основном ссылки на «Мифический человеко-месяц» верны, за исключением искусственных случаев, подобных тому, который я придумал. Г-н Брукс провел тщательное исследование, чтобы продемонстрировать, что после определенного момента затраты на сетевые и коммуникационные возможности, связанные с добавлением новых программистов в проект, перевесят любые выгоды, которые вы получите от их производительности.

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

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

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

Очевидно, что каждый проект индивидуален, но большинство рабочих мест разработки могут быть обеспечены определенным количеством сотрудничества между разработчиками. В этом случае мой опыт показывает, что свежие ресурсы могут фактически непреднамеренно замедлять людей, на которых они рассчитывают, чтобы привести их в движение, и в некоторых случаях это могут быть ваши ключевые люди (между прочим, обычно это «ключевые» люди, которые берут время воспитывать новичка). Когда они находятся до скорости, нет никаких гарантий того, что их работа будет вписываться в установленные «правила» или «культуру труда» с остальной частью команды. Опять же, это может принести больше вреда, чем пользы. Таким образом, в стороне, это обстоятельства, когда это может быть выгодно:

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

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

3) Другие члены команды очень терпеливы.

Я полагаю, что добавление людей к концу работы может ускорить процесс, если:

1. Работу можно выполнять параллельно.

2. Сумма, сэкономленная добавленными ресурсами, превышает сумму времени, потраченного на то, чтобы люди, имеющие опыт работы с проектом, объясняли вещи тем, кто неопытен.

РЕДАКТИРОВАТЬ: я забыл упомянуть, такого рода вещи не случаются слишком часто. Обычно это довольно простые вещи, такие как административные экраны, которые делают простые CRUD для таблицы. В наши дни эти типы инструментов могут быть в основном автоматически сгенерированы в любом случае.

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

• Автономные модули, которые еще не запущены
• Отсутствие инструментов разработки, которые они могут интегрировать (например, автоматизированный менеджер сборки)

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

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

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

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

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

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

1. Насколько хорош ресурс при его подборе. Лучшие разработчики могут перейти на новый сайт и быть продуктивными, исправляя ошибки практически мгновенно и без особой помощи. Этот навык редок, но может быть изучен.
2. Разделимость задач. Они должны уметь работать с объектами и функциями, не отключая существующих разработчиков и не замедляя их.
3. Сложность проекта и доступная документация. Если это приложение ASP.Net с наилучшей практикой и распространенные хорошо документированные бизнес-сценарии, то хороший разработчик может сразу же застрять. Этот фактор больше, чем какой-либо, будет определять, сколько времени существующие ресурсы должны будут инвестировать в обучение и, следовательно, первоначальное негативное влияние новых ресурсов.
4. Количество оставшегося времени. Это тоже часто ошибочно оценивают. Часто логика заключается в том, что у нас осталось только x недель, а для того, чтобы кто-то набрал скорость, потребуется x + 1 неделя. На самом деле, проект срывается и на самом деле у него осталось две недели на разработку, и получение большего количества ресурсов раньше, чем позже, поможет.

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

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

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

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