내가 일하는 회사의 여러 개발 팀에서 JIRA를 사용할 수 있는지 검토 중입니다. 우리는 스크럼을 프로젝트 관리의 기반으로 사용합니다. 우리는 좋은 자기 조직 팀, 거의 할당 된 작업 등이 없습니다. JIRA는 이러한 항목 중 일부는 훌륭하지만, 우리가 해결해야 할 부분은 프로세스 대 기술적 작업과 "번들 문제"라고 불리는 것을 관리하는 것입니다.프로세스 제어 및 스크럼을위한 JIRA 구현
프로세스 제어. 현재 우리는 "이익과 손실 보고서의 그래프에는 중복 된 범례 텍스트에 문제가 있습니다"라고 말하는 이야기를 작성합니다. 좋아요. 그런 다음 기술 하위 작업을 만들겠습니다. 간결함을 위해 "연구하고 문제를 해결하십시오"라고 가정 해 보겠습니다. 다음으로 우리가 만드는 일련의 프로세스 하위 작업이 있습니다. 피어 리뷰, 빌드 만들기, QA 테스트, 병합, 추적. 그런 다음 각각을 독립적으로 사용자에게 할당하고 스크럼 보드의 보류 저장소에 넣을 수 있습니다 (BTW, 보류 중, 대기중인 작업, 진행 중, 완료, 병합 된 모델 대신 진행 중, 완료됨 모델). 기본적으로 보류 중입니다. 우선 순위가 다음에 오면 기다리고 있습니다. 개발하는 동안 프로그래머는 기술 과제를 잡고 양수인으로 지정하고 진행 중입니다. 작업이 완료되면이를 완료 저장소로 이동 한 다음 피어 검토 프로세스 하위 작업을 "작업 대기 중"으로 업데이트하고 담당자를 코드 파트너로 설정합니다. 이메일을 보내 피어 리뷰가 완료되었습니다. 완료되면 피어 리뷰 파트너는 피어 검토를 완료 저장소로 이동하고 빌드 작성 하위 작업을 빌드 관리자에 설정하고 작업 대기 중으로 이동합니다. 빌드 관리자가이를보고 빌드를 만들고 완료된 후에 QA 테스트 티켓을 작업 대기 중 상태로 업데이트하면 바로 알 수 있습니다.
그것은 효과가 있지만 대안, 모범 사례 등에 대한 제안입니다. 기술 및 프로세스 하위 작업을 만드는 것이 길지 않은가요? 한 가지주의해야 할 점은 하위 작업을 숨기기 위해 이슈 목록을 필터링해야한다는 것입니다. 스크럼 보드는 부모 이야기의 상태를보고 싶어하는 이해 관계자에게 압도적 인 인상을 줄 수 있습니다. 부모 이야기는 하위 작업이 움직일 때까지 움직이지 않기 때문에 하위 작업이 움직이는 동안 이야기가 "진행 중"인 경우에도 관심이없는 내용은 표시되지 않습니다. 응.
문제 묶음. 우리는 종종 긴밀하게 관련되어 있지만 일반적으로 더 일반적인 문제를 가지고 있습니다. 예를 들어, 소프트웨어의 보고서와 관련된 모든 문제. 현재 15 가지 알려진 문제가 있습니다. 이러한 문제는 특정 단계를 재현하는 등 시스템의 여러 보고서에있을 수 있습니다. 우리가 스프린트를 준비 할 때 이러한 관련 문제의 번들을 선택할 것입니다. 그 이유는 QA가 각 보고서를 별도의 프로세스로 테스트하기보다는 한 번에 일반적으로 관련된 작은 수정을 더 효율적으로 테스트 할 수 있기 때문입니다.
현재 각 문제는 번들의 하위 작업으로 이동합니다. 예를 들어, 번들은 간단히 "보고서 수정 1"이라고 불릴 수 있으며, 예를 들어 기술적 인 5 개의 하위 작업이 있습니다. 각 하위 작업은 수정되어야 할 다른 보고서 버그입니다. 그런 다음 위에 나온 프로세스 제어 항목을 전체 번들에 추가 할 수 있습니다. 또한 번들의 모든 항목이 완료 될 때까지 병합되지 않으므로 모두 동일한 버전이됩니다.
그러나 위에 언급 한 바와 같이 하위 작업의 상태가 번들에 포함되므로 쉽게 확인할 수 없으므로 가시성이 떨어집니다.
또 다시 모범 사례입니까? 아이디어? 어떻게 다른 사람들이 이것을 취급합니까?
왜 스크럼을 지원하는 도구를 사용하지 않습니까? JIRA는 [Greenhopper] (https://www.atlassian.com/software/greenhopper/overview)를 사용할 수 있습니다! –