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

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

<p>точные обстоятельства, очевидно, очень специфичны для вашего проекта (например, команда разработчиков, стиль управления, зрелость процесса, сложность предмета и т.д.). для того, чтобы охватить это немного лучше, чтобы мы могли говорить об этом во всем, кроме чрезмерных упрощений, я повторю ваш вопрос:</p><blockquote> <p>при каких обстоятельствах, если таковые имеются, может ли добавление членов команды в проект разработки программного обеспечения, который запаздывает, привести к уменьшению фактической даты отгрузки с уровнем качества, равным таковому, если существующей команде было разрешено работать до завершения?</p> </blockquote><p>есть ряд вещей, которые я считаю <em> необходимыми </em>, но недостаточными для того, чтобы это произошло (в произвольном порядке):</p><ul> <li><strong>предлагаемые лица, которые будут добавлены в проект, должны иметь:</strong> <ul> <li>хотя бы разумное понимание предметной области проекта</li> <li>быть опытным в языке проекта и конкретных технологиях, которые они будут использовать для задач, которые им будут даны</li> <li>их уровень должен/не должен быть намного меньше или намного больше, чем у самого слабого или самого сильного существующего члена соответственно. слабые участники будут истощать ваш существующий персонал из-за третичных проблем, в то время как новый человек, который слишком силен, нарушит команду тем, что все, что они сделали и делают, неправильно.</li> <li>иметь хорошие навыки общения</li> <li>быть высоко мотивированным (например, уметь работать независимо, не подталкивая)</li> </ul> </li> <li><strong>существующие члены команды должны иметь:</strong> <ul> <li>прекрасные навыки общения</li> <li>отличные навыки управления временем</li> </ul> </li> <li><strong>руководитель проекта/руководство должны иметь:</strong> <ul> <li>хорошие возможности приоритизации и распределения ресурсов</li> <li>высокий уровень уважения со стороны существующих членов команды</li> <li>прекрасные навыки общения</li> </ul> </li> <li><strong>проект должен иметь:</strong> <ul> <li>хорошая, законченная и задокументированная спецификация разработки программного обеспечения</li> <li>хорошая документация уже реализованных вещей</li> <li>модульная конструкция, позволяющая распределять четкие фрагменты ответственности</li> <li>достаточные автоматизированные процессы для обеспечения качества для требуемого уровня дефекта. к ним могут относиться такие вещи, как: модульные тесты, регрессионные тесты, автоматическое развертывание сборки и т.д.)</li> <li>система отслеживания ошибок/функций, которая в настоящее время используется и используется командой (например, trac, sourceforge, fogbugz и т.д.).</li> </ul> </li> </ul><p>одна из первых вещей, которые следует обсудить, это то, может ли дата <em> поставки </em> быть пропущена, могут ли функции быть урезаны, и если некоторые комбинации этих двух вариантов позволят вам удовлетворить выпуск с ваши существующие сотрудники. много раз это пара функций, которые действительно затягивают ресурсы команды, которые не будут приносить ценность, равную инвестициям. поэтому, прежде чем что-либо еще, внимательно изучите приоритеты вашего проекта.</p><p>если результат вышеупомянутого параграфа не достаточен, то посетите список выше. если вы заметили, что график пропущен раньше времени, добавление правильных членов команды в нужное время может спасти релиз. к сожалению, чем ближе вы подходите к ожидаемой дате отправки, тем больше проблем может возникнуть с добавлением людей. в какой-то момент вы пересечете "точку невозврата", когда никакие изменения (кроме доставки текущей ветки разработки) не смогут сохранить ваш выпуск.</p><p>я мог бы продолжать и продолжать, но я думаю, что поразил главные моменты. вне проекта и с точки зрения вашей карьеры, будущего успеха компании и т.д. одна из вещей, которые вы обязательно должны сделать, это выяснить, почему вы опоздали, если что-то могло быть сделано, предупредить вас раньше, и какие меры вам нужны принять, чтобы предотвратить это в будущем. поздний проект обычно происходит потому, что вы были:</p><ul> <li>опоздали, прежде чем начать (больше вещей, чем времени) и/или</li> <li>поскользнулся 1 час, 1 день за раз.</li> </ul><p>надеюсь, это поможет!</p>

<p>это помогает, только если у вас есть ресурсный проект.</p><p>например, рассмотрим это:</p><p>вам нужно нарисовать большой плакат, скажем, 4 на 6 метров. такой большой плакат, вы, вероятно, можете поставить перед ним двух или трех человек и сделать так, чтобы они рисовали параллельно. однако разместить 20 человек перед ним не получится. кроме того, вам понадобятся опытные люди, если вы не хотите вый плакат.</p><p>однако, если ваш проект состоит в том, чтобы заполнять конверты готовыми печатными буквами (например, <em>вы можете победить!</em>), то чем больше людей вы добавите, тем быстрее он пойдет. при распределении стеков работы возникают некоторые накладные расходы, поэтому вы не можете получать пособия вплоть до того момента, когда у вас будет один человек. конверт, но вы можете получить выгоду от гораздо больше, чем просто 2 или 3 человека.</p><p>таким образом, если ваш проект можно легко разделить на небольшие куски, и если члены команды могут быстро набрать скорость (например ... мгновенно), то добавление большего количества людей заставит его работать быстрее, вплоть до определенного момента.</p><p>к сожалению, в нашем мире не так много проектов, поэтому совет docgnome о книге "мифический человеко-месяц" - действительно хороший совет.</p>

