대규모 제품 백로그를 어떻게 관리합니까?[닫은]

Question

우리는 소프트웨어에서 수행해야 할 작업에 대해 다양한 범주에 걸쳐 많은 백로그를 보유하고 있습니다. 예를 들면 다음과 같습니다.

• 우리 제품이 해결해야 할 새로운 문제 영역
• 기존 문제 영역을 지원하는 새로운 기능
• 기존 사용자가 요청한 새로운 기능
• 유용성 및 "외관" 향상
• 백엔드 아키텍처 업그레이드
• 버그 수정

이 모든 것을 합리적인 방식으로 관리하는 것은 제품 관리의 업무이지만 여러 가지 이유로 까다롭습니다.첫째, 우리는 다양한 사항(파일의 시장 요구 사항 문서, 버그 데이터베이스의 버그, 헬프 데스크 시스템의 고객 요구 사항, 인트라넷의enginering 희망 목록 등)을 보유하는 다양한 시스템을 보유하고 있습니다.둘째, 많은 항목의 크기, 범위, 복잡성 및 가치가 매우 다르기 때문에 선택이 우선순위에 따라 목록을 주문하는 것만큼 간단하지 않습니다.

현재 우리 회사의 규모가 상당히 크고 복잡한 제품과 많은 고객을 보유하고 있기 때문에 기본 솔루션(스프레드시트, Google 문서, 베이스캠프 할 일 목록)만으로는 이 문제를 처리하기에 충분하지 않습니다.우리는 여러 가지 방법으로 항목을 그룹화하고, 지속적으로 우선순위를 지정하고, 현재 수행 중인 작업과 향후 작업을 명확히 할 수 있는 방법이 필요합니다. 일부 도구를 관리하는 데 누군가의 시간을 쏟지 않고도 가능합니다.

기업이 항상 기존 고객에게 가장 가치 있는 일을 수행하고, 신규 고객 확보를 돕고, 소프트웨어 내부를 정상 상태로 유지할 수 있도록 이를 어떻게 관리합니까?

이는 개발 측면과는 다르다는 점에 유의하세요. 저는 우리가 꽤 잘 해냈다고 생각합니다.우리는 모든 것을 반복적이고 민첩한 방식으로 개발하며, 일단 디자인과 구현을 위해 무언가가 선택되면 그렇게 할 수 있습니다.가장 어려운 것은 다음에 무엇을 해야 할지 알아내야 하는 부분입니다!

효과적인 방법이나 도구를 찾았나요?그렇다면 공유해주세요!(그리고 답변도 알고 싶다면 질문이 계속 표시되도록 평가하세요. :)

부록: 물론 모든 버그를 먼저 수정하는 것은 좋지만 실제로 고객의 컴퓨터에 설치되는 실제 시스템에서는 이것이 항상 실용적인 것은 아닙니다.예를 들어, 매우 드물게 발생하는 버그가 있을 수 있으며 수정하는 데 엄청난 시간과 아키텍처적 격변이 필요할 수 있습니다. 이를 잠시 동안 그대로 둘 수도 있습니다.또는 누군가가 사용하기 어렵다고 생각하는 버그가 있을 수 있으며, 이를 수정하려면 해당 영역이 더 크게 개편될 때까지 기다려야 한다고 생각합니다.따라서 모든 문제를 즉시 해결하는 것이 아니라 잊어버리지 않도록 열어두는 데에는 많은 이유가 있습니다.게다가 가장 어려운 것은 버그가 아닌 것의 우선순위를 정하는 것입니다.아무것도 없다고 상상해 보세요 :)

Answer 1

공격적인 방식으로 대규모 백로그를 관리하는 것은 거의 항상 낭비입니다.우선순위가 높은 더미의 중간에 도달할 때쯤에는 상황이 변경되지 않은 경우가 더 많습니다.Corey Ladas가 우선순위 필터라고 부르는 것과 같은 것을 채택하는 것이 좋습니다.

http://leansoftwareengineering.com/2008/08/19/priority-filter/

기본적으로 크기는 증가하고 우선순위는 감소하는 버킷이 몇 개 있습니다.이해관계자가 스토리를 채우도록 허용하지만 버킷에 여유가 생길 때까지 나머지 스토리를 무시하도록 강요합니다.매우 간단하지만 매우 효과적입니다.

편집하다: Allan은 작업의 크기가 다른 경우 어떻게 해야 하는지 물었습니다.기본적으로 이 작업을 수행하는 데 있어 가장 중요한 부분은 작업 크기를 적절하게 조정하는 것입니다.우리는 이 우선순위를 사용자 스토리에만 적용합니다.사용자 스토리는 일반적으로 "커뮤니티 사이트 만들기"보다 훨씬 작습니다.나는 커뮤니티 사이트를 서사적이거나 심지어 프로젝트라고 생각합니다.우선순위를 지정하려면 훨씬 더 작은 비트로 나누어야 합니다.

하지만 비슷한 크기의 스토리를 만드는 것은 여전히 ​​어려울 수 있습니다.때로는 그렇게 할 수 없기 때문에 계획 결정 중에 이를 전달합니다.

2픽셀 이동하는 위블과 관련하여 이러한 쉬운 작업 중 많은 부분이 "무료"로 수행될 수 있습니다.당신은 이것들의 균형을 맞추는데 주의해야 하며, 그것들이 정말로 무료에 가깝고 실제로 어느 정도 중요한 경우에만 수행해야 합니다.

