빌드 및 제품 백로그 관리 합니다.

아티클
02/21/2013

Mitch Lacey 작성.Agile 및 Scrum 채택과 개선을 전문으로 하는 컨설팅 기업인 Mitch Lacey & Associates, Inc가 소유자입니다.

2012년 1월

이 문서에서 Mitch Lacey는 제품 백로그의 중요도와 좋은 백로그에게 필요한 사항에 대해 설명하고 백로그를 만들어 유지하기 위한 몇 가지 모범 사례를 제공합니다.

적용 대상

응용 프로그램 수명 주기 관리; Team Foundation Server

이 문서의 내용:

소개
제품 백로그
- 사용자 스토리.
- 추정
- 우선 순위 지정
살아 있는 제품 백로그
- 정리
결론

제품 백로그는 프로젝트를 완료하는 데 필요한 모든 특성과 기능의 우선 순위 목록입니다.좋은 제품 백로그는 제대로 기능하는 모든 agile 팀의 핵심이며 다음과 같은 특징이 있습니다.

팀이 가장 중요한 기능을 먼저 빌드할 수 있도록 우선 순위가 지정됩니다.
제품 소유자에게 명확한 설명을 제공하여 "이러한 스토리는 언제 수행합니까?" 같은 질문을 할 수 있도록 팀에서 추정합니다.
프로젝트를 완료하는 데 필요한 모든 작업을 포함합니다.
이것은 살아 있는 문서이며 프로젝트의 현식을 반영하기 위해 끊임 없이 변화하고 발전합니다.

좋은 제품 백로그라고 해서 자동으로 좋은 소프트웨어가 되는 것은 아닙니다.그러나 좋은 제품의 백로그 부족은 고객 및 이해관계자의 요구 사항을 충족하지 않는 불완전한 소프트웨어를 만듭니다.

제품 백로그 관리는 정규직입니다.간단한 기술로 과도하고 시간이 많이 걸리는 프로세스를 팀 구성원, 고객 및 이해 관계자를 효과적으로 관련시키는 대화형의 반복적인 프로세스로 변경할 수 있습니다.따라서 확실한 기술을 학습하여 제품 백로그를 빌드하고 우선 순위를 지정하고 유지하는 데 필수적입니다.

제품 백로그

제품 백로그는 프로젝트를 완료하는 데 필요한 모든 특성과 기능의 우선 순위가 부여된 작동 중인 마스터 목록입니다.제품 백로그는 일반적으로 요구 사항을 사용자 스토리 포함 (e.g. 요구 사항), 버그, 리서치 작업 (스파이크) 및 엔지니어링 개선.이러한 항목은 종종 스토리 점수라고 하는 추상 단위로 예측됩니다.

제품 백로그는 프로젝트가 필요로 하는 모든 작업을 포함하여 시간이 지남에 따라 발전합니다.따라서 거기에는 제품의 새로운 기능 뿐만 아니라 버그 수정과 리서치를 포함합니다. 모두 팀에서 시간을 들여야 하는 일입니다.팀에서 수행하는 모든 작업은 제품 백로그에서 가져와야 합니다. 이것은 프로젝트의 시작점입니다.제품 백로그가 모든 작업을 포함한다면 제품 소유자, 팀 및 관리자는 긴박한 문제들이 감소하는 작업 환경을 가질 수 있습니다.

어떤 프로젝트든 시작할 때 측정과 우선 순위 지정 준비가 완료된 깔끔하고 잘 정의된 제품 백로그 항목을 가지고 있을 가능성은 희박합니다.대신 스토리 참고 카드 그리고 하나의 기능 명세서 또는 두 개가 있을 수 있습니다.제품 소유자로서 팀이 백로그 예측을 시작할 수 있도록 엉망인 상태가 어느 정도 질서를 잡을 수 있게 만들 책임이 있습니다.

사용자 스토리.

