버그로 사례를 다시 열어야합니까, 아니면 새로운 사례로 버그를 열어야합니까?

현재는 직장에서 다양한 웹 응용 프로그램의 모든 기능과 버그를 관리하기 위해 FogBugz 를 사용 합니다.

웹 애플리케이션 중 하나에 새로운 기능을 추가하면 새로운 사례가 생성됩니다. 예를 들어 "CSV 업로드 양식 작성"입니다.

그런 다음 내가 보낸 시간을 기록하면서 사건을 처리합니다. 이 사례가 완료되면 사례를 해결 한 다음 사례 오프너 (일반적으로 프로젝트 관리자)에게 다시 할당되어 사례를 종료합니다.

이 기능에 버그가있는 경우 프로젝트 관리자가 사례를 다시 열고 버그의 글 머리 기호 목록을 사용하여 사례를 다시 할당합니다.

내 생각에 나는이 글 머리 기호 버그는 개별 버그 사례로 열어야하므로 쉽게 추적 할 수 있고 원래 기능 사례 노트로 어수선하지 않아야한다고 생각합니다.

관리자가 한 가지 경우에 기능에 소요 된 총 시간을 계산하는 것이 더 쉽다는 점에 동의하지 않습니다.

또한 고객이 기능에 대해 1 개의 사례 번호 참조 만 있으므로 혼동이 줄어든다고 생각합니다. 그러나 나는 원래 사례의 사후 완료이므로 버그를 별도의 사례로 처리해야한다고 강조합니다.

버그를 새로운 사례로 다시 열어야한다는 말이 맞습니까? 그리고 이것을 관리하는 각 방법의 장단점은 무엇입니까?

귀하와 귀하의 관리자 모두 각자가 선호하는 방식을 다루어야 할 충분한 이유가 있으며, 타협 할 필요가 없습니다. 저에게 효과적이며 두 가지 문제를 모두 해결하는 솔루션이 있습니다.

당신과 같은 경우에 나는 높은 수준의 작업 / 낮은 수준의 하위 작업 접근 방식을 사용합니다 ( JIRA 에서 선택한 개념 , FogBugz가 명시 적으로 지원하는 ^것처럼 말할 수는 없습니다 ). 이런 식으로 "클라이언트 대면"글 머리 기호 목록은 높은 수준의 작업으로 이동하고 나에게 중요한 "개발자 반복"은 하위 작업에 반영됩니다.

높은 수준의 작업이 "다시 열리면" 자체 하위 작업을 추적하기 위해 새 하위 작업을 만듭니다 .

이러한 방식으로 개발자는 기능 사양에 의해 전달 된 모든 순열, 왜곡 및 왜곡을 명확하게 반영하여 관리자가 완벽하게 고객에게이를 제시 할 수 있습니다. 그건 그렇고 완벽한 프레젠테이션은 개발자로서 나에게 가치가 있습니다. 고객이 더 쉽게 읽을 수 있도록하면보다 정확한 조정을 얻는 데 도움이되기 때문입니다.

또한 기능 구현이 원래 예상보다 훨씬 많은 시간이 걸리는 경우 자연스럽게 명확한 정당성을 가질 수 있습니다.

_{작업 또는 하위 작업 당 시간 추적-JIRA는 하위 작업 추적을 상위 레벨 요약에 포함 할 수 있으므로 하위 작업에서 시간을 추적하는 것이 허용됩니다. 그러나 이것이 사실이 아니더라도 "부모"작업에서 공식적으로 시간을 추적하면서 살 수 있습니다.이 경우 하위 작업 주석을 사용하여 특정 반복에 소비 된 시간을 나타냅니다.}

기능이 고객에게 릴리스되기 전에이 모든 것이 발생하는 경우 하나의 사례 만 있습니다. 여기서의 주장은 QA가 통과되어 출시 될 준비가 될 때까지 해당 사례가 완전히 완료되지 않았다는 것입니다. 다른 이점-청구 및 최종 사용자가 참조 할 수있는 단일 사례 번호는 유효하고 중요합니다.