우리는 버그를 비슷하게 취급합니다.버그는 지금, 곧 또는 결국의 세 가지 범주 중 하나를 갖습니다.우리는 Now 및 Soon 버그를 최대한 빨리 수정합니다. 유일한 차이점은 수정 사항을 게시할 때입니다.결국 개발자가 지루해지거나 할 일이 없거나 어떻게든 우선순위가 높아지지 않는 한 버그는 수정되지 않습니다.

Answer 2

핵심은 공격적인 분류와 우선순위 지정입니다.

고객을 멀리하게 만드는 문제를 신속하게 해결하고 고객이 계속 찾아오도록 더 많은 기능을 추가하세요.수정하기가 매우 쉽지 않은 경우 소수의 사람에게만 영향을 미치는 문제를 푸시백하세요.

Answer 3

간단한 기술은 우선순위 매트릭스를 사용하는 것입니다.

예:

• http://erc.msh.org/quality/pstools/psprior2.cfm

• http://it.toolbox.com/blogs/enterprise-solutions/sample-project-prioritization-matrix-23381

또한 우선순위 사분면(두 가지 차원:중요도, 긴급성) Covey가 제안하는 내용은 다음과 같습니다. http://www.dkeener.com/keenstuff/priority.html.중요하고 긴급한 일에 집중한 다음, 중요하고 긴급하지 않은 일에 집중하세요.중요하지 않은 것...글쎄..누군가가 근무 외 시간에 그렇게 하고 싶다면 :-).내가 사용한 Covey 사분면의 변형은 중요성과 용이성의 차원입니다.용이성은 Covey 사분면 내에서 작업의 우선순위를 지정하는 좋은 방법입니다.

Answer 4

우선 순위를 정할 수 있도록 모든 것을 한곳에 모아야한다고 생각합니다.여러 다른 소스를 대조해야 하면 이것이 사실상 불가능합니다.그런 다음 누군가/그룹이 각 버그, 요청한 기능 및 원하는 개발의 순위를 매겨야 합니다.

우선순위를 정할 수 있는 사항은 다음과 같습니다.

• 제품에 부가된 가치
• 기존 고객과 잠재 고객 모두에 대한 중요성
• 작업 규모

Answer 5

먼저 모든 버그를 수정한 다음 새 기능을 추가하는 방법을 생각해야 합니다.

Answer 6

이 모든 것들은 다음 기능을 갖춘 훌륭한 버그 추적 시스템으로 추적할 수 있습니다.

• 작업 항목을 버그 또는 개선 요청으로 표시하는 기능
• 작업 항목이 속하는 책임 영역에 대한 범주 필드(UI, 백엔드 등)
• 수정 또는 기능이 완료될 예정인 시기를 나타내는 버전 # 필드
• 상태 필드(진행 중, 완료, 확인 등)
• 우선순위 필드

Answer 7

이미 민첩한 방식으로 작업을 수행하고 있으므로 XP에서 몇 가지 아이디어를 빌릴 수 있습니다.

• 놓다 모두 큰 색인 카드 더미(또는 그러한 도구)에 담긴 당신의 이야기
• 이제 개발자는 해당 이야기의 크기를 추정해야 합니다(여기서 개발자가 최종 결정을 내립니다).
• 고객(또는 제품 관리자와 같은 대리인)이 비즈니스 가치에 따라 스토리를 정렬하도록 합니다(여기서 고객이 최종 결정을 내립니다).
• 그리고 개발자가 더 중요한 기술적 문제(예: 성가신 버그 수정)가 있다고 생각하는 경우 이를 클라이언트(비즈니스 사람)에게 전달하고 클라이언트가 우선 순위를 높이도록 해야 합니다(클라이언트가 아직 최종 결정권을 갖고 있음).
• 팀의 속도가 허용하는 만큼 다음 반복을 위해 많은 스토리를 선택하세요.

이 방법:

• 비즈니스 요구 사항에 따라 정렬된 단일 작업 대기열이 있습니다.
• 고객은 투자 대비 최고의 수익을 얻습니다
• 기술이나 전문가가 아닌 비즈니스 가치가 개발을 주도합니다.
• 개발자들은 구현하기가 얼마나 어려운지 말하게 됩니다.
• 만약 없다면 ROI, 작업은 해당 더미의 맨 아래 근처에 유지됩니다.

자세한 내용은 다음을 참조하세요. 익스트림 프로그래밍 계획 ~에 의해 켄트 벡 그리고 마틴 파울러.그들은 내가 할 수 있는 것보다 훨씬 더 잘한다고 말합니다.

Answer 8

도구가 프로세스만큼 중요한지 잘 모르겠습니다.나는 상당히 큰 프로젝트를 관리하기 위해 색인 카드와 화이트보드와 같은 간단한 것을 사용하여 팀이 매우 성공적인 것을 보았습니다.우선순위를 정할 때 제가 추천하고 싶은 한 가지는 이러한 항목의 포괄적인 목록을 함께 가지고 있는지 확인하는 것입니다.이렇게 하면 문제 해결의 우선순위와 해결의 우선순위를 비교할 수 있습니다.새로운 기능 등

Answer 9

도구와 프로세스 외에도 다음이 있어야 합니다.어떤 사람들은 ;)

우리 가게에서는 그를 'A'라고 부른다. 릴리스 관리자 그리고 그는 생산에 투입될 다음 기능 경계를 결정합니다.
그런 다음 동결 관리자 코드와 파일, 버그에 대해 실제로 알고 있는 사람(그는 일반적으로 프로그래머 중 한 명임), 릴리스 관리자의 선택을 강요하고 테스트할 항목을 확보한 후 릴리스하기 위해 필요한 병합을 모니터링합니다.

이 둘 사이에서 높은 수준(기능적 요청)과 낮은 수준(버그 및 기술 문제) 모두에서 우선순위를 설정할 수 있습니다.