첫 번째 단계는 모든 아이디어와 메모를 구현에 대한 자세한 내용이 아니라(이러한 요구 사항을 충족하는 소프트웨어를 만드는 방법) 최종 사용자가 원하는 기능(소프트웨어가 수행해야 하는 사항)을 설명하는 사용자 스토리로 변환하는 것입니다.각 사용자 스토리의 제목은 다음 형식을 따릅니다. "<사용자>로서 다음과 같은 <이유>로 <기능>을 원합니다."

스토리 카드 예제

제품 백로그처럼 각 사용자 스토리는 시간이 지남에 따라 발전할 것입니다.프로젝트가 진행되는 동안 팀에서는 이러한 스토리에 우선 순위를 부여하고 추정하여 정보를 추가한 후 보다 작은 스토리로 세분하거나 모두 삭제합니다.스프린트에 가져온 것들은 구현되어 고객에게 전달됩니다.

사용자 스토리에 대한 추가 정보를 보려면 제품 백로그에 추가 또는 만들기 및 Powerpoint를 사용 하 여 백로그 항목 스토리을 참조하십시오.

모든 아이디어와 메모를 사용자 스토리로 변환한 후에는 예측하고 우선 순위를 정합니다.

추정

정의에 따라 예측은 부정확합니다.그러나 당신은 시간, 연습, 전체 팀의 참여를 통해 보다 정확한 추정치를 예측할 수 있습니다. 첫 번째 단계는 제품 백로그 항목 추정치를 제공하도록 팀 참여시키는 것입니다.팀에서 각 스토리를 추정하면 상대 크기 추정치에 스토리 점수라는 추상 측정 단위가 제공됩니다.

예측은 다음 두 가지 이유로 중요합니다.

이들은 “언제 완료되나요?”라는 질문에 답변하는 데 도움이 되었습니다.
이들은 제품 소유자가 각 항목의 우선 순위를 결정하는 데 도움을 줍니다.

추정치는 제품 소유자와 팀에게 제품 소유자가 스토리의 상대 우선 순위를 지정하는데 도움이되는 특정 스토리 비용 개념을 제공합니다.항목의 측정치가 클수록 시간과 리소스 측면에서 항목을 구현하는 데 소요되는 비용도 비쌉니다.따라서 높은 비용일 경우 제품 소유자의 위시 리스트에 있는 높은 항목의 우선 순위에 저하될 수 있습니다.

팀은 스토리 포인트 측면에서 작업을 예상하는 데 계획 포커, 큰 벽 또는 다른 기술을 사용할 수 있습니다.추정 기법 및 스토리 포인트의 빠른 정보에 대한 자세한 내용은 추정 및 백로그 정리 및 예상을 참조하십시오.

팀이 모든 스토리를 예상한 후 우선 순위를 지정할 때입니다.

우선 순위 지정

모든 제품 백로그는 비즈니스 가치와 위험에 따라 우선 순위를 지정합니다.제품 소유자는 상대 우선 순위를 결정하기 위해 다른 소유자에 대해 백로그에 각 항목을 비교합니다.이를 위해 제품 소유자는 각 항목의 크기, 비즈니스에 대한 가치 및 관련 위험을 고려합니다.항목은 우선 순위의 내림차순으로 정렬됩니다.우선 순위가 높은 항목은 제품 백로그의 최상위 또는 상위에 있고, 우선 순위가 낮은 항목은 최하위 또는 하위에 있습니다.팀은 가장 중요한 항목을 먼저 완료할 수 있도록 가장 중요한 우선 선위 항목에서 예정된 스프린트에 대해 작업을 선택합니다.

백로그의 모든 항목 크기가 같지 않습니다.일부는 하나의 스프린트에서 완료 될 수 있지만 다른 것은 너무 커 구현하는 데 관련된 내용 또는 구현에 소요될 시간을 정확히 확인할 수 없습니다.괜찮습니다.항목이 백로그의 상단으로 이동할수록 팀에서 항목을 더 작고 더 집중적으로 만들어 모두가 앞으로 수행할 스프린트 작업을 더 잘 이해할 수 있게 합니다.

