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

Question

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

На самом деле параллельно будут работать два разработчика. Каким фактором было бы разумно уменьшить оценку? (Я понимаю, что это не будет 0,5)

Answer 1

В зависимости от первоначального разработчика и нового разработчика, вы можете сократить эти 25 недель на целых 75% (нет, я не шучу) или увеличить на 50% (опять же, не шучу) ). На самом деле разница между отдельными разработчиками огромна . Разработчики с предполагаемым подобным уровнем квалификации показали, что изменяется на порядок .

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

Вообще говоря, при прочих равных условиях вы потеряете время на вопросы общения, и я бы, вероятно, сказал, что это примерно 20% при переходе от одного к более чем одному.

Answer 2

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

Answer 3

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

Имейте в виду, оно может даже не быть сокращено вообще .

Answer 4

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

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

Таким образом, у вас есть оценка, основанная на вкладе разработчиков, которые фактически собираются создать код, а не только одного из них.

Answer 5

Со всеми обычными предостережениями (по-настоящему оценить это невозможно, часто добавляя разработчиков добавляет время и т. Д. И т. Д.). Предполагая, что дополнительный разработчик имеет такой же уровень способностей, обладает сопоставимым набором навыков и опытом работы с платформами / технологиями, как и я, я обычно оцениваю снижение на 20% для добавления дополнительного разработчика; дополнительная скидка 5% для добавления третьего. Никаких сокращений после этого.

Answer 6

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

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

Answer 7

Это зависит не только от разработчика - как было сказано выше, но и от работы. Может ли проект быть достаточно подразделенным, есть ли какие-либо внешние факторы, которые будут влиять на развитие любого разработчика (ole 'вы не можете добавить еще 2 женщин, чтобы иметь ребенка через 3 месяца вместо 9 месяцев). Я бы определил, можно ли эффективно разделить работу (разделенные области), понять уровень другого программиста (кого-то нового? Или кого-то, кого вы уже имеете в виду) и создать оценку с любыми необходимыми предположениями (такими как сторонние интерфейсы, ожидаемые изменения и т. д.)

Answer 8

Я бы разделил оценку на 2:

• Получить настройки, узнать проект
• Сделай работу

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

Добавление разработчика обойдется вам в дополнительные 2 недели в проекте.

Кроме того, необходимо учитывать стоимость координации между разработчиком. Один из способов оценить это - сказать, что каждый разработчик должен разговаривать друг с другом 5 минут в день. В вашем случае это добавит дополнительные 10 минут усилий в день.

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

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

Answer 9

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

Answer 10

Это, вероятно, не произойдет, по крайней мере, если доставка должна быть произведена менее чем за 3 месяца.

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

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

Последний месяц, который они, вероятно, возместят за то, что они повредили в первый месяц.

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

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

Вещи, которые будут определять точное воздействие, будут:

1) технические навыки
2) знание предметной области
3) знания, относящиеся к конкретному проекту
4) размер всей команды, в частности, сколько дополнительных людей вы добавляете в процентах

Вы хотите, чтобы первые три были высокими, а последний - таким, чтобы пропорционально команда не менялась слишком сильно. Добавьте одного человека в команду из 10 человек, и влияние будет управляемым. Создайте команду из 5 человек в команду из 10 человек, и вы, вероятно, облажались на 3 - 6 месяцев.

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