버그 수정 시간 할당

Question

우리는 고객에게 우리가 가진 모든 버그에 대한 시간 추정을하도록 요청 받았습니다.

우리는 버그 수정을위한 정해진 일정을 가지고 있지만 시간을 할당했지만, 우리는 각 버그에 대한 시간 할당이 없습니다. 간단히 말해서, 우리는 버그의 우선 순위를 정하고 할당 된 시간에 가장 높은 우선 순위 버그가 고정되도록 보장했습니다.

나는 단순히 버그에 시간을 할당하는 팬이 아닙니다.

1. 일반적으로 부정확합니다. 수정하는 데 얼마나 걸리는지 알아내는 것은 매우 어렵습니다.
2. 시간 낭비.
3. 코드 품질에 영향을 미칩니다
4. 장기적으로 더 많은 버그를 만듭니다 (마감일까지 완료하려는 시도에서 특정 버그를 놓칠 수 있습니다).

버그 당 시간 수를 제공하고 싶지 않고 어떤 버그가 수정 될지에 대한 시간만을 제공하고 싶지 않은 곳 에서이 문제를 어떻게 해결해야합니까?

버그에 시간을 어떻게 할당합니까? 효과적입니까? 시간과 노력의 가치가 있습니까?

Answer 1

내가 줄 수있는 유일한 대답은 매우 보수적 인 것입니다. 시간이 얼마나 걸릴지 추측하고, 여러분의 추측은 4 개입니다. 그것을 당신의 견적으로 사용하십시오. 당신이 말했듯이, 해결하는 데 시간이 얼마나 걸리는지 알아내는 것은 매우 어렵고, 당신이 충분히 보수적이지 않았기 때문에 실제로 "마감일을 끊는 것"보다는 실제보다 오래 걸릴 것이라고 말하는 것이 낫습니다.

Answer 2

내가 일하는 회사는 종종 고객으로부터 불합리한 요청을받습니다. 기억해야 할 중요한 점은 고객이 잘 알고 싶어한다는 것입니다. 이를 수행하는 가장 좋은 방법은 상태 보고서 측면에서입니다.

그래서 우리는 먼저 우리의 입장을 설명하는 꽤 좋은 일을합니다. 예에서는 다음과 같은 것입니다.

우리는 프로젝트에서 버그를 고치기위한 정해진 일정을 가지고 있으며, 역사적으로 일정에 따라 머무르는 좋은 실적을 가지고 있습니다. 그러나 각 버그를 수정하는 데 걸리는 시간을 자세히 설명하는 과정은 상당히 오류가 발생합니다. 수정 된 버그와 테스트 된 수정 사항에 대한 주간 업데이트 (또는 고객에 따라 두 번 또는 매일)를 제공하게되어 기쁩니다.

그러나 나는 각 버그가 수정하는 데 걸리는 시간을 추정하는 것이 좋다고 생각합니다. 그 이유는 모든 버그가 취할 수있는 총 시간을 이해해야하기 때문입니다. 개별 부품이 수정하는 데 걸리는 시간에 대한 견적이 없다면 정확한 견적을 얻을 수 없습니다. 이것은 물론 대략적인 추정치가 될 수 있습니다 (문제를 연구하는 데 한 시간을 보내는 것보다 더 이상 추정되지 않음) - 너무 많은 시간을 낭비하고 싶지 않습니다. 그런 다음 일반적으로 추가 20%를 고려합니다. 따라서 버그에 대한 추정치는 3 일, 5 일 및 2 일이라고 가정하십시오. 그런 다음 고객에게 12 일 안에 버그를 고칠 수 있어야한다고보고했습니다. 물론 제품을 제공하기 전에 제품을 테스트하고 다시 포장하는 데 더 많은 시간을 추가해야 할 수도 있습니다.

Answer 3

버그가 얼마나 오래 걸리는지 추정하는 관점에서 생각하지 마십시오. 올바르게 추정 할 수 없기 때문입니다.

