버그와 원래 개발에 어느 정도의 시간을 소비해야합니까? [닫은]

이 질문은 약간 추상적이지만 누군가가 올바른 방향으로 나를 가리킬 수 있기를 바랍니다.

내 질문은 원래 개발 시간과 관련하여 소프트웨어 프로젝트의 버그에 얼마나 많은 시간을 할애 할 수 있는지입니다. 나는 결정 요소가 엄청나게 많다는 것을 알고 있지만 전형적인 또는 평균 고장을 원했습니다.

예를 들어, 프로젝트 A를 완료하는 데 40 시간이 걸리고 추가로 10 개의 수정 버그가있는 경우이 프로젝트의 비율은 4 : 1입니다.

다른 프로젝트 (B)가 완료하는 데 10 시간이 걸리고 또 다른 8 개의 버그가 있으면 5 : 4의 비율이됩니다.

이것이 문서화 / 연구 된 개념입니까?

최신 정보

모든 유익한 답변에 감사드립니다. 관련된 모든 변수와 환경 요인으로 인해 이러한 종류의 메트릭에 표준을 적용하는 것은 불가능하다는 것을 알고 있습니다. 답변을 할당하기 전에이 측정 항목에 합의 된 이름이 있는지 더 알고 싶습니다. 추가 조사를 수행 할 수 있습니다. 메트릭을 생성하는 데 필요한 측정 값을 이해하고 프로젝트의 기본 표준을 제시 할 수있는 지점에 도달하고 싶습니다.

결함 수정에 할당 된 총 용량의 평형 백분율은 결함 주입 률 과 같습니다 .

물론 팀이 개발하는 제품의 종류, 사용하는 기술 및 기술 관행, 팀의 기술 수준, 회사 문화 등 많은 요소가이 비율에 영향을 줄 수 있습니다.

팀 B를 고려할 때, 완료 한 10 개의 작업 단위마다 평균 8 개의 재 작업을 작성하면 8 개의 단위를 작업하면 새로운 6.4 개의 재 작업이 작성됩니다. 우리는 기하학적 진행의 합으로 결국 소비해야 할 총 노력을 추정 할 수 있습니다.

10 + 8 + 6.4 + 5.12 + ...

버그의 수는 시간이 지남에 따라 기하 급수적으로 감소하지만 B 팀은 지수에 이러한 계수가있어 매우 느리게 0이됩니다. 실제로, 위의 시리즈에서 처음 세 항의 합은 24.4에 불과합니다. 처음 5 개 중 33.6; 처음 10, 45 중; 따라서 전체 시리즈 중 50 개. 따라서 팀 B 요약 : 결함 주입 률, 0.8; 기능 개발, 10/50 = 20 %; 결함 고정, 80 %. 20/80은 지속 가능한 용량 할당입니다.

대조적으로, 팀 A는 훨씬 더 나은 형태입니다. 그들의 진행은 다음과 같습니다 :

40 + 10 + 2.5 + 0.625 + ...

이 시리즈의 합은 53 1/3이므로 팀 A의 기능 개발 할당은 40 / (53 1/3) = 75 %이고 결함 수정 할당은 25 %이며 결함 주입 비율은 10/40 = 0.25입니다. .

실제로, 처음 3 이후의 팀 A 시리즈의 모든 용어는 무시할 정도로 작습니다. 이것이 실제로 의미하는 것은 팀 A가 아마도 두 개의 유지 보수 릴리스로 모든 버그를 제거 할 수 있다는 것입니다. 두 번째 릴리스는 범위가 매우 작습니다. 이것은 또한 모든 팀이 할 수 있는 환상을 만듭니다 . 그러나 B 팀은 아닙니다.

데이비드 앤더슨 (David Anderson)의 새 책 "간반 (Kanban)" 을 읽는 동안이 동등성에 대해 생각했습니다 . 소프트웨어의 품질을 논의 할 때 Anderson 은 Capers Jones가 "소프트웨어 평가, 벤치 마크 및 모범 사례"라는이 책을 인용 합니다 .

"... 2000 년 ... 북미 팀의 소프트웨어 품질 측정 ... 기능 포인트 당 6 개 결함에서 100 개 기능 포인트 당 3 개 미만, 200에서 1까지의 범위까지 중간 범위 는 약 1 개입니다. 기능 포인트 0.6 ~ 1.0 : 팀이 결함을 수정하는 데 90 % 이상의 노력을 기울이는 것이 일반적임을 의미합니다. "그는 버그를 수정하는 데 90 %의 시간을 소비하는 회사 동료 중 한 명이 제공 한 사례를 인용합니다 . .

Anderson이 결함 주입 속도에서 defext-fixing capacity 할당에 이르기까지의 유창성 ( 실패 요구 는 그 용어 임)은 두 가지의 동등성이 소프트웨어 품질 연구자들에게 잘 알려져 있으며 아마도 한동안 알려졌을 것임을 시사합니다 .

