용어개념

먼저 스크럼에서 사용하는 용어들에 대한 정의를 기술합니다.

스프린트

• 계획 회의부터 제품 리뷰가 진행되는 날짜까지의 기간이 하나의 스프린트
• 회사에서 정하는 이터레이션이 개발 주기가 될 수 있음

백로그

• 이슈들을 모아둔 곳

에픽

• 많은 스토리, 작업 단위로 나눌 수 있는 업무의 큰 틀

스토리

• 고객에서 가치를 줄 수 있는 기능을 서술한 것
• 최종 사용자 관점에서의 언어로 작성된 요구사항

태스크

• 개발자가 실제로 작업해야 하는 각각의 단위 작업

버그

• 버그나 문제에 관한 이슈

스크럼은 소프트웨어 개발 프로젝트를 위하여 상호, 점진적 개발방법론이며, 애자일 개발방법론 중 하나입니다. 스크럼 방법론에 기반한 이슈관리 방안을 수립합니다.

개인적인 적용방안

JIRA에서 제공하는 기능은 완벽한 방법이 아니며 반드시 따라야 하는 규칙은 아닙니다. 스프린트를 진행하면서 일이 되는 방향으로 스크럼을 점진적으로 개선하거나 상황에 맞게 적용하는 것이 중요합니다. 현재 JIRA를 처음으로 도입하는 과정이므로 조금 더 직관적이고 복잡하지 않은 방식으로 적용하는 것이 필요합니다.

백로그

• 스프린트를 포함한 모든 이슈들을 볼 수 있는 곳
• 백로그에 보관된 이슈를 현재 스프린트로 올려서 작업

스프린트

• 1주일을 개발주기로 설정하여 스프린트함
• 1주 단위로 태스크를 작업하고 리뷰하도록 함
• 하나의 태스크는 가급적 하나의 스프린트 내에 끝낼 수 있는 범위로 지정
• 태스크가 스프린트 동안 끝나지 않은 경우 다음 스프린트로 연장

이슈

에픽

• 여러 스프린트에 걸쳐 작업되어야 하는 큰 단위의 작업
• 버전보다는 작으면서 최소한 두 세 가지 이상의 작업으로 구성되어야 함
• 먼저 여러 태스크를 생성 후, 관리 차원에서 하나의 에픽으로 묶을 수 도 있음
• 기간을 설정하여 로드맵으로 관리함

태스크

• 에픽의 하위개념으로 들어갈 수 있는 작음
• 가급적 하나의 스프린트에서 해결할 수 있는 양으로 하나의 태스크로 지정
• 태스크는 반드시 브랜치로 생성하여 작업
• 가급적 하나의 태스크는 코드수정 양이 너무 방대하여 코드리뷰가 어려울 정도가 되지 않도록 함

버그

• 고객사에서 발생한 버그수정 작업
• 내부 테스트시 발견한 버그수정 작업
• 관련자, 비관련자 구분없이 버그 발견시 당사자가 이슈로 등록하도록 권장
• 버그는 반드시 브랜치로 생성하여 작업

문서

• 개발에 필요한 문서화 작업
• 실제 문서 작성은 컨플루언스에서 진행하고 최종링크를 Description에 추가

---

이슈 작성 규칙

에픽

• 특별한 규칙없이 간결하게 작성
• 날짜범위를 지정하여 로드맵에서 관리

태스크, 문서

작업범위

• 작업(개발)할 내용들을 간략히 나열함

작업결과

• 모든 작업이 완료된 이후 종합적인 작업내용을 작성
• 문서의 경우는 컨플루언스 링크, 개발의 경우 PR 링크

댓글

• 개발진행 상황을 댓글을 상시로 기록을 권장 (최소 하루에 하나 이상)
• 보고의 의도가 아닌, 개발 히스토리를 남기고, 개발 진행시 필요한 내용들을 중간중간 메모해두는 용도
• 비교적 자유로운 형태로 사용

버그

• 태스크와 동일하되 재현방안과 재현환경을 추가됨