이슈 트래커의 백 로그를 관리하는 방법

우리는 몇 년 동안 Trac을 현명하게 사용했으며, "액티브 티켓"목록은 거의 200 개로 늘어났습니다. 여기에는 우선 순위가 너무 낮아 현재 해결하기에 너무 복잡한 버그, 지연된 기능 요청, 실제로 불만을 생성하지 않은 문제가 있지만 모두 언젠가는 수정해야하며 계획된 코드 리팩토링 및 기타 설계상의 불필요 함이 포함됩니다. t 등을 잃고 싶다

결과적으로 이러한 문제 중 거의 200 개에 달하는이 목록은 거의 압도적입니다. 더 이상 현재 작업해야 할 소스로 유용하지 않습니다.

이런 종류의 문제를 추적하는 가장 좋은 방법은 무엇입니까?

문제의 일부는 이러한 문제 중 일부는 우선 순위가 낮아서 절대로 완료되지 않을 수 있다는 것입니다. 나는이 물건들을 추적하는 것을 싫어한다. (언젠가 필요할 수도 있기 때문에 내 집에서 무언가를 버리고 싶지 않은 것과 비슷하다); (원톤으로 표시하여) 관계없이 버리고 나중에 필요할 때 찾을 수 있다고 가정합니까?

먼저, 각 개발자가 각 항목을보고 각 항목을 검토 / 테스트하여 여전히 문제인지 확인하십시오 (사람들간에 분할하는 것이 가장 효과적 일 수 있음). 그런 다음 더 이상 문제가되지 않거나 다른 개발 노력으로 이미 처리 된 사항은 모두 닫으십시오.

이제 각각 큰, 중간 또는 작은 개발 노력으로 표시되어 있는지 확인하십시오. 이것은 프로젝트를보다 쉽게 ​​분류하고 사물을 정리하는 데 도움이되는 매우 대략적인 추정치입니다. 모든 것이 이미 추정된다면 도움이 될 것이지만 시간에 걸리지 마십시오. 그냥 빠른 내장 검사와 함께 가십시오. 그것은 종종 방에 개발자를 데려 가고 각 항목을 살펴보고 대다수 사람들이 적절하다고 생각하는 노력을 사용합니다.

세 가지 노력 그룹 각각을 검토하고 그룹의 각 항목을 중요, 높은 비즈니스 가치, 높은 기술적 가치, 중간 가치, 낮은 가치 및 절대 고칠 수 없음으로 표시하십시오.

이 시점까지, 당신은 목록을 실제로 알고 있으며 백 로그와 관련된 작업을 실제로 이해하고 실제로 아이템으로 무엇을해야할지 결정할 수 있습니다. 절대로 고칠 수없는 것으로 표시된 모든 항목을 백 로그에서 보관하십시오.

이제 항목을 다음 릴리스로 예약 할 때 중요하고 중요한 항목을 릴리스의 핵심으로 사용할 수 있습니다. 개발자가 이미 시스템의 해당 부분에서 작업하고 있으므로 우선 순위가 중간 인 항목 목록을 검토하고 목록의 다른 항목과 동시에 작업 할 수있는 항목을 추가하십시오.

우선 순위가 중간 또는 낮음으로 표시된 항목 목록은 사람들이 약간의 여유 시간이있을 때 작업 할 항목 목록 또는 신입 사원 교육으로 사용할 수 있습니다. 나는 항상 반복 할 때마다 한 명의 팀원이이 아이템들을 다루고 필요할 때 나머지 팀을 돕는 것이 좋다는 것을 알게되었습니다. 이런 식으로 현재 반복 작업을 계속하고 있지만 유연하고 필요할 때 불을 끄는 데 도움을 줄 수 있지만 일반적으로주의를 기울이지 않는 문제를 처리하는 사람이 있습니다.

우리가 발견 한 한 가지 좋은 점은 각 반복 사이에 전체 팀이 작은 개발 노력으로 표시된 항목에 대해서만 작업 할 수있는 짧은 2 주 기간이 있다는 것입니다. 짧은 시간에 많은 수의 티켓을 마감하는 데 집중할 것입니다.

Trac에 우선 순위 설정이 있습니까? 주요 쇼 스토퍼의 경우 1, 언젠가 해본 것이 좋은 것들의 경우 5 정도?

우선 순위를 기준으로 정렬 할 수 있으면 우선 순위가 낮은 항목은 무시해도됩니다.

읽는다 : http://en.wikipedia.org/wiki/5S_%28methodology%29

다락방에 넣고 1 년을 기다린 다음 집을 옮기십시오. 그게 내가하는 일입니다.

심각하게 고치지 않으면 잊어 버리십시오. 익스트림 프로그래밍을 참조하십시오.

그러나 코드에 대한 항목. 사소한 관찰로 코드 검토 시스템에 넣을 수 있습니다. 이 시스템은 시스템의 해당 부분을 편집 할 때 문제를 표시하도록 설정할 수 있습니다. 나는 이것이 동료로서 효과가 없다는 것을 알았고 이것이 이것이 예상 된 것으로 생각했으며 리뷰 관찰을 다루지 않았다.

그것을하는 유일한 방법은 무자비한 우선 순위 결정입니다. 지금 또는 귀찮게하지 마십시오.

이것은 실제로 워크 플로 및 비즈니스 우선 순위의 문제만큼 버전 관리 문제가 아닙니다. "고정"될 가능성이 적더라도 몇 가지 이점이 있지만 잘못된 것으로 알려진 것을 추적하는 것이 좋습니다. 우선 QA (별도의 QA 팀이있는 경우)는 새로운 버그를 기록하지 않는다는 것을 의미합니다. 또 다른 이점은 새로운 문제가 발생하지만 근본 원인이 "우리가 알고 있지만 우선 순위가 낮은"문제 중 하나에 기인 한 경우 수정에 대한 모든 분석이 이미 추적되어 더 새롭고 높은 버그의 우선 순위 버전은 수정하기가 훨씬 쉽습니다.

이것의 또 다른 측면은 현재 또는 미래에이 작업의 일부를 다루는 약간의 여지가있을 수 있다는 것입니다. 언젠가 인턴이 될 수도 있고, 코드베이스에 발을 적시 게하는 소개로 간단한 것들을 할당 할 수도 있습니다.

개발자가 이러한 문제를 해결하는 것이 좋다고 생각하는 경우 (예 : 기술 부채를 나타내는 경우) 코드베이스를 사용하여 문제를 해결하기가 더 쉬워 지지만 비즈니스 가치가없는 경우에는 논의 할 가치가 있습니다. 비즈니스 이해 관계자와 함께 이러한 백 로그 항목이 때때로 수령되는 계약에 도달 할 수 있는지 확인합니다. 스크럼 팀이 "기술 백 로그"항목에 대해 스프린트 당 3-5 포인트 속도를 차단하는 것과 같은 작업을 수행하는 것을 보았습니다. 개발 팀과 비즈니스 이해 관계자와의 관계에 따라 정치적 벌금이 필요할 수 있습니다. 잘 작동합니다.

이것은 실제로 몇 가지에 달려 있습니다.

1. 팀 규모 : 팀이 충분히 큰 경우 우선 순위가 낮은 항목을 완료 할 수있는 방식으로 티켓을 할당 할 수 있습니다.
2. 릴리스 빈도 : 릴리스주기가 충분히 길면 모든 티켓이 해결 될 때까지 더 많은 항목을 추가하거나 릴리스를 보류 할 수 있습니다.