제가 여기 제시하려고하는 추론의 핵심 단어는 "평형"과 "지속 가능"입니다. 지속 가능성을 없애면 이러한 수치를 속이는 명백한 방법이 있습니다. 초기 코딩을 한 다음 다른 곳으로 코드를 옮기고 다른 사람에게 유지 보수를 맡기십시오. 또는 기술 부채를 상환하여 새 소유자에게 내립니다.

분명히 모든 팀에 적합한 할당은 없습니다. 버그에 20 %를 소비해야한다고 결정한 경우, 팀에 결함 주입 률이 매우 낮 으면 시간을 채울 버그가 충분하지 않으며 팀의 속도가 매우 높으면 버그가 발생합니다. 계속 축적됩니다.

여기서 사용한 수학은 단순화되었습니다. 나는 거래 비용 (계획 및 추정 회의, 사후 조사 등)을 무시했는데, 이는 백분율에 약간 영향을 미칩니다. 또한 한 제품을 유지하고 다른 제품을 동시에 개발하는 시뮬레이션을 생략했습니다. 그러나 결론은 여전히 ​​유효합니다. 단위 테스트, 지속적인 통합, 코드 검토 등과 같은 기술 실무 측면에서 결함 주입 속도를 줄이고 결과적으로 실패 요구를 줄이려면 수행 할 수있는 작업을 수행하십시오. 10 가지 기능마다 하나의 버그만 만들 수 있다면 새로운 기능을 개발하고 고객을 만족시킬 수있는 많은 자유 시간이 있습니다.

불행히도 나는이 비율이 주어진 프로젝트에서 매우 가변적이라고 생각합니다. 환경, 언어, 도구, 팀 규모 및 경험에 의해 크게 영향을받습니다.

수정 프로그램에서 얻는 것이 투자 한 것보다 큰 경우에만 버그에 시간을 투자해야합니다.

다음과 같은 매트릭스를 사용하십시오 (수평-버그 수정에 필요한 시간, 수직-버그 유형-사용자에게 미치는 영향)

              | Few hours | Many hours
--------------+-----------+-------------------------
Minor problem | Might fix | Fix only if time permits
--------------+-----------+-------------------------
Major problem | Fix       | Fix

문제의 예 :

              | Few hours                            | Many hours
--------------+--------------------------------------+---------------------------------
              | Window moves 1px every 10            | Windows is painted incorrectly 
Minor problem | times when you open the application. | every 100th time the app is open.
              | Fix is: handle window resize event   | Fix: Change the graphical engine.
--------------+--------------------------------------+---------------------------------
Major problem | Application crashes when opening     | Poor performance when >100 users 
              | SQL connection.                      | are connected (unusable app)
              | Fix: Fix invalid query + add nice    | Fix: change architecture + DB
              | message                              |

매트릭스는 다른 심각도, 노력, 위험 등의 수준으로 더 복잡 할 수 있습니다.

각 버그에 대한 순위를 만들어 순위에 따라 수정할 수도 있습니다. 다음과 같은 것 :

Bug priority = Risk x Severity x Effort

* 선택한 스케일에 따라 일부 피연산자의 경우 (1-x) 일 수 있습니다 :)

따라서 질문에 대답하려면 버그 유형, 사용 가능한 시간 / 예산 등에 따라 다릅니다.

팀의 경험과 품질뿐만 아니라 프로젝트의 어려움 (새로운 OS 커널과 다른 표준 웹 응용 프로그램을 만드는 것과 동일하지 않음)뿐만 아니라 관리 접근 방식에 따라 매우 다양합니다. 사용하겠습니다.

예를 들어, 폭포수 모델에서는 첫 번째 테스트 단계에서 첫 번째 버그를 정확하게 설정할 수 있지만 민첩한 환경에서는 기능이 변경 될 수 있으므로 "여기부터 버그를 수정하고 있습니다"라는 문구를 작성하기가 어려울 수 있습니다 ( 그리고 나에게 그것은 기능 변경을 버그로 간주하는 것이 불공평합니다)

경험상, 나는 그것이 항상 과소 평가 된 것이며, "원본 프로젝트"와 같은 시간을 아주 쉽게 보낼 수 있다고 말합니다.

코드가 완벽하기 때문에 버그 수정에 대한 정답은 0 시간입니다. :-)

현실적으로, 나는 누군가가 그런 유형의 비율을 요구하거나 제공한다고 들었다고 말할 수 없습니다. 그러나 일부 회사는 개발 및 유지 관리 시간을 모두 추적하지 않는다고 말할 수는 없습니다. 그러나 대부분의 회사가 돌아가서 그 비율을 계산하지 않는 유지 관리와 비교할 때 응용 프로그램 개발은 짧은 기간입니다. 그들은 아마도 앱이 유지 보수를 요구하는 이유를 배우고 그 결과를 새로운 응용 프로그램에 적용하는 것에 대해 더 우려하고 있습니다.

