우선 순위와 심각성이 모두 필요한 이유는 무엇입니까?

나는 그들이 무엇을 결정하는지 이해하지만 발견 된 문제에 할당하는 것이 실제로 유용합니까? 내 말은, 빨리 고쳐야 하는가 아닌가.

나는 그들을 설정하고 분류하는 방법을 알고 있습니다. 나는 IEEE / ISO가 그렇게해야한다는 것을 알고 있습니다. 나는 왜 그런지 모르겠다.

이러한 값을 다르게 설정하는 것이 가능합니다. 고성능을 요구하지만 모듈 X를 사용하지 않는 중요한 정부 기관에 판매하려고 할 경우 X 모듈의 심각한 오류보다 작은 데이터베이스 가용성 오류를 빨리 수정하는 것이 많은 비즈니스 의미가 있습니다. 기본적으로 소프트웨어 비즈니스 를 운영 할 때 기술적 인 이유 만있는 것은 아닙니다 .

날짜 및 시간 버그

버그 : 연말 처리는 데이터베이스를 완전히 손상시킵니다. 그것은 분명히 심각한 버그입니다.

날짜 : 12 월 15 일. 버그의 우선 순위가 매우 높습니다.

날짜 : 2 월 1 일. 버그의 우선 순위가 낮습니다.

실수로 미사일 버그 발사

버그 : ICBM 제어 소프트웨어는 2 년 28 월에서 3 월 1 일까지 4로 나눌 수 있습니다. 결과는 명령되지 않은 시작입니다.

그것은 존재하는 버그만큼 심각합니다. 우선 순위가 매우 낮습니다. 조건이 트리거 될 때 소프트웨어가 실제로 사용될 가능성이 있습니까?

화면에 부주의 한 '나쁜'단어