<p>возможно, если применяются следующие условия:</p><ol> <li>новые программисты уже разбираются в проекте и не нуждаются в ускорении.</li> <li>новые программисты уже владеют средой разработки.</li> <li>для добавления разработчиков в команду не требуется административного времени.</li> <li>почти не требуется общение между членами команды.</li> </ol><p>я дам вам знать, когда впервые увижу все это сразу.</p>

<p>согласно "мифическому человеку-месяцу", главная причина, по которой добавление людей в поздний проект делает его более поздним, - это o (n ^ 2) коммуникационные издержки.</p><p>я испытал одно первичное исключение из этого: если в проекте только <em>один</em> человек, он почти всегда обречен. добавление второго ускоряет его почти каждый раз. это потому, что общение не <em>накладные расходы</em> в этом случае - это полезная возможность прояснить ваши мысли и сделать меньше глупых ошибок.</p><p>кроме того, как вы, очевидно, знали, когда писали свой вопрос, совет из "мифического человека" относится только к <em>поздним</em> проектам. если ваш проект еще не опоздал, вполне возможно, что добавление людей не сделает это позже. если вы делаете это правильно, конечно.</p>

<p>если существующие программисты совершенно некомпетентны, то добавление компетентных программистов может помочь.</p><p>я могу представить ситуацию, когда у вас была очень модульная система, а у существующих программистов даже не было <em>запущено</em> в очень изолированном модуле. в этом случае может помочь назначение только этой части проекта новому программисту.</p><p>в основном ссылки на "мифический человеко-месяц" верны, за исключением искусственных случаев, подобных тому, который я придумал. г-н брукс провел тщательное исследование, чтобы продемонстрировать, что после определенного момента затраты на сетевые и коммуникационные возможности, связанные с добавлением новых программистов в проект, перевесят любые выгоды, которые вы получите от их производительности.</p>

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

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

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

<p>я полагаю, что добавление людей к концу работы может ускорить процесс, если:</p><ol> <li> <p>работу можно выполнять параллельно.</p> </li> <li> <p>сумма, сэкономленная добавленными ресурсами, превышает сумму времени, потраченного на то, чтобы люди, имеющие опыт работы с проектом, объясняли вещи тем, кто неопытен.</p> </li> </ol><p>правка: я забыл упомянуть, такого рода вещи не случаются слишком часто. обычно это довольно простые вещи, такие как административные экраны, которые делают простой crud для таблицы. в наши дни эти типы инструментов в большинстве случаев могут быть автоматически сгенерированы.</p><p>будьте осторожны с менеджерами, которые делают ставку на такую работу. звучит здорово, но на самом деле этого обычно не хватает, чтобы урезать какое-то значительное время от проекта.</p>

<p>очевидно, что каждый проект индивидуален, но большинство рабочих мест разработки могут быть обеспечены определенным количеством сотрудничества между разработчиками. в этом случае мой опыт показывает, что свежие ресурсы могут фактически непреднамеренно замедлять людей, на которых они рассчитывают, чтобы привести их в движение, и в некоторых случаях это могут быть ваши ключевые люди (между прочим, обычно это "ключевые" люди, которые берут время воспитывать новичка). когда они <em>имеют</em> скорость, нет никаких гарантий, что их работа будет соответствовать установленным "правилам" или "рабочей культуре" с остальной частью команды. опять же, это может принести больше вреда, чем пользы. так что, кроме этих обстоятельств, это может быть выгодно:</p><p>1) новый ресурс имеет сложную задачу, которая требует минимум взаимодействия с другими разработчиками и набор навыков, которые уже были продемонстрированы. (т.е. перенос существующего кода на новую платформу с внешним рефакторингом мертвого модуля, который в настоящее время заблокирован в существующей базе кода).</p><p>2) проект управляется таким образом, что время других более старших членов команды может быть использовано совместно, чтобы помочь новичку набрать скорость и наставлять его по пути, чтобы гарантировать, что их работа совместима с тем, что уже было сделано.</p><p>3) другие члены команды очень терпеливы.</p>

<ul> <li>автономные модули, которые еще не запущены</li> <li>отсутствие инструментов разработки, которые они могут интегрировать (например, автоматизированный менеджер сборки)</li> </ul><p>в первую очередь я думаю о вещах, которые позволяют им держаться подальше от современных людей. я согласен с mythical man-month, но я также думаю, что есть исключения из всего.</p>

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

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

<p>проще говоря. все сводится к сравнению оставшегося времени и производительности, которую вы получите от кого-либо, за исключением того времени, которое требуется дополнительным ресурсам для того, чтобы набрать скорость и быть продуктивным, и вычитая время, потраченное на обучение их существующим ресурсам. ключевые факторы (в порядке значимости):</p><ol> <li>насколько хорош ресурс при его подборе. лучшие разработчики могут перейти на новый сайт и продуктивно исправлять ошибки практически мгновенно, без особой помощи. этот навык редок, но может быть изучен.</li> <li>разделимость задач. они должны уметь работать с объектами и функциями, не отключая существующих разработчиков и не замедляя их.</li> <li>сложность проекта и доступная документация. если это приложение asp.net с наилучшей практикой vanilla и распространенные хорошо документированные бизнес-сценарии, то хороший разработчик может сразу же застрять. этот фактор больше, чем любой другой, будет определять, сколько времени должны потратить существующие ресурсы на обучение и, следовательно, первоначальное негативное влияние новых ресурсов.</li> <li>количество оставшегося времени. это тоже часто ошибочно оценивают. часто логика заключается в том, что у нас осталось только x недель, а для того, чтобы кто-то набрал скорость, потребуется x + 1 неделя. на самом деле проект is собирается сорваться, и на самом деле у него осталось 2x недели разработки, и получение большего количества ресурсов раньше, чем позже, поможет.</li> </ol>

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

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