답변:
예전 회사에서는 이러한 상태를 사용하여 개발자가 얼마나 "나쁜"지 확인하기 위해 문제가 "다시 열림"으로 몇 번이나 이동했는지 추적했습니다. 그들은 작업 항목이 "재 개설"되는 횟수와 프로그래머로서의 가치 사이에 상관 관계가 있다고 생각했습니다.
나는 더 이상 거기서 일하지 않습니다.
또한 문제가 해결 된 후에도 계속 문제가되기 때문에 문제에 더주의를 기울이거나 더 빨리주의를 기울여야한다는 것을보다 분명하게 밝힐 수 있습니다.
우리가 여기서 사용하는 방식 :
새 작업 : 프로젝트 시작시 작성해야 할 모든 작업을 표시합니다. 누군가 코딩 할 때까지 열린 다음 해결됩니다. 무언가가 구현되지 않았거나 기능이 변경되어 개발자가 돌아와서 작업하는 데 상당한 시간을 소비 해야하는 경우에만 다시 열립니다.
버그 / 결함 : QA 또는 다른 개발자가 전체 작동중인 제품을 확인하여 열었습니다. 버그가 할당되면 버그를 수정 한 다음 해결하면 테스트로 돌아갑니다. QA가 수정되지 않았다고 생각되면 다시 열어서 다른 정보를 첨부합니다. Resolved / Reopened주기는 QA가 버그가 수정되었다고 만족할 때까지 진행된 다음 티켓을 닫습니다.
따라서 기본적으로 Reopen을 사용하여 티켓을 이미 살펴 보았고 누군가가 티켓을 해결했다고 생각하는 작업을 수행했지만 실제로는 그렇지 않다고 말합니다.
기본적으로 일관성 유형의 것입니다. 버그 (또는 일반적인 문제)는 처음부터 만들어진 경우 "개방"입니다. 이전 처리가 수행 된 후 생성 된 경우 "다시 열기"입니다.
개발자 (또는 문제를 처리하는 사람)에게는 차이가 없어야합니다. issure가 제기되었고 이제 처리되어야합니다.
그러나 뚜렷한 "재 개방"상태는 여러 시나리오에 여전히 유용 할 수 있습니다.
첫째, 품질 보증 프로세스의 작동 여부를 추적하는 방법으로 사용할 수 있습니다. 품질 관리팀이 모든 것을 올바르게 수행 한 경우 버그가 수정 된 후에는 절대 버그가 발생하지 않아야합니다. 따라서 버그가 '재 개설'상태로 설정된 횟수는 QA가 제대로 수행하지 않은 횟수입니다. 이것은 물론 양질의 QA 프로세스가 확립되어 있고 사용자가 프로세스에 적극적으로 참여하고 문제를 "열기"시기와 "다시 열기"시기를 알고 있음을 의미합니다.
또 다른 용도는 버그가 다시 발생할 때 다른 문제를 제기 할 필요는 없지만 이미 존재하는 문제를 추가 할 수 있다는 것입니다 (따라서 문제 기록, 업로드 된 추가 파일, 이전 주석 및 ) 그래도 여전히 "이봐,이 일이 다시 일어난다"라고 표시 합니다 .