Почему добавление большего количества людей в поздний проект делает это позже?

25

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

project-management

— Генри
источник

14

Термин для этого - закон Брукса ( en.wikipedia.org/wiki/Brooks's_law ).

— Макнейл

7

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

— Дэвид Торнли

Эта страница Википедии очень хорошо написана.

— Генри

Для доказательства того, как производительность уменьшается с размером команды (более 7 членов команды уменьшают доходность), см. Qsm.com/process_improvement_01.html

— Джори Себрехтс,

33

Введение накладных

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

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

— Baelnorn
источник

Так что, если вы оптимизируете «Введение», то влияние будет меньше?

— Генри

9

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

— Baelnorn

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

— rwong

7

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

— TMN

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

— Дэвид Торнли

32

В дополнение к другим ответам: еще один фактор, который следует учитывать, это общение.

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

— Стивен Эверс
источник

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

— Мигель Велосо

+1. Согласитесь, это самая большая проблема при добавлении большего количества членов команды.

— Мартин Уикман

+1 для более долгосрочной проблемы с добавлением людей в проект.

— indyK1ng

23

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

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

Он упоминает обучение как часть проблемы:

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

... но отмечает, что общение является гораздо большим фактором:

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

Стоит также отметить, что у Фреда Брукса (автора) есть опыт, чтобы понять, о чем он говорит. Большая часть книги основана на его опыте управления проектом IBM OS / 360. Несмотря на десятилетия приверженцев проповедующих всякие «улучшенные» методы управления, а некоторые даже придумывают имена прохладных (экстремальные, Agile, Scrum, и т.д.) , когда вы садитесь на него, немного сущности ¹ , похоже, изменились с тех пор.

¹ Определение понятия «сущность» см. В статье «Нет серебряной пули: сущность и случайность в разработке программного обеспечения» того же автора, которая включена в издание «Мифический человеко-месяц », посвященное 20- ^й годовщине .

— Джерри Гроб
источник

12

Это не просто пословица; это поддается проверке. Проверьте Брукс « Мифический человеко-месяц» .

— Джон
источник

1

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

— Питер Боутон

3

У меня нет этой книги (очевидно). Это подкреплено жесткими цифрами или анекдотично?

— Генри

2

@ Генри: Прошло много времени с тех пор, как я его прочитал, но IIRC, оба присутствуют в достаточном количестве, чтобы окончательно осветить эту мысль.

— Стивен Эверс

@Peter: отредактировал мой ответ.

— Джон

@PeterBoughton Это изречение. Кроме того, это не просто пословица.

— SantiBailors

6

Вот некоторые мысли по этому вопросу ...

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

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

— aggietech
источник

1

+1 за добавление ресурсов в тестирование, а не разработку.

— Baelnorn

4

Потому что программирование не является основной работой производственной линии. Чтобы освоить программный проект, нужно время. Новым людям нужно задавать много вопросов, которые приводят к отрицательной продуктивности (т. Е. Обучение нового человека, его обучение старому человеку -> фактическая работа не выполняется).

Чтобы упростить его, представьте себе относительно простой проект с одним человеком, который запланирован на 1 неделю: в четверг вы понимаете, что он не будет выполнен вовремя, что вместо этого одному программисту потребуется больше, как 6-7 дней из 5. Если вы добавите другого программиста в этот момент, им нужно будет поработать с программистом1, по крайней мере, несколько часов или день или около того, задать много вопросов, чтобы набрать скорость и т. д. Вы, вероятно, не получите любая чистая положительная производительность для остальной части недели. Новый программист, вероятно, также внесет некоторые дополнительные ошибки (так как они не будут знать существующий код так же, как и programmer1), так что это разрушит цикл внедрения и тестирования еще на один или два дня. Проект легко продлится целых две рабочие недели вместо оригинальной!

— Бобби Столы
источник

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

— n1ckp

@ n1ck Это обобщение - например, «слишком много поваров» - ключевой момент заключается в том, что простое использование рабочей силы для проекта не обязательно приведет к тому, что оно будет решено быстрее. 1 человек на 2? Наверное, будет. От 2 до 4? Слишком много переменных - это зависит от размера и структуры проекта. 4 -> 8? Определенно становится маргинальным (по крайней мере, с точки зрения рентабельности).

— Murph

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

— n1ckp

Хорошо, пример мог бы быть лучше, но обобщение все еще верно?

— Murph

1

Я прошел через это достаточно раз, чтобы знать, что это МОЖЕТ работать в очень специализированных случаях, но в 99% случаев это не так. Неважно, насколько хорошо это выглядит в теории в то время. Тем не менее, да, это не черно-белый абсолют. Это больше похоже на то, что открытые отношения не работают. Теория хороша и заманчива;) .... но природа зверя такова, что в большинстве случаев она заканчивается неудачей. Вроде «исключения подтверждают правило».

