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

185

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

Ed Guiness
источник
Я понимаю аналогию, которую вы пытаетесь провести, но все же, более описательный и менее шокирующий заголовок может быть хорошей идеей ...
Адриан Петреску,
заменить "пары" на "женщины"
просто Майк
Неважно, сколько мужчин вы добавите (если число не равно нулю), вам все равно нужно 9 женщин.
Windows программист
9
Это может работать, пока одна из женщин на восьмом месяце беременности.
Toon Krijthe

Ответы:

87

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

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

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

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

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

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

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

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

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

Zach Burlingame
источник
3
Хороший список. Однако я боюсь, что многие проекты опоздали именно потому, что в них нет всего, что вы перечислите ...
sleske
1
Просто легкомысленно, но если бы у команды были все эти функции, они, вероятно, не были бы позади в первую очередь :)
rtpHarry
29

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

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

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

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

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

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

Лассе В. Карлсен
источник
Я думаю, что программное обеспечение по своей сути не такой проект, поэтому, если вы не добавляете людей для работы не программистом (например, для создания изображений и перевода текста), вы можете с уверенностью сказать, что это НЕ ПОМОЖЕТ, с TMMM в качестве справки
Майк Стоун,
17

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

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

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

Затерянный в Алабаме
источник
1
фактически добавляя кого-то обратно в проект, который они оставили (достаточно недавний, чтобы они тоже ничего не забыли)
Майк Стоун,
1
«Я дам вам знать, когда я увижу все это сразу». Затаив дыхание !!!
Стю Томпсон
Мне нравится тот факт, что вы попытались обобщить условия для успешного добавления члена команды. Я думаю (2) и (3) ежу понятно. (1) возможно, только если вы переключаете их обратно на проект, в котором они уже были. (4) возможно только в том случае, если они являются существующим сотрудником, который переводится в проект с существующими отношениями с другими программистами (из предыдущих проектов).
Анонимный Тип
11

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

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

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

apenwarr
источник
10

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

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

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

оборота Джозеф Стайонс
источник
Не совсем ... все же есть затраты на изучение одной только кодовой базы ... и если они совершенно некомпетентны, проект, вероятно, все равно потерпит неудачу.
Майк Стоун
Я согласен с Майком Стоуном здесь. Кодовая база и архитектура могут быть ошибочными, 2-4 месяца на одного разработчика для серьезного проекта, всевозможные проблемы, связанные с техническим лидерством и т. Д.
Стю Томпсон
5
  • Если новые люди сосредоточены на тестировании
  • Если вы можете выделить независимые функции, которые не создают новых зависимостей
  • Если вы можете ортогонализировать некоторые аспекты проекта (особенно задачи, не связанные с кодированием, такие как визуальный дизайн / макет, настройка / индексирование базы данных или настройка сервера / конфигурация сети), чтобы один человек мог работать над этим, в то время как другие продолжают работу с кодом приложения.
  • Если люди знают друг друга, и технологии, и бизнес-требования, и дизайн, достаточно хорошо, чтобы иметь возможность делать вещи со знанием того, когда они наступят друг другу на ноги и как избежать этого (это, конечно, это довольно сложно организовать, если это не так)
Ли Колдуэлл
источник
4

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

Даниил
источник
4

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

JXG
источник
1
Хорошее предложение, и я думаю, что оно соответствует духу предложений в Мифическом Месяце Человека. ++
Эд Гиннес
3

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

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

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

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

screenglow
источник
3

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

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

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

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

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

оборота Джованни Гальбо
источник
И как часто это действительно так?
Стю Томпсон
2
  • Автономные модули, которые еще не запущены
  • Отсутствие инструментов разработки, которые они могут интегрировать (например, автоматизированный менеджер сборки)

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

Том Риттер
источник
2

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

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

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

Мэтью Коул
источник
2

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

Оскар
источник
На самом деле это довольно хороший ответ. В целом, если проект зависит от знаний ABC и D, а программисты в команде знают A и B, то добавление программистов, понимающих C и D, может ускорить завершение. Люди должны хорошо ладить, и в команде все еще есть ограничения на размер
программист Windows
1

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

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

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

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

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

Билл Мичелл
источник
То есть вы говорите, что это может быть полезно, а может и не быть?
Эд Гиннес
Более или менее. Я говорю, что общепринятая мудрость заключается в том, что добавление людей в поздний проект сделает это позже, но при некоторых ограниченных обстоятельствах, управляемых очень осторожно, вы можете получить некоторую полезную дополнительную работу от дополнительного человека.
Билл Мичелл
1

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

Калеб
источник