it-swarm-ru.tech

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

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

185
Ed Guiness

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

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

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

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

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

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

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

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

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

87
Zach Burlingame

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

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

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

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

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

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

29
Lasse Vågsæther Karlsen

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

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

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

17
Lost in Alabama

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

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

Кроме того, как вы, очевидно, знали, когда писали свой вопрос, совет из "Мифического человека" относится только к поздним проектам. Если ваш проект еще не опоздал, вполне возможно, что добавление людей не сделает это позже. Если вы делаете это правильно, конечно.

11
apenwarr

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

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

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

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

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

4
JXG

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

4
Daniel

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

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

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

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

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

3
Giovanni Galbo

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

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

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

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

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

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

2
Tom Ritter

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

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

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

2
Matthew Cole

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

2
Oskar

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

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

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

1
Caleb

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

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

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

1
Bill Michell