이것을 관점에서 생각하십시오 클라이언트 분노 관리. 당신이 그들에게 버그가 고칠 시간이 전혀 없을 것이라고 말하면, 그들은 3 개월이 걸리면, 당신의 의뢰인은 지금 당신과 함께 행복하고 미래에 당신과 분노 할 것입니다.

그들에게 버그를 고치는 데 3 개월이 걸릴 것이라고 말하면 실제로 고치는 데 실제로 3 개월이 걸리면, 고객은 지금 분노하고 미래에 당신과 만족할 것입니다.

나는 보통 버그가 전혀 시간이 걸리지 않을 것이라고 말합니다 (2-3 일은 좋은 진정 숫자 인 것 같습니다).

Answer 4

다른 작업을 추정하는 것과 동일해야합니다. 가능한 가장 작은 작업으로 나누고 예상치 못한 작업을 위해 가능한 한 정확하게 추정하십시오. 그런 다음 잘 정의되지 않은 작업의 특정 날짜에 고정되지 않도록 범위를 제공하십시오. 버그를 수정하는 시간 추정 시간과 성인 요구 사항이있는 기능을 구현하기위한 시간을 추정하는 데는 차이가 없습니다.

Answer 5

맞습니다. 추정치는 일반적으로 부정확합니다.

어쩌면 각 버그가 고정되지 않은 경우 각 버그 비용이 얼마인지 물어보고 싶을 수도 있습니다. 그런 다음 고정되어야하는지 파악하기위한 적절한 계산을 수행 할 수 있으며, 각 버그에 헌신 할 수있는 시간 (또는 현실적으로) 시간을 얼마나 많은 시간을 할애 할 수 있습니다.

Answer 6

버그 심각도, 예를 들어 1 시간, 1/2 일, 1 일, 1 주를 위해 여러 밴드를 선택하지 않겠습니까? 일반적으로 당신은 버그에 대한 느낌을 가질 것입니다. 당신이 모르는 사람들은 최악의 경우를 넣습니다!

나는 당신이 인용 한 이유 (조사하기에 너무 오래 걸리는 등)보다 더 미세한 수준에서 추정하고 싶지 않다고 생각합니다.

나는 그것이 시간 낭비라고 생각하지 않습니다. 고객은 버그 수와 우선 순위보다 더 많은 것을 알고 싶어합니다. 그들은 얼마나 많은 일이 남아 있는지에 대한 느낌을 원합니다.

어떠한 상황에서도 더 많은 버그를 생성하지 않아도됩니다. 시계에 대해 서두르지 않아야합니다. 하루를 추정하고 10 시간이 걸렸다면 괜찮습니다. 1 주를 추정하고 2 시간이 걸렸다면 좋은 결과!

이것은 단순히 추정 운동입니다!

Answer 7

일반적으로 특정 릴리스를 위해 어떤 버그가 수정되어야하는지 동의 한 다음 모든 버그를 수정하기위한 시간 프레임을 정의합니다. 각각의 개별 버그마다 고치는 데 걸리는 시간에는 많은 불확실성/변동이 있지만 더 많은 버그로 평균화하는 경향이 있습니다. 당신이 알고있는 특정 버그는 더 오래 걸릴 것입니다. 예를 들어 시뮬레이터 또는 테스트 프레임 워크를 작성 해야하는 경우 몇 가지 추정치를 제공 할 수 있습니다.

Answer 8

이것들이 발견되고보고 된 버그 인 경우, 시간에 추정치를 개발할 수 있어야합니다 (및 재시험 시간). 견적에 대한 신뢰는 추정치에 소비하는 시간에 비례 할 것입니다. 아마도이 비용을 고객에게 설명 할 수 있습니다.

관련 작은 버그 보고서가 여러 개 있다면 아마도 하나의 옴니버스 보고서로 무너질 수 있습니다. 이를 통해 클라이언트는 순전히 개별 추정치를 기반으로 수정할 버그를 선택하고 선택하지 않을 수 있습니다.