우리 회사에서는 여러 팀이 동시에 여러 프로젝트의 다른 구성 요소에 대해 작업합니다. 예를 들어, 한 팀은 일부 프로젝트에 대해 특정 종류의 소프트웨어 (또는 하드웨어)를 만들고 다른 팀은 다른 특정 종류의 소프트웨어를 만들 수 있습니다. 우리는 Jira 프로젝트를 사용하여 특정 프로젝트의 이슈를 호스트하고 다른 팀의 스프린트를위한 Jira 보드를 호스팅합니다.
우리는 프로젝트 전체에서 코드 중복을 피하는 문제에 직면하고 있으며 프로젝트에서 사용하는 핵심 라이브러리 세트를 개발했습니다. 프로젝트를 진행하는 동안 일부 개발자는 자신이 작성한 코드가 더 큰 관심을 가져야하며 핵심 라이브러리로 추출되어야하거나 사용중인 일부 핵심 코드에 버그가 있거나 매개 변수가 더 필요하거나 새로운 기능 ... 이름을 지정합니다.
따라서 핵심 프로젝트의 백 로그에 들어가는 핵심 라이브러리 문제를 만듭니다. 이러한 모든 문제는 핵심 도서관 회의 (일주일에 한 번)에서 검토, 우선 순위 지정 및 추정되며, 향후 스프린트에서 우선 순위 (프로젝트 별 문제와 함께)에 따라 해결 될 것입니다.
우선 순위는 정렬 문제로 이루어지며 정렬 된 문제에 sorted레이블을 붙입니다 (따라서 정렬되지 않은 문제를 검색 할 수 있습니다). 그런 다음 핵심 구성 요소 당 하나의 문제를 백 로그 상단에 수동으로 배치하여 문제를 먼저 해결합니다. 일부 팀은 이러한 문제를 스프린트에 넣을 때 다른 항목을 수동으로 백 로그 상단으로 직접 드래그해야합니다.
이것은 오류가 발생하기 쉽습니다. 기본적으로 우리가 가진 것은 "공개"와 "진행 중"사이의 "정렬 된"및 "추정 된"추가 문제 상태입니다. sorted레이블과 보드에서의 위치를 통해 이것을 반영 하는 것은 다소 번거롭고 오류가 발생하기 쉽습니다. (예를 들어, 누군가가 일부 스프린트에서 문제를 위아래로 움직 인 경우, 이는 핵심 보드에 반영되어 팀이 이전에 광범위한 토론에서 결정했을 수있는 문제의 순서를 조용히 뒤흔들 것입니다.)
그렇다면 이것을 구현하는 더 좋은 방법은 무엇입니까?