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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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