— Бобби Столы

4

Фред Брукс написал целую книгу «Мифический человеко-месяц», отвечая на этот вопрос.

Вот быстрая и грязная версия:

1) Существует ограничение на то, сколько вы можете разбить проект на отдельные части, чтобы назначить большее количество программистов.

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

3) Для каждого человека, которого вы добавляете в проект, вы добавляете более одного канала связи, по которому нужно перейти в команду. Это число растет геометрически и увеличивает количество общения, которое должно произойти. Больше общения = больше работы.

4) При добавлении каждого члена команды появляется «J-кривая». То есть существующие производственные ресурсы должны тратить время на то, чтобы новые люди работали быстрее, чем они могли бы потратить на работу над проектом. В конечном итоге вы можете увеличить мощность, но это временно замедляет проект. Чем позже в проекте, тем больше нужно усвоить, тем сильнее эффект.

— JohnFx
источник

4

Еще один фактор, о котором я не упомянул, это то, что некоторые задачи нужно выполнять в определенном порядке. Вы не можете выполнить задачу 4, пока задача 3 не будет выполнена, потому что она зависит от 3. Бесполезно нанимать кого-то для выполнения задачи 4, в то время как кто-то выполняет задачу 3. Часто в конце проекта те задачи, которые сначала требуют выполнения других задач, являются оставшимися задачами.

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

— HLGEM
источник

+1. Это было главной проблемой на моей последней работе. Менеджмент был в мегаполисе «добавление человеко-месяца» для большого проекта, не продумав вещи до конца. В какой-то момент наша команда была обучена медлительности, потому что наши вещи должны были интегрироваться с этим крупным проектом. Но потом, новые сотрудники в крупном проекте не смогли набрать достаточную скорость, поэтому МЫ слишком далеко продвинулись (по материалам, которые требовали завершения их бэкэндов). В какой-то момент мы разрабатывали внешние интерфейсы для полуобжаренных бэкэндов и тестовых комплектов. Не хороший поток.

— Бобби Столы

2

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

— повторный показ
источник

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

— n1ckp

1

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

— перезапуск

2

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

— Дэвид Торнли

@rerun: проблема с вашей аналогией в том, что у беременных женщин нет аналогии с работниками. Женщинам в вашем случае было бы легче сравнивать с компанией , а не с рабочими. Вот почему это так много, на мой взгляд. Самым близким, что я могу придумать, была бы еда, но это было бы больше похоже на строку кодов, так что нет, не рабочие.

— n1ckp

1

@ n1ck: У меня сложилось впечатление, что вы не согласны, потому что вы не понимаете, если честно. Брукс не говорил о замене бесполезных людей компетентными людьми, потому что он был в ситуации, когда все, кто все еще работал, считались компетентными.

— Дэвид Торнли

2

Я бы также предложил "Peopleware" от DeMarco и Lister.

И «Крайний срок» от DeMarco представляет это, а также ряд других болезней и заблуждений, связанных с управлением проектами программного обеспечения, в легкомысленном и очень читабельном виде.

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

Эти книги довольно дешевые, я бы посоветовал вам их приобрести (есть у Amazon или The Book Depositary) и почитать. Короткие ответы здесь не могут действительно отдать должное заданному вопросу.

— quickly_now
источник

2

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

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

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

Вы когда-нибудь тестировали документацию и спецификации своего проекта, показывая их разработчику другого проекта? Они смотрели на это и решили, что могут начать работу над проектом, если это необходимо?

Насколько актуален какой-либо график проекта?

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

— JeffO
источник

1

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

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

— Пол Д. Уэйт
источник

0

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

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

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

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

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

Не торопитесь :-).

— Мартин Маат
источник