Сколько времени тратится на оценку задач программирования?

Например, если я разбиваю проект на n отдельных рабочих продуктов (скажем, классов, функций или компонентов), будет ли время t такое, что n * t - это подходящее количество времени, которое нужно потратить на оценку?

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

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

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

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

Как только вы сломали их, чтобы сделать это, вы сделали достаточно; независимо от того, что на самом деле эти вещи.

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

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

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

Прочти это и попробуй!

Также, как правило, ни одно задание в пользовательской истории не должно превышать 7,5 часов (один рабочий день). Если это так, вам нужно разбить задачу на более мелкие задачи.

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

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

Что вы получаете от своих оценок?

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

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

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

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

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

Хорошие оценки основаны на фактах, а не на предположениях.

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

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

• Люди, которые делают работу, должны участвовать в оценке проекта
• Привлечь экспертов: экспертное суждение имеет решающее значение для успеха проекта
• Оцените большие куски как диапазон
• Используйте Delphi Technique: это метод, который помогает сблизить мнения команды в случае конфликта в оценке проекта программного обеспечения.
• Имейте в виду стоимость
• Имейте в виду выделенные ресурсы, доступные для выполнения работы