Насколько вы должны оценивать свои задачи?

Question

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

это как 0,5, 1, 2, 5 дней, или вам нужно спуститься до часов, как 0,5, 1, 2, 4 часа, а затем продолжить до нескольких дней?

Должно ли изменение текста метки быть задачей вообще? (ETA < 1 мин)

Предложения?

Answer 1

Scrum использует значения 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40 и 100. Время значений указано в часах, когда вы планируете более подробно (отлаживать запросы функций в технические билеты) и дни, когда вы планируете увеличить картинку (функции большой картинки).

В целом, если вы оцениваете билет на 20 часов (или 20 дней), ваши задачи должны быть разделены на более мелкие части.

Answer 2

Ну, это действительно зависит. Лично мне нравятся задачи меньшие (следует оценивать в часах, обычно используя что-то близкое к серии Фибоначчи: 0,5, 1, 2, 3, 5, 8, ...).

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

Answer 3

Действительно сложно предсказать, будущее.

Единицы (минуты, часы, дни, недели, крепости) не имеют значения.

Выберите устройство, которое сделает ваш менеджер счастливым.

Просто убедитесь, что оценка 30 минут, 0,5 часа или 0,625 дней - это только предположение, а не факт.

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

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

Answer 4

Я думаю, это зависит от того, насколько вы точны быть точным.

Я лично использую минуты, поскольку «дни» или «месяцы» могут вводить в заблуждение периоды времени. Например, если вы скажете, что что-то займет 1 день - значит ли это 24 часа солидной работы? Или 8 часов? Или в среднем за 3-4 часа производительности в течение рабочего дня?

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

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

Answer 5

Я нашел себя сортировку задач по следующим категориям:

• Полдня
• Целый день
• Всего неделю
• Несколько недель

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

Answer 6

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

Правильное использование: разделите задачу на более мелкие куски, пока не узнаете точно что вы должны делать дальше (и это не планируется). Это «знание точно, что делать» вещь немного субъективно, но задачи дольше, чем 2 дня, редко вписываются в эту категорию.

Answer 7

Я стараюсь использовать единицы часов, если они подходят (1 час, 4,5 часа, 6 часов и т. Д.). После того, как дни ползут в уравнение, я стараюсь не использовать часы и держать дни в качестве единственного используемого устройства (3d, 7d, 10d). Переоценка немного дает место для размещения этих нежелательных, но ожидаемых осложнений, которые вы ударите по пути.

Answer 8

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

Вы никогда не сможете предсказать будущее, и это не так. Это вероятность того, что вероятность предсказать 1 неделю с шагом в 1/2 часа не так уж велика, а если первые 6 задач взять 5 мин. больше для завершения, вы 1/2 (после 3 часов работы).

Я бы предложил создать структуру разбивки работ (WBS), чтобы определить усилие, а затем сгруппировать задания не менее, чем в однодневные группировки и не более, чем недельные группировки (в зависимости от общей продолжительности проекта - вы никогда не захотите прирост, составляющий более 2-3% общей работы). Это позволит программам переключаться между задачами (нормальные условия работы) без давления, необходимого для удовлетворения определенной 1/2-часовой доставки.