defect triaging scrum
결함 심사 소개 :
이전 튜토리얼에서 스크럼 이벤트 소개 – Sprint, Sprint Planning, Daily Scrum, Sprint Review 및 Sprint Retrospection. 우리는 각 스크럼 이벤트에 대한 타임 박스, 참가자 및 활동과 같은 개념에 대해 논의했습니다.
독자를위한 다음 단계는 결함 심사입니다. QA 직원에게는 새로운 개념은 아니지만 결함 심사의 중요성과 스크럼 설정에서 어떻게 구성되는지 이해하려고 노력할 것입니다.
이제 이해부터 시작하겠습니다. '결함 심사 란 무엇입니까?'.
학습 내용 :
결함 심사
결함 분류는 현재 Sprint의 모든 결함을 논의하고 분류하는 공식 회의입니다.
개발 팀의 QA 개발자는 나머지 스크럼 팀에게 결함을 시연하고 설명합니다. 모든 사람의 의견을 바탕으로 결함을 구성하고 여러 범주로 분류합니다.
이러한 결함을 분류하는 데 중요한 결정 요소 중 일부는 심각도, 관련 위험, 비즈니스 영향, 발생, 성격 등이 될 수 있습니다. 이러한 범주를 기반으로 결함을 해결해야하는시기를 결정합니다.
Eclipse에서 Java 애플리케이션을 만드는 방법
참가자
결함 심사 회의는 모든 스크럼 팀 구성원이 참여합니다.
- 제품 소유자
- 스크럼 마스터
- 개발팀
이해 관계자 (내부 또는 외부)도 결함 심사 회의에 포함될 가능성이 있습니다.
이제 결함 심사 회의에서 각 스크럼 팀 구성원의 역할과 책임에 대해 논의하고 명확한 구분을 설정하겠습니다.
역할과 책임
개발팀
- 개발자는 결함을 설명하고 시연합니다.
- 개발자는 또한 근본 원인 분석에 초점을 맞출 것입니다.
- 개발자는 결함의 영향을받는 응용 분야에 대한 통찰력을 제공합니다.
- 결함이 허용 가능한지 또는 거부되어야하는지에 대해 결합 된 호출이 작성됩니다.
- 결함의 우선 순위 지정에 도움이됩니다.
- 결함 수정과 관련된 복잡성을 표현합니다.
- 수정 및 재 테스트를 위해 자체 결함을 할당합니다.
스크럼 마스터
- 스크럼 마스터는 결함 심사 회의를 조직하는 일도 담당합니다.
- 스크럼 마스터는 나머지 팀원의 요청에 따라 회의를 진행할 수도 있습니다.
- 결함 수정을 위해 팀이 직면 할 수있는 장애가있는 경우 메모를 작성하십시오.
- 회의가 시간 제한이 있고 초점에서 벗어나지 않는지 확인합니다.
- 우선 순위 및 심각도를 지정하여 결함을 특정 결함 클래스로 분류합니다.
- 팀과 함께 스크럼 마스터는 개선 영역을 테이블에 제공합니다.
제품 소유자
애자일 스크럼에서 비즈니스 분석가 역할
- 가장 최근의 결함을 해결할 수있는 방법을 결정하는 결함의 우선 순위 지정에 중요한 이해 관계가 있습니다.
- 우선 순위가 중간 인 결함의 경우 제품 소유자는 후속 릴리스에서 선택할 수 있도록 제품 백 로그에 배치 할 계획을 세울 수 있습니다.
- 팀이 결함으로 인해 비즈니스에 미치는 영향을 이해할 수 있습니다.
- 제품 소유자는 최종 사용자의 관점과 감정을 받아들이면서 결함을 논의합니다.
간단히 말해서 결함 심사 프로세스
모든 스크럼 팀원은 결함 심사 회의를 위해 회의실에 모입니다. 개발자 팀의 누구나 주도권을 잡고 결함에 대해 자세히 논의 할 수 있습니다. 그런 다음 팀은 유효성을 위해 각 결함에 대해 논의합니다.
결함이 유효하지 않은 것으로 확인되면 거부됩니다. 결함이 유효한 경우 팀은 결함 수정의 복잡성과 시스템에서 해결되지 않은 상태로두면 비즈니스에 미치는 영향을 확인합니다.
이제 팀의 다른 모든 구성원이 올바른 분류를 위해 버그를 분석 및 평가하고 올바른 우선 순위 및 심각도가 결함에 할당되었는지 확인합니다.
올바른 우선 순위 및 심각도가 지정되지 않은 경우 팀은이를 올바른 우선 순위로 재설정합니다. 이제 팀과 함께 제품 소유자는 우선 순위에서 수정할 결함과 후속 릴리스에 할당 할 수있는 결함을 결정합니다.
결함 분류 회의 중에 전체 스크럼 팀이 결함을 분석하고 평가합니다. 그런 다음 팀은 이러한 결함에 올바른 심각도와 우선 순위를 할당합니다.
토론과 정밀 조사를 게시하면 이제 결함 할당이 완료 될 때가됩니다. 이 활동에서 한 명 이상의 개발자가 결함을 수정하도록 지정됩니다. 결함을 테스트하기 위해 다른 개발자가 지정됩니다.
또 다른 매우 중요한 활동은 각 결함에 대한 근본 원인 분석을 검토하고 시스템에서 유사한 결함이 다시 발생할 가능성을 최소화하기 위해 프로세스 개선 계획을 세우는 것입니다.
이 모든 것은 추적 시스템에 캡처됩니다. Agile에서 작업하는 팀의 경우 JIRA가 가장 좋아했습니다. 따라서 회의가 끝날 때 팀에는 올바른 우선 순위 및 심각도가 지정된 유효한 결함 목록이 있습니다. 팀은 또한 후속 스프린트에 채택되어야하는 프로세스 개선 계획을 가지고 있습니다.
결함 심사 회의는 몇 가지 결함이 발견되어 논의가 필요할 때마다 예약됩니다. 결함 심사 회의가 필요하다고 생각하는 사람은 누구나 회의를 요청할 수 있습니다.
일반적인 상황에서 결함 심사 회의는 스프린트 중에 2-3 번 도움이 될 수 있습니다. 그러나 그것에 대한 규칙은 분명히 없으며 필요할 때마다 회의가 열릴 수 있습니다.
결론
이것이 결함 심사 회의와 관련하여 우리가 준비한 전부입니다. 결함 심사 회의는 스크럼 팀 구성원의 민첩성을 높이기위한 단계적 활동으로 간주됩니다. 그것은 그것이 생산하는 이점으로 인해 스크럼 프로세스의 필수적인 부분이되었습니다.
다음 튜토리얼에서는 자급 자족 스크럼 팀의 중요성에 대해 논의 할 것입니다.
또한 스크럼 설정에서 자급 자족이 의미하는 바와 팀이 자급 자족 팀으로 발전 할 수있는 방법에 대해서도 강조 할 것입니다.
이전 튜토리얼 | NEXT 튜토리얼