Подтвердить что ты не робот

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

  • Вы опоздали до того, как начали (подробнее чем время) и/или
  • поскользнулся 1 час, 1 день в момент времени.

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

Ответ 2

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

Например, рассмотрим следующее:

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

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

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

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

Ответ 3

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

  • Новые программисты уже понимают проект и не нуждаются в сроках разгона.
  • Новые программисты уже владеют средой разработки.
  • Для добавления разработчиков в команду не требуется административное время.
  • Между членами команды практически не требуется общение.

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

Ответ 4

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

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

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

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

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

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

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

Ответ 10

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

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

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

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

Ответ 11

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

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

Ответ 12

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

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

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

Ответ 13

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

Ответ 14

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

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

Ответ 15

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

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

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

Ответ 16

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