예상과 마찬가지로 초기 제품 백로그의 우선 순위 지정은 무모할 수 있습니다.어떻게 경쟁 당사자 요구를 효과적으로 균형 조정하면서 최종 제품, 위험 및 비용을 고려하십니까?다행히 몇 가지 기술을 작업 혁신 게임 및 상대적 가중치를 포함 하 여 쉽게 있습니다.이 사항과 다른 기술에 대한 자세한 내용은 우선 순위 지정 및 백로그 정리 및 예상을 참조하십시오.

선택한 우선 순위 지정 방법이 무엇이든 팀에서 대부분의 가치를 비즈니스, 이해 관계자 및 고객에 제공하는 기능을 작성할 수 있도록 작업을 주문해야 합니다.작업 우선 순위를 지정하지 않았다면 높은 우선 순위를 가진 스토리 대신에 낮은 우선 순위를 가진 사용자 스토리 전달 위험을 증가시키고, 리소스 및 일정을 변경할 때 사용자 스토리를 완성하지 마십시오.

(백로그 항목의 특성에 대한 자세한 내용은 제품 백로그에 추가 또는 만들기 and Agile 계획 및 반복를 참조하십시오.)

살아 있는 제품 백로그

지금까지 설명한 것은 아무 것도 아닌 것에서 추정된 또는 우선 순위가 지정된 제품 백로그로 이동에 중점을 두었습니다.요구 사항 문서와 달리 제품 백로그는 제품 시작 시 만들어 지지 않고 선반에 남게 됩니다.대신, 제품 백로그는 프로젝트의 현실에 따라 확장 및 축소되면서 발전합니다.일부 제품 백로그 항목은 관련이 없으며 제거해야 합니다.다른 것들은 표면으로 버블링되고 더 작은 스토리로 구분해야 합니다.새 사용자 스토리는 추가 요구 사항이 발생할 때 추가, 예측 및 우선 순위 지정됩니다.

팀과 이해 관계자는 제품 백로그를 만들고 관리하는 데 관여하지만 제품 소유자는 이에 대해 궁극적인 책임을 집니다.제품 소유자는 백로그를 정리하고 우선 순위를 부여하며 업데이트하여 고객과 팀이 프로젝트 릴리스에 대한 작업 계획에 대한 명확한 그림을 가질 수 있도록 해야 합니다.프로젝트가 한창 진행된 후에도 제품 소유자에게는 제품 백로그를 제대로 유지하기 위한 많은 일들을이 있습니다.

새 스토리 추가 및 우선 순위 지정
팀이 더 잘 이해할 수 있도록 팀에게 새로운 스토리를 예측하도록 요청하고 기존 스토리를 다시 예측하기
필요에 따라 항목을 세분화하기 위해 예정된 사용자 스토리를 팀과 함께 검토
고객 및 관계자와 만나 요구 사항을 검토하고 추가

누구나 제품 백로그에 항목을 언제든지 추가할 수 있지만 제품 소유자만 항목의 우선 순위 지정할 수 있습니다.제품 소유자는 스토리에 우선 순위를 할당할 수 있는 유일한 사용자입니다.해당 정보에 대한 메시지를 표시하는 전자 도구를 사용하는 경우에도 팀의 모든 구성원과 관련자는 스토리를 추가할 때 우선 순위 영역을 빈 상태로 남겨 두어야 합니다.

스토리가 추가되면 제품 소유자는 이해를 바탕으로 우선 순위의 예비 평가를 수행합니다.그는 스토리를 더욱 잘 이해하기 위하여 스토리 창시자와 함께 토론을 할것이고, 점차적으로 그는 팀원들의 질문에 대답을 할 수 있습니다.각 스프린트마다 미리 정해진 시간에 제품 소유자는 새 스토리를 설명하고 백로그의 여러 스토리와 비교하여 보다 정확하게 우선 순위를 정할 수 있도록 협력하여 새 스토리를 예측하기 위해 팀과 만남을 갖습니다.이 프로세스는 백로그 정리라고 합니다.

