Как оценить продолжительность непредвиденных задач?

Question

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

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

Answer 1

Ключ - исторические данные.

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

Пример: предположим, что это данные за последние 10 раз, когда вам нужно было сделать текстовое обновление веб-страницы:

time     note
10m
10m
1.5h     got pulled away to fix a production bug
10m
45m      server offline due to upgrade
10m
10m
4h       entire staff evacuated due to bomb scare
10m
10m

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

Этот подход также должен помочь учесть непредвиденные элементы, которые являются частью задачи - для написания кода требуется всего 10 минут, а для развертывания - 15 минут, потому что вам нужно отправить его по FTP, а затем выполнить rsync и т. д. Опять же, это проявится в исторических данных.

Answer 2

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

Таким образом, вместо того, чтобы сказать «120 дней», скажите «4 месяца» (или «полгода»).

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

Answer 3

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

Я склонен использовать этот метод, хотя: http://www.joelonsoftware.com/articles/fog0000000245.html

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

Answer 4

Если у вас постоянно возникают непредвиденные задачи, вы можете приблизительно определить время, когда вы работаете с ними, и добавить его в качестве буфера для определения даты окончания (не трудозатраты для проекта, поскольку непредвиденные задачи звучат так, как будто они связаны с. другие проекты). Там были исследования, которые показывают в среднем. Программист на 60% продуктивен в назначенном проекте, поэтому буферизация 30% -40% может показаться высокой (или нет), но будет хорошей отправной точкой.

Answer 5

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

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

Answer 6

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