기능이 릴리스되고 버그가 발견되면 문제 추적 소프트웨어에서 새로운 문제로 제기되어야합니다.

나는 당신에게 완전히 동의하고, FogBugz도 그렇습니다-그것이 버그와 기능에 대해 다른 카테고리를 정의하는 이유입니다. FogBugz는 시간 사용을 추적하기위한 도구가 아닙니다. 이것은 증거 기반 스케줄링의 도입으로 우연히 발생하는 부산물입니다.

완성 된 지형지 물에 대한 버그는 지형지 물의 주요 사례 (FogBugz에서 태그 이름 또는 상호 참조를 사용하거나 하위 사례로 만들면)에 연결될 수 있습니다. PM이 여러 경우에 걸쳐 정보를 통합하는 데 약간 더 많은 작업이 있음을 알 수 있지만 원래 개발에 소요 된 시간과 유지 보수에 소요되는 시간, 특히 고정 가격 계약에 대한 시간을 분리 할 수있는 경우도 있습니다. 모든 것을 한 경우에 넣으면이 작업을 수행 할 수 없게됩니다.

일단 티켓이 닫히면 티켓은 닫혀 있어야하며 버그 추적기는 다른 경우에 연결할 수 있어야합니다. 새 버그를 만들어 원래 사례에 연결하면 설명하는 방법보다 더 많은 이점이 있습니다.

• 클라이언트는 여전히 각 버그에 대한 링크를 포함하는 하나의 참조 번호를 가질 수 있습니다.
• 각 버그의 상태를 개별적으로 추적 할 수있어 우선 순위 및 상태보고가 향상됩니다.
• 별도의 버그가 있으면 관리자가 버그에 소요 된 시간과 새로운 기능을 개발하는 데 소요되는 시간을 구분할 수 있으며 변경 및 해당 변경의 개발과 관련된 모든 버그의 총 수를 얻기위한 최소한의 추가 노력이 필요합니다.
• 버그를 분리하면 관리자가 전체 버그, 버그 당 평균 수정 시간, 종료 / 진행 / 고정 버그 비율과 같은 다른 메트릭을 훨씬 쉽게 수집 할 수 있습니다.
• 버그마다 별도의 사례를 사용하면 모든 개발자간에 작업을 더 잘 나누어 각 작업에 대한 책임을지게하거나 나중에 더 많은 개발자를 고용 할 경우이 가능성을 허용 할 수 있습니다.

현재 설정의 유일한 장점은 시스템의 주요 사용자가 아닌 사람들에게 매우 간단하다는 것입니다. 버그 추적기의 목적은 개발자가 버그에 대한 모든 것을 한 곳에서보고하여 다른 사람들이 진행 상황을 볼 수있을 정도로 친절 할 수 있도록하는 것입니다. 현재 시스템은 거의 모든 부분을 손상시키는 것으로 보입니다.

제품이 고객에게 '배송 / 출시'되기 전이나 후에 버그가 발견 되었습니까?

릴리스 이전 인 경우 버그는 원래 티켓에 대해 추적되어야합니다.

릴리스 이후 인 경우 각 버그는 자체 티켓이어야합니다.

내가 일하는 곳에서는 품질 보증 담당자 만 사례를 종결 할 수 있습니다. Code Review, Engineer Tested 및 Demo to Stakeholder (귀하의 경우 Project Manager) 확인란이 있습니다. 품질 관리팀에 '완료'라고 표시된 사례가 표시되는데이 입력란이 모두 표시되지 않은 경우 취소 된 것으로 표시하고 다시 Google에 보냅니다.

사례가이 모든 단계를 통과하고 QA가 사례를 종료하면 발견 된 새로운 문제가 모두 버그로 기록됩니다.

이 시스템은 우리에게 잘 작동하는 것 같습니다.

두 가지 방식으로 논쟁을 할 수 있다고 생각합니다. 나는 PM과 함께 앉아서 별개의 문제가 당신을 도울 것이라고 생각하는 이유를 설명하려고 노력할 것입니다. 나는 개인적으로 각 할 일 항목이 자체 티켓이되어야하지만 그가 왜 그렇게 원하는지 알 수 있습니다.