버그 : 화면에 공간이 넘치면 Bob에 대한 부적절한 참조가 나타납니다. (실제 세계 : "Final Ass"부서에서 일하는 사람들이있었습니다. "Ass"= "Assembly".

안타깝게도 내일 당신은 회사를 위해 판매를하는 것이 프리젠 테이션을하고 있습니다. "Bob"이라는 사람에게 프레젠테이션을하고 있습니다. 심각도 : 매우 낮습니다. 우선 순위 : 매우 높습니다.

당신은 썼습니다 :

내 말은, 빨리 고쳐야 하는가 아닌가.

맞아요. 그러나 대부분의 회사와 같은 경우 자원이 제한됩니다. 모든 문제를 해결할 충분한 인력이 없거나 시간이 충분하지 않습니다.

버그를 신속하게 수정하거나 수정하지 않아도되고 수정해야하는 버그가 많다는 사실을 고려할 때 "우선 순위"는 "어느 것을 먼저 수정해야합니까?"라는 질문에 대답합니다.

반면에 심각도는 우선 순위를 설정하는 사람이 사용하는 지표입니다. 개발자의 관점에서 심각도는 약점입니다. 과제 할당의 관점에서 심각도는 의사 결정 프로세스에 도움이되는 중요한 정보입니다.

물론이 모든 것은 매우 일반적인 정보입니다. 버그에 대한 백 로그가 엄청나게 긴 팀인 경우 우선 순위와 심각도는 버그가 거의없는 버그 데이터베이스가있는 팀에있는 경우와 완전히 다른 의미입니다.

"높은 심각도 == 높은 우선 순위"인 팀에서이 중 어느 것도 중요하지 않으며 두 가지 메트릭이 모두 필요하지 않습니다. 하루가 끝나면 도구 일뿐입니다. 팀에서 사용 방법을 결정해야합니다. 팀에게는 둘 다 사용하는 것이 합리적이지 않을 수 있습니다.

IMHO, 우선 순위와 심각도 모두 관료 주의적입니다.

실제로는 "중요도"라는 측정 기준 하나만 있으면됩니다. 종종 우선 순위가 사용되며 심각도는 "높음 = 충돌 시스템 또는 사용할 수 없게 만드는", "중간 = 버그가있는 행동, 잠재적으로 유해한", "낮은 = 성가신, 성가 시지만 무해한"과 같은 기술 용어로 사용됩니다.

일반적으로 우선 순위는 심각성과 밀접한 관련이 있습니다. 몇 가지 반대 사례는 "모든 사람이 항상 불평하는 성가신"또는 "이국적인 환경에서 한 번 충돌이 발생한 것"입니다.

...하지만 결국 개발자 (또는 관리자 등)는 어떤 순서로 문제를 해결 / 개선해야한다는 것만 알면됩니다. 따라서 하나의 측정으로 충분합니다.

우선 순위가 필요하다는 것은 분명합니다. 버그 리포트를 어떤 순서로 처리해야하는지 알아야합니다. 다른 하나 인 IMHO는 평소와 같이 관료주의입니다. 왜 필요한가요? 우선 순위가 그렇게하기 때문에 정렬에 쓸모가 없습니다. 그리고 결과 (심각도 설명)는 어쨌든 버그 보고서에 설명되어 있습니다.

나는 그것이 어떤 버그가 더 중요한지 명확하지 않기 때문에 해롭다 고 생각합니다.

• 어떤 사람들은 "중요한"버그가 "높은 우선 순위"버그보다 우선 순위가 높다고 생각할 수 있습니다.
• 버그를보고하는 일부 사용자는 심각도와 우선 순위를 혼동 할 수 있습니다
• ... 버그를 다루는 순서에 대해 혼란을 더합니다.

다른 답변 외에도 다음 시나리오를 고려하십시오. 버그 A는 수정하는 데 30 분이 걸리고 심각도가 '낮습니다'. 버그 B는 수정하는 데 2 ​​주 이상 걸릴 수 있으며 심각도가 '높습니다'. 또한 버그 B는 개발자 팀과 팀 외부에서 많은 토론과 조정을 수행 할 수 있습니다. 버그 A는 단일 개발자에 의해 즉시 수정 될 수 있습니다. 버그 A에 우선 순위를 두는 것이 좋습니다.

물론 '심각도'와 '우선 순위'는 다른 방식으로 해석 될 수 있습니다.

작은 버그 추적기에서 나는 스스로 사용하기 위해 심각도가 높은 문제가 항상 우선 순위가 높은 '난이도'와 '우선 순위'를 선호했으며 난이도에 따라 작업을 지연하기로 결정할 수 있습니다.

'심각도'에 대해 내가 싫어하는 한 가지는 버그에만 적용되고 기능에는 적용되지 않는다는 것입니다. '다음에 무엇을해야합니까?'를 결정하는 것이 더 도움이되므로 우선 순위와 난이도별로 정렬 된 모든 문제의 단일 목록을 갖는 것이 좋습니다.

ISO9001 : 2007 인증을받은 소프트웨어 회사에서 프로세스를 설계하고 구현했습니다. 2007 년 이후 표준에 대한 업데이트가 있었으므로 알지 못하는 추가 요구 사항이있을 수 있습니다.

ISO9001 표준은 귀사가 제품 및 프로세스 결함이 식별 될 때 프로세스를 개선하기 위해 피드백 루프가있는 프로세스를 설계하고 구현하도록하는 것입니다.

설계 단계에서 요구 사항은 제안 된 솔루션이 올바르게 구현 된 경우 실제로 설계 개요 (유효성 검증)를 해결할 수 있는지 여부와 구현이 실제로 결함없이 구현되었는지 확인 (확인)하는 데 중점을 둡니다.

피드백 루프에서 결함이 식별되면 결함이 기록되기에 충분하지 않습니다. 결함의 심각성도 평가해야하며 재 작업이 우선시됩니다.

중요한 부분은 특정 회사가 심각도를 평가하고 우선 순위에 대한 결정을 내리는 방법이 ISO 표준에 의해 정의되지 않는다는 것입니다. 회사가 결정하고 문서화하는 것은 상업 및 거버넌스 문제입니다.

표준으로 요구 사항으로 작성되면 인증 된 회사는 결함의 심각도를 평가하는 프로세스와 버그 수정 작업의 우선 순위를 결정하는 프로세스를 갖게됩니다. 그들은 반드시 두 가지 별도의 결정을 내려야합니다.

버그의 심각성은 하나의 데이터 포인트입니다. 고객 영향 또 다른 데이터 요소입니다. 또한 수정, 결함 연령, 제품에 남아있는 상용 수명 및 회사가 의사 결정에 포함하기로 결정한 기타 요인에 대한 노력도 있습니다. 결정을 내리는 권한 만 정의하고 결정을 내리는 과정을 정의하지 않기 때문에 "제품 관리자가 우선 순위를 결정하는 데있어 현재의 결함"으로 작성해서는 안됩니다.

전반적인 제품 안정성을 가장 크게 향상시키는 것처럼 보이는 작고 중요한 변경 사항을 빠르게 적용하는 데 편향된 우선 순위를 선호합니다. 즉, 해결하기 위해 많은 작업이 필요한 심각한 버그는 일정을 잡기 위해 충분한 우선 순위를 얻기 위해 작은 청크로 나누어 진 작업이 필요합니다.

우선 순위와 심각도가 크게 다른 이유 :

간단한 예입니다. 시스템의 확장을 방해하는 좁은 장소가 있다고 가정합니다. 일부 알고리즘에는 복잡도 O (N ^ 3)가 있으며 여기서 N은 고객의 상점 수입니다. 고객은 내년에 200 개의 새로운 매장을 열 것이며 필요한 계산 (상품 분배, 운송 계획 등)이 제 시간에 완료되지 않을 것이라고 말했습니다. 그러나 현재이 클라이언트에는 30 개의 상점 만 있으며 자원이 충분합니다. 이 알고리즘을 최적화하는 작업 (O (N ^ 2) 이상)은 확실히 중요하지만 (구현되지 않으면 클라이언트를 잃게됩니다) 긴급하지는 않을 것입니다. 새 알고리즘을 구현하는 데 몇 달이 걸립니다.

예 2 : 응용 프로그램이 체계적으로 충돌하지만 업그레이드 또는 마이그레이션으로 인해 며칠 내에이 버전의 사용이 중단됩니다. 충돌은 실제로 사용자 경험에 영향을 주지만 중요도가 낮기 때문에 수정이 시급합니다.

물론, 두 매개 변수는 단기적 작업 계획을 생성하기 위해 일부 공식 (비공식 또는 비공식)을 사용하여 통합되는데, 후자는 단일 차원 (작업 순서)이기 때문입니다. 그러나 장기적인 관점에서 그것들은 통일되지 않을 것이다.