정리

제품 백로그 정리는 이전에 언급한 것처럼 정기적으로 수행해야 합니다.

Scrum에서 팀은 정리 활동에 각 스프린트 시간의 5%-15%를 소비해야 합니다.팀은 내용과 변경을 이해하여 우선 순위에 따라 모든 스토리를 나누고 작성된 모든 스토리를 예상하며 발생할 스토리에 대한 긴급한 디자인 및 계획을 수행해야 합니다.이런 상황을 발생시키려면 제품 소유자와 팀은 각 스프린트 계획 회의 동안 스프린트에서 약간의 시간을 할당하여 백로그를 함께 정리해야 합니다.스프린트 계획에 대한 자세한 내용을 보려면 스프린트 계획 및 반복 계획를 참조하십시오.

2주 스프린트 동안 두 번째 주에 이 회의를 개최하고 싶습니다.이는 고객 및 이해 관계자와 의미 있는 대화를 나누고 비즈니스의 어려움을 이해하며 우선 순위에서 신규이거나 상승하는 사용자 스토리와 스토리를 명확하게 할 수 있는 충분 한 시간을 제품 소유자에게 제공합니다.다가올 스프린트에 참가하기 시작할 스프린트 동안 논리적인 시간이기도 합니다.회의를 개최할 시기를 결정할 수 있습니다.중요한 점은 정리 활동을 완료하도록 스프린트 동안 충분한 시간을 할애하는 것입니다.

일반적인 그루밍 회의 과정에서 제품 소유자는 차후 몇몇 스프린트에 대한 새로운 점, 변경 사항 및 계획에 대해 제시합니다.새로운 스토리를 추정하고 빨리 완료하여 스토리를 세분화하는 것과 더불어 팀은 현재 시스템 구조를 검토하고 새로운 기능을 계획하고 디자인하는 것에 회의 시간을 할애합니다.이 과정에서 스토리는 잦은 변경이 예측되며, 새 스토리는 더 큰 스토리가 작은 스토리로 분할되는 것으로 나타나는 경향이 있습니다.

이 프로세스는 간단해 보이지만 약간 어려울 수 있습니다.작업이 원활하게 실행되도록 하려면 제품 소유자는 질문에 답변할 준비를 해야 합니다.예를 들어, 제품 소유자가 다음 스프린트에서 스토리를 끝낼 계획이지만 팀이 양호한 추정치를 제공하는데 필요한 명확성을 제공하지 못하는 경우, 충돌이 발생할 수 있습니다.만약 이것이 스프린트 계획 회의 중에 발생하였다면, 스크럼 마스터는 제품 소유자가 고객과 이해 관계자로부터 어떤 정보를 얻어 팀에 전달해야 하는지 코치해야 합니다.

모든 정리 회의가 끝날 때 새로운 것과 앞으로 변경될 것, 릴리스 계획 업데이트를 모두가 확인할 수 있도록 제품 소유자가 관련자와 고객에게 변경 내용을 공지해야 합니다.

좋은 제품 백로그를 통해 작성한 소프트웨어에 고객 및 이해 관계자와의 대화에서 식별되고 사용자 스토리에서 정의되는 가장 중요한 특성이 포함될 수 있습니다.좋은 제품 백로그를 만들고 유지하기 위해서 모든 스프린트를 기반으로 하여 이해관계자/고객 그룹과 팀이 적극적인 관계를 유지해야 합니다.

좋은 백로그 빌드하는 것이 좋은 시스템을 보장하지는 않습니다. 하지만 좋은 백로그가 없으면 궁극적으로 시스템에서 고객이 요청하는 것을 거의 수행할 수 없습니다.즉, 백로그를 최신 상태로 유지하지 않으면 거의 항상 프로젝트 오류가 발생합니다.

제품 소유자는 정규직이며 백로그가 이들의 책임입니다.역할을 진지하게 수행하십시오.제품 백로그를 양호한 상태로 유지하면 고객이 고마움을 느낄 것입니다.