개발자의 버그 우선 순위에 영향을 미치고 적절히 처리하는 방법은 무엇입니까?

현재 진행중인 버그 프로세스가 있습니다.

우리는 3 가지 레벨의 버그가 있습니다 :

• P1 버그 : 사용자의 작업을 방해하는 버그. 현장에서 해결해야합니다.
• P2 버그 : 영향을 주지만 사용자가 작업 할 수있는 버그
• P3 버그 : 영향을받지 않고 사용자가 작업 할 수있는 버그.

P1은 필수 사항이며 즉시 처리해야합니다. 그러나 P2 및 P3의 경우 사례별로 판단합니다.

우리가 가지고있는 3 가지 수준으로, 팀은 거의 긴급하지 않은 P2 및 P3를 다루는 대신 고객이 요구하는 더 새로운 개발에 노력하는 경향이 있습니다.

질문은 다음과 같습니다.

P4와 같은 다른 우선 순위를 추가해야합니까?

코딩 작업을 할당하지 않을 때 이번 주와 같이 긴급하지 않은 티켓을 처리 할 대상도 할당해야합니까? 최소한 1P2를 처리해야합니까?

현재, 우리는 위에서 제기 한 목표를 가지고 있지 않지만 그러한 목표를 부여하는 것은 잔인 할 수 있습니다. 확실한 것은 목표에 대해 그들과 이야기해야한다는 점입니다. 팀은 특히 목표를 설정할 때 토론에 참여하고 싶어합니다.

최신 정보:

나는이 질문 을 유사성 측면에서 제안 했다 . 그러나 전혀 비슷하지 않습니다.

제 질문은 사람들에게 엄격한 의제를 부과하지 않고 버그를 해결하도록하고 해결하는 방법입니다. 따라서 아니오, 묵시적인 질문은 도움이되지 않습니다. 여전히 감사합니다.

일반적으로 버그에는 두 가지 축 (중력과 주파수)이 있습니다.

따라서 가장 중요하고 빈번한 것이 가장 중요합니다. 그러나 심각하지만 거의 발생하지 않는 것은 심각하지는 않지만 자주 발생하는 것과 거의 동일하게 계량되어야합니다. 따라서 1에서 3까지의 중력과 1에서 3까지의 빈도를 평가한다고 가정하면 수정해야 할 버그 유형은 중력 1, 주파수 3 및 중력 3, 주파수 1로 정의 된 대각선을 교차하는 버그입니다.

클라이언트 정보에 잠재적 인 손상을 일으킬 수있는 차단 오류 또는 오류는 항상 중력 3입니다. 마찬가지로, 중력 1의 오류는 사용자가 알지 못하거나 우선 순위가 낮습니다. 확실하지 않은 경우 2는 할당하기에 안전한 숫자 일 것입니다.

사용자가 볼 때마다 오류가 발생하고 프로그램을 시작할 때마다 빈도는 3입니다. 빈도 1의 오류는 거의 발생하지 않습니다. 다시 말하지만 확실하지 않은 경우 2는 할당하기에 안전한 숫자 일 것입니다.

중력 3의 버그 또는 주파수 3의 버그를 구성하는 것은 주로 주관적이지만 상식을 사용하십시오. 중력 1, 빈도 2의 버그는 철자가 틀린 레이블 일 수 있습니다. 데이터베이스 연결이 끊어졌을 때 중력 2, 빈도 1의 버그가 올바른 오류 처리 일 수 있습니다.

다시 말하지만, 이것은 대략적인 아이디어이지만 일종의 심사로서 버그 수정에 중점을 두어야 할 사항에 중점을 둡니다. 적어도이 방법론을 사용하여 모든 버그를 제거하거나 차단하거나 제거하는 것은 불가능합니다. 버그가 너무 중요하거나 빈번하지는 않습니다. 오류를 차단하는 버그만 수정하면 고주파수 오류가 무시되고 사용자 는 이러한 버그를 수정하지 않은 것을 알 수 있습니다.

또한 편의상 중력 또는 주파수에 대해 문자 등급을 제공하는 것을 선호하므로 버그가 B3 오류라고 말할 수 있으며 중력과 주파수가 모두 명확합니다.

행운을 빕니다!

이것은 정말로 당신이 더 중요하다고 생각하는 것으로 요약됩니다. P2 버그 또는 새로운 기능?

일반적으로 민첩한 프로젝트 관리 시스템에는 우선 순위별로 작업을 정렬하고 해당 순서대로 작업하는 일종의 우선 순위 모임이 포함됩니다.

개발자는 작업중인 작업을 선택할 수 없습니다. 이것이 프로젝트 관리자의 일입니다. 예산이 소진되기 전에 프로젝트에 포함 된 가장 중요한 기능을 최대한 많이 확보해야합니다.

그것은 정말로 가장 중요한 것입니다. "일주일에 적어도 1P2 수정"과 같은 간단한 규칙은 실제로이 목표에 도움이되지 않습니다.

소프트웨어가 무언가를 줄 때까지 중요하지 않은 버그를 쌓아 올리는 것은 매우 일반적인주기입니다. 큰 이벤트가 발생하고 많은 버그가 한 번에 수정됩니다. 큰 새 릴리스가 나오기 전에 스프린트 한두 개만 버그 수정에 전념하거나 소프트웨어가 EOL이고 힙-오-버그에서 살아남은 경우 일 수 있습니다.

따라서 개발자가 슬라이드를 보자면 좋은 회사에 있습니다. 물론 당신이 언급 한 것처럼 "규칙"( "새로운 기능을 사용하지 않는다면, 적어도 일주일에 P2로 작업해야합니다")으로 뒤섞 일 수 있지만, 그것은 당신에게 인기가 없을 것입니다.

제 질문은 사람들에게 엄격한 의제를 부과하지 않고 버그를 해결하도록하고 해결하는 방법입니다.

대신, 전반적인 사고 방식을 약간 변경하고 버그가 백 로그에서 일류 시민이라는 의미에서 기능과 같은 버그를 만드는 것이 좋습니다. 예, 새로운 기능은 훌륭합니다. 그렇습니다. 관리 및 판매는 새로운 기능을 매우 어렵게합니다. 그러나 거대 지저분한 버그 대신 안정적이고 잘 작동하는 응용 프로그램을 갖는 것도 중요합니다.

개발자들에게 그들이 싫어하는 일을해야한다고 말하지 마십시오. 그러나 버그를 다루는 것을 좋아하도록 분위기를 바꾸려고 노력하십시오. 버그가없는 응용 프로그램에 자부심을 심어보십시오. 버그를 해결하는 데있어 근본적인 이유 (예 : 빠른 해결 방법 / 해킹이 아닌)를 실제로 수정하도록함으로써 버그에 대해 작업하는 것이 더 재미있게 만들어집니다. 깨진 클래스 구조를 제거하고 더 적합한 것으로 교체하면 개발자에게 매우 재미있을 수 있습니다. 중앙 부분이 파손되어 정기적으로 버그가 발생하는 경우 중앙 부분을 수정하십시오.

목표를 달성하는 방법은 자신의 성격과 팀의 성격에 크게 의존합니다. 달성하려는 목표에 속지 말고 공개 토론을하고 동료 효과를 얻으려고 노력하십시오. 작업 프로세스 자체 등.