버그가 무엇인지에 대한 기준이 너무 광범위하면 시간이 거의 두 배가 될 수 있습니다. 클라이언트가 버튼을 더 크게 만들라는 요청 (마우스 문제가 있음)을 생각하는 지나치게 열성적인 관리자는 우리가 수정 한 버그 수를 늘리는 좋은 방법입니다. 패치를 고려, 테스트, 재 컴파일 및 배포 할 필요가 없기 때문에 수정하는 데 몇 초 밖에 걸리지 않습니다. 아, 그리고 그것은 새로운 기능으로 두 번 계산됩니다.

이를위한 가장 큰 결정 요인은 새로운 기술을 사용하는지 아니면 기존 기술을 사용하는지 여부입니다. 새로운 작업을하고 다른 환경에서 수행되지 않았거나 몇 번 수행 된 작업을 개발하는 경우 버그 수정에 많은 시간을 할애하고 프로젝트가 원하는 방식으로 작동하게됩니다 . 종종 버그는 스스로 구석에 서 작업 한 결과이므로, 수행 한 작업을 재구성하기 위해 상당한 양의 작업을 수행해야합니다. 또한, 많은 버그는 사용자의 기대치에 대한 불완전한 이해와 개발자가 엣지 케이스를 인식하지 못해 발생합니다.

확립 된 기술을 연구하고 있다면, 대부분의 문제는 도서관이나 커뮤니티의 관행에 의해 해결되었을 것이며, 버그가 발생했을 때 Google을 구매하거나 구매하거나 길을 물어볼 수 있어야합니다.

중요한 소프트웨어에서는 1 : 1 비율이 드문 일이 아닙니다. 단위 테스트의 경우 10 줄의 코드마다 1 일 단위의 단위 테스트가 표시됩니다.

내 생각에는 이 질문이 편견적 . 버그를 수정하는 것은 새로운 기능을 개발하는 것과 비슷한 단계라는 전제에서 시작한다 . 그렇지 않다.

좋은 개발자는 코드를 처음부터 버그가 없으므로 코드 디버깅에 많은 시간을 소비하지 않습니다. 나쁜 개발자는 실제 문제를 해결하기 위해 적절한 추상화를 만들 수 없기 때문에 코드를 디버깅하는 데 많은 시간을 할애합니다.

개발자는 자신의 코드 자체를 단위 테스트해야합니다. 버그가없는 코드를 제공하는 것은 그들의 책임입니다. 따라서 코딩과 디버깅을 분리하기가 어렵습니다.

또한 우선 순위의 문제입니다. 개발시 버그를 수정하는 데 필요한 시간은 코드에 버그를 삽입 한 이후로 지난 시간과 기하 급수적으로 관련됩니다. 따라서 새로운 기능을 개발하는 것보다 버그를 수정하는 것이 우선 순위가 높아야합니다.

따라서 "버그에 소요 된 시간"에 대해 말하는 대신 "테스트에 소요 된 시간"(통합 테스트, 사용자 승인 테스트 ...)에 대해 이야기해야합니다.

나는 당신이 옳다고 생각합니다-당신은 영향을 미치는 요인의 수로 인해 의미있는 메트릭을 얻지 못할 것입니다.

그것이 내가 당신에게 일하는 프로젝트 (기업 공간, 대규모 복잡한 시스템, 다른 시스템과의 많은 통합)를 알 수 있다면 약 3 : 2의 비율입니다. 이들 중 대부분은 코드의 결함이 아니며, 일반적으로 인터페이스의 결함입니다. 예를 들어, 시스템 A와 B는 인터페이스 X를 통해 서로 통신합니다. 시스템 A의 개발자는 인터페이스 X를 시스템 B의 개발자와 약간 다르게 해석합니다. 코미디가 이어집니다.

코드를 개발하고 코드를 테스트 / 버그 수정하는 것은 별개의 두 단계가되어서는 안된다는 것을 관찰해야합니다. 개발할 때 테스트하면 버그 수정의 "비용"이 적습니다.

나는 실질적으로 실용적인 관점을 취한다 : 프로젝트의 실질적인 유용성을 더 방해하는 것은 무엇인가? 기존 기능의 버그 인 경우 버그를 수정해야합니다. 누락 된 기능이있는 경우 독창적 인 개발을 수행 한 다음 가장 심각한 누락 된 기능이 구현되면 버그를 수정하고 수정하십시오. 이를 위해서는 사용 사례에 익숙해야합니다. 이상한 경우에 프로그램을 중단시키는 버그는 모든 사람에게 영향을 미치는 사소한 유용성 향상보다 우선 순위가 낮을 수 있습니다. 가장 일반적으로 사용되는 기능의 작은 성가신 버그는 소프트웨어를 극도로 추진하는 사람들에게만 도움이되는 기능보다 더 중요 할 수 있습니다.