버그 수정에 약간의 이점이 있습니까?

이전 동료로부터 버그의 우선 순위 목록을 내려 가면 버그가 더 모호해 지거나 고객 만족도가 낮아지는 유스 케이스 때문에 모든 버그를 수정해야하는 것은 아니라고 들었습니다. 그러나 여전히 그 버그를 고치는 데 상당한 시간을 소비해야합니다.

이 개념에 대해 제품 소유자를 설득하기 위해 좋은 리소스를 찾을 수 없었습니다. 소프트웨어 개발에 한계 비용이 있는지 없는지에 대한 토론 만 찾을 수있었습니다.

버그 수정에 실질적인 이점이 있습니까? 이 개념을 설명하는 다른 용어가 있습니까?

비즈니스 관점에서 버그 수정은 기능 요청과 다르지 않습니다. 개발 시간에는 일정한 비용이 들며 고객에게는 일정한 가치가 있습니다. 치명적이지 않은 버그 인 경우 버그 수정보다 중요한 기능의 우선 순위를 정하는 것이 전적으로 의미가 있습니다.

그러나 기술적 인 관점에서, 버그 는 다른 코드가 사용 / 빌드 할 수있는 기초에 오류가 있음을 나타내므로 더 중요 할 수 있습니다.이 경우 오류는 "전염성"이며 향후 유지 관리에 비용이 추가됩니다. 그래서 없는 버그를 수정하는 것은입니다 기술 부채 동안 관리가 필요 하지 정말 지속적으로 비용이없는 기능을 구현. 그러나 버그로 인해 발생하는 기술 부채 수준은 버그의 특성에 따라 다릅니다.

우선 순위를 정할 때 이러한 모든 요소를 ​​고려해야합니다.

버그 수정에 약간의 이점이 있는지 여부는 다음과 같습니다. 모든 버그의 심각도는 같지 않기 때문에 가장 중요한 버그의 우선 순위를 자연스럽게 정해야합니다. 따라서 더 많은 버그를 수정하면 다음 수정의 한계 값이 낮아집니다. 그러나 버그를 고치는 수준에 도달했는지 여부는 노력의 가치가 없으며 기술적 인 결정보다는 비즈니스 결정입니다.

여기 좋은 참조가 있습니다

http://www.joelonsoftware.com/articles/fog0000000043.html

새 코드를 작성하기 전에 버그를 수정합니까? Windows 용 Microsoft Word의 첫 번째 버전은 "죽음의 행진"프로젝트로 간주되었습니다. [...] 버그 수정 단계가 공식 일정의 일부가 아니기 때문에 [...]

Microsoft는 보편적으로 무언가를 채택했습니다 ...] 우선 순위는 새로운 코드를 작성하기 전에 버그를 제거하는 것입니다. [...] 일반적으로 버그를 수정하기 전에 더 오래 기다릴수록 더 많은 비용과 시간이 소요됩니다. .

해당 버그가 더 길수록 우선 순위가되면 버그를 수정하는 데 시간이 오래 걸립니다. 따라서 지금 당장 막대한 이익을 얻는 대신에 비용이 많이 드는 손실을 피할 수 있습니다.

이를 관리하는 좋은 방법은 백 로그 문제를 처리하기 위해 할당 된 시간을 정의하는 것입니다. 이것은 마이크로 소프트처럼 어리석은 것이 아니지만, 클라이언트가 실제로 신경 쓰지 않아도 이미 문제가되지 않는다면 미래의 문제를 해결할 것입니다.

이 개념에 대해 제품 소유자를 설득하기 위해 좋은 리소스를 찾을 수 없었습니다.

상업 조직에서 일한다고 가정하면 비용 편익 분석을 알고있는 사람이있을 것 입니다.

귀사에는 유한 한 개발자 리소스와 유용한 혜택 목록이 있습니다. 이러한 유용한 기능에는 새로운 기능 추가와 기존 버그 제거가 포함됩니다. 버그를 제거하면 새로운 기능을 추가하는 것처럼 소프트웨어가 향상됩니다.

따라서이 무한 자원을이 무한 목록에 할당하는 방법에 대해 결정해야 할 결정이 있으며, 그 결과 일부 버그가 현재, 다음 주, 내년 또는 사실.

보다 체계적인 접근 방식을 찾고 있다면 버그의 사용자 및 프로그래머 뷰에 숫자 를 할당 하는 PEF / REV 시스템 을 수정하여 무엇이 고쳐지지 않는지 결정하는 출발점으로 시도해보십시오 .

소프트웨어 엔지니어링에 대한 다음 두 게시물을 참조하십시오.

어떤 버그를 해결하면 비용이 가장 많이 듭니다

