Исправление Ошибок Распределение Времени

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

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

Я не поклонник выделения времени на ошибки, просто потому, что:

  1. обычно это неточный. Очень трудно понять, сколько времени это займет.
  2. трата времени.
  3. влияет на качество кода
  4. создает больше ошибок в долгосрочной перспективе (мы можем пропустить некоторые вещи в нашей попытке завершить его в срок).

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

Как вы выделяете время на свои ошибки? Это эффективно? Стоит времени и усилий?

8 ответов


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


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

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

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

тем не менее, я считаю, что это хорошо, чтобы попытаться оценить, как долго каждая ошибка займет исправить. Причина этого в том, что вам нужно понять, что общее время исправить все жуки возьмут. Вы не сможете получить точную оценку, если у вас нет оценки того, сколько времени потребуется для исправления отдельных деталей. Конечно, это могут быть приблизительные оценки (не более часа на исследование проблемы) - вы не хотите тратить слишком много времени на оценку. Тогда я обычно учитываю дополнительные 20%. Так сказать, оценки ошибок составляют 3 дня, 5 дней и 2 дня. Затем я сообщу клиенту, что мы сможем исправить ошибки за 12 дней. Тогда, конечно, вам может потребоваться больше времени для тестирования и повторной упаковки вашего продукта, прежде чем вы сможете дать им результат.


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

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

Если вы скажете им, что ошибки займут 3 месяца, чтобы исправить, и они на самом деле занимают 3 месяца, чтобы исправить (что они будут), ваш клиент будет в ярости сейчас и счастлив с вами в будущем.

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


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


вы правы, оценки обычно неточны.

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


Почему бы просто не выбрать несколько полос для серьезности ошибки, например, 1 час, 1/2 дня, 1 день, 1 неделю и назначить против них. Как правило, у вас будет чувство ошибки-те, для которых вы понятия не имеете, поставьте худшую цифру!

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

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

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

Это просто упражнение в оценке!


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


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

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