Правильно ли основано планирование на основе фактических данных с разнородными оценками? - PullRequest
2 голосов
/ 19 ноября 2008

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

  • отдельные программисты, кажется, имеют любимые числа (например, 2,4,8,16,30 часа)
  • большие задачи кажутся недооцененными фиксированным значением (около 2), но стандартное отклонение здесь низкое
  • небольшие задачи (1 или 2 часа) абсолютно широко распространены. В среднем они имеют одинаковый средний коэффициент недооценки 2, но стандартное отклонение велико:
    • некоторые 5-минутные проблемы правописания оцениваются в 1 час
    • другие исправления также оцениваются как 1 час, но занимают день

Итак, действительно ли хорошая идея позволить программистам разбить задачу на 30 часов на 4 или 2 часа во время оценки? Не поднимет ли это стандартное отклонение? (Хорошо, пусть они разбивают его - но, возможно, после оценок?!)

Ответы [ 4 ]

6 голосов
/ 19 ноября 2008
  • Да, ваши наблюдения - это именно те проблемы, для решения которых EBS предназначена.
  • Да, важно разбивать большие задачи. Стреляйте в 1-2 дня, более или менее.
    • Если ваши вещи оцениваются менее чем за 2 часа, посмотрите, имеет ли смысл их группировать. (Возможно, нет - это нормально!)
    • Если у вас есть задачи, которые оцениваются в 3+ дня, посмотрите, есть ли способ разбить их на куски. Там должен быть. Если оценщик говорит, что нет, заставьте их защищать это утверждение. Если выясняется, что на самом деле задача занимает всего 3 дня, хорошо, но чем их больше, тем больше вы должны пристально смотреть в зеркало и видеть, не играют ли люди в систему.
    • Считайте 4 и 5-дневные оценки как 2x и 4x плохими, как 3-дневные. Любой, кто говорит, что что-то займет больше 5 дней, и это не может быть разбито, скажите им, что вы хотите, чтобы они потратили 4 часа на размышления о проблеме и о том, как ее можно решить. Помните, что это задача, кстати.
  • По мере того, как вы и ваша команда будете практиковаться в этом, вы будете лучше оценивать.
  • ... Вы также начнете распознавать паттерны неудач, и решения представят себя.
  • Смысл планирования Доказательства заключается в использовании Доказательства в качестве основы для вашего расписания, а не набора догадок с дикими оценками. Это Хорошая вещь ...!
1 голос
/ 19 ноября 2008

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

Поэтому убедитесь, что разработчики также знают, что они делают и говорят:)

0 голосов
/ 19 ноября 2008

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

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

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

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

Следовательно, всегда лучше их сломать. :)


Имитация Excel, которую я сделал:

  • создать 50 строк с этими столбцами:
    • первое - фиксированное значение 2 (очень однородная оценка)
    • 20 столбцов с некоторой случайной функцией (например, "= rand () * rand () * 20")
  • составляют суммы для каждого столбца
  • добавить "= VARIANCE (..)" для каждого случайного столбца
  • и добавить расчет отклонений для сумм

Дисперсия для каждого столбца в моем моделировании была около 2-3, а дисперсия сумм ниже 1.

0 голосов
/ 19 ноября 2008

"Итак, действительно ли это хорошая идея позволить программистам разбить 30-часовое задание на 4 или 2 часа во время оценок? Разве это не повысит стандартное отклонение? (Хорошо, пусть они разбивают его - а может после оценок?!) "

Я, конечно, вообще не понимаю этого вопроса.

Как это звучит, как вы говорите (вы не можете быть , говоря это, но это точно звучит так)

  1. Программисты вообще не могут оценить - числа всегда округляются до «магических» значений и выключаются в 2 раза.

  2. Я не могу доверять им как определять работу, так и оценивать время, необходимое для выполнения работы.

  3. Только я знаю правильную оценку времени, необходимого для выполнения задачи. Это не круглый день 1/2. Это точное количество минут.

Вот мои дополнительные вопросы:

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

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

...