보고 된 거의 모든 버그는 우선 순위가 높은 버그입니다.

소프트웨어 동작의 의도하지 않은 또는 바람직하지 않은 측면이 모두 버그 인 것은 아닙니다. 중요한 것은 소프트웨어가 유용한 방식으로 작동하기 위해 신뢰할 수있는 유용하고 문서화 된 조건을 갖도록하는 것입니다. 예를 들어, 두 숫자를 받아들이고 곱한 다음 결과를 출력하고 결과가 9.95 이상 10.00 미만, 99.95 이상 100.00 미만이면 가짜 숫자를 출력하는 프로그램을 고려하십시오. 프로그램이 제품이 3에서 7 사이 인 숫자를 처리하기 위해 작성되었지만 다른 어떤 것도 처리하도록 요구되지 않는 경우, 동작을 9.95로 수정해도 의도 한 목적에 더 이상 유용하지는 않습니다. 그러나 프로그램을 다른 목적에 더 적합하게 만들 수 있습니다.

위와 같은 상황에서는 두 가지 합리적인 행동 과정이 있습니다.

1. 실제적인 경우 문제를 해결하십시오.

2. 프로그램의 출력이 신뢰할 수있는 범위를 지정하고 프로그램이 유효한 범위 내의 값을 생성하는 것으로 알려진 데이터에만 사용하기에 적합하다고 명시하십시오.

접근법 # 1은 버그를 제거합니다. 접근법 # 2는 진행 상황을 다른 목적보다 목적에 덜 적합하게 만들 수 있지만, 프로그램이 문제가되지 않는 문제가있는 값을 처리 할 필요가없는 경우.

99.95에서 100.0까지의 값을 올바르게 처리 할 수없는 것이 프로그래밍 실수 (예 : 소수점 이하 왼쪽에 두 자리를 출력하여 소수점 이하 자릿수를 출력하여 00.00을 산출하기로 결정)의 결과 인 경우에도 이러한 경우 프로그램이 의미있는 출력을 생성하도록 지정된 경우 버그. [우연히, 위에서 언급 한 문제는 Turbo C 2.00 printf 코드에서 발생했습니다. 그러한 맥락에서, 그것은 분명히 버그이지만, 잘못된 printf를 호출하는 코드는 문제가있는 범위에서 출력을 생성 할 경우에만 버그가있을 것입니다].

느슨한 의미에서, 모든 버그를 고칠 필요는 없습니다. 위험 / 이익 비율 분석에 관한 것입니다.

일반적으로 비즈니스는 기술 담당자 및 이해 관계자와 회의를 통해 '고칠 필요'파일에 포함되지 않은 버그에 대해 논의합니다. 그들은 버그 수정에 투자 한 시간 (= 돈)이 비즈니스에 가치가 있는지 여부를 결정할 것입니다.

예를 들어 '사소한 버그'는 웹 사이트의 이용 약관 섹션에서 약간의 철자 / 문법 오류 일 수 있습니다. 이 문제를 제기 한 개인은 변경하기에는 너무 작다고 생각할 수 있지만 비즈니스는 브랜드에 미칠 수있는 잠재적 인 피해와 몇 가지 문자를 수정하는 상대적 용이성을 인식 할 것입니다.

반면에 중요해 보이지만 해결하기 어렵고 무시할 수있는 사용자 수에만 영향을주는 버그가있을 수 있습니다. 예를 들어 기존 버전의 Chrome을 사용하는 사용자의 경우 작은 버튼 링크가 끊어졌으며 자바 스크립트도 사용 중지되었습니다.

비즈니스에서 버그를 수정하지 않는 다른 이유는 투자 한 시간으로 인해 프로젝트가 예상치 못한 시간을 중단 시키거나 개발자의 시간이 다른 수정 / 코딩 작업에 더 잘 사용될 수 있기 때문입니다. 버그가 사소한 것일 수도 있고 나중에 수정 될 수도 있습니다.

그것이 개념을 조금 더 잘 설명하기를 바랍니다! 나는 일반적으로 이것에 대해 생각하는 것을 피할 것입니다-모든 버그는 독특하며 그렇게 취급해야합니다.

버그 우선 순위 목록으로 이동하면 해당 버그를 유발하는 사용 사례가 더 모호해 지거나 고객 만족도가 낮아집니다.

그래서 그들의 "인수"는 실제로

버그를 충분히 오랫동안 무시하면 사용자는 문제가 무엇인지 잊어 버리거나 문제를 해결할 방법을 찾습니다.

버그는 새로운 기능 요청 과 마찬가지로 "순서대로"우선 순위를 정하고 처리해야합니다 .