Что лучше: настройте недооцененные или завышенные сроки?

Ответ 1

Вы должны использовать лучшее предположение, которое является функцией оценок min и max *, а не только простой средний -

best_guess = (min * min_weighting + max * max_weighting)/divisor *

* Том Нейланд предполагает, что это должно быть (min_weighting + max_weighting). На самом деле я не уверен, правильно ли это, но это, вероятно, более корректно, чем мой оригинальный делитель 2.0.

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

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

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

* Эти минимальные и макс-оценки будут получены различными способами - просят разработчиков, прошлый опыт и т.д. Если разработчики опроса тогда фактические значения min и max должны рассматриваться как выбросы и либо отброшены, либо изменены каким-то образом. То, что я имею в виду здесь, - это ценности, которые вы получаете от фраз типа "это займет 2 недели, если все пройдет хорошо или месяц, если мы ударим некоторые коряги". Таким образом, значения, которые вы вставляете в формулу, не необработанные числа.

Ответ 2

Не используйте ни минуты, ни макс, а что-то среднее между ними.

Лучше использовать Erring на стороне переоценки. В долгосрочной перспективе он имеет гораздо более выгодное поведение.

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

• Дополнительная стоимость неэффективности из-за синдрома студента ведет себя линейно.

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

В целом, я бы не тратил слишком много времени на отслеживание отдельных задач. С P50 целями половина из них будет в любом случае опаздывать. Самое главное, как ведет себя совокупность. При составлении оценок отдельных задач в совокупности ни минимальный, ни макс не являются разумными. Чрезвычайно маловероятно, чтобы либо все задачи выполнялись с минимальным временем (скорее всего, с периодом P10), так и с максимальным временем (например, время P90): для n задач P10/P90 вероятность равна 0.1 ^ n.

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

• Стив Макконнелл: Оценка программного обеспечения - Демистификация черного искусства. Это вполне читаемое и прагматичное, но по крайней мере первое издание, которое у меня есть, имеет некоторые причуды в его математике и в противном случае.

• Ричард Д. Штуцке: Оценка программно-интенсивных систем - проектов, продуктов и процессов. Это немного более академично, труднее читать, но, к примеру, объясняет математику лучше.

Ответ 3

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

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

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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

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

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

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

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

То, что только мое мнение о каждом и других может иметь иное отношение к нему, чем я.

Ответ 8

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

Немного сложнее:

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

Область под кривой слева от единственного числа, которое вы выбираете в качестве вашей оценки, представляет вероятность того, что вы успешно выполнили или до этой оценки. Так что, если вы дадите номер в левой руке, ваш шанс попасть в ноль, если вы дадите номер с правой стороны, ваш шанс будет на 100%.

Что менее обычно реализуется, если вы даете среднее значение (при условии, что ваш min и max усреднены, дайте что-то, приближающееся к фактическому значению), вы достигнете этого предельного срока в 50% случаев. Эффективно, если вы используете среднее значение, вы собираетесь пропустить крайний срок в течение половины времени. Я не знаю о вас, но мне не нравится, когда меня рассматривают как парня, который пропускает половину своих сроков.

Итак, вам нужно число, которое даст вам то, что вы нанесли, скажем, 90% времени. Удобно 95% представляет собой среднее значение + два стандартных отклонения, но если вы не можете справиться, чтобы вычислить это (и большинство из нас, вероятно, не имеют данных), мой опыт говорит, что:

(3 x max + 1 x min)/4

дает разумный результат.

Кстати, то, что вы говорите разработчику, это крайний срок, это еще один вопрос. Лично я бы дал ему где-нибудь ((2 x max + 1 x min)/3) и остальное как непредвиденное.

Ответ 9

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

В Agile/Scrum вы не устанавливаете жесткие сроки, а устанавливаете "сколько часов осталось на этой задаче". Каждый день вы обновляете оставшееся время. Вы не отслеживаете потраченные часы, но отслеживаете оставшиеся часы, и вы стараетесь оставаться честными.

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

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

Ответ 10

Для чего вы используете оценки? В частности, почему разработчик чувствует стресс, если вы обычно недооцениваете?

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

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

Ответ 11

Это зависит от проекта.

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

Некоторые проекты точно спланированы, и здесь вы можете использовать всю имеющуюся у вас аналитику: данные истории, некоторые показатели времени разработчика по подзадачам, вычисление рисков и т.д.

Но в любом случае время MAX не должно использоваться: его самая неточная мера, которая обычно приводит к еще большему времени. И вот простая причина: когда разработчик просто отдает это МАКС, он почти не измеряет. Он просто отдает свою интуицию, которая имеет очень мало информации в то время. Но если он проведет по крайней мере полчаса, он поймет специфику своих задач, он даже может разбить его на подзадачу и повысить свою точность. Таким образом, вы можете дать разработчику некоторые предубеждения, такие как "эй, ребята, просто подумайте, в какое время вы бы предоставили стабильный код здесь", но присылайте ему измерение. Это хорошо для работы, это хорошо для самого программиста.

Ответ 12

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

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

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