백로그 정리 및 예상
제품 소유자는 제품에 대한 상위 수준의 계획 작성 후 agile 규칙에 따라 백로그를 정리 하 고 항목을 예측 팀을 충족 합니다.하면 백로그 보다 세부적인 항목을 정의 하 여 추가 연구와 같은 또는 주소 해결 되지 않은 버그를 나타낼 추가 항목 작업 정리 합니다.팀 노력 수준을 예측 하기 전에 각 항목에 대해 성공을 의미에 동의 해야 합니다.
이 주제를 계속 한 자습서 제품 백로그와 스 프린트 사이클 agile 규칙에 따라 실행을 만드는 과정 가상 파이버 Fabrikam 팀의 멤버를 따릅니다.팀 Team Web Access 백로그 및 작업 보드 페이지를 사용합니다.
제품 소유자로 줄리아 캡처된 그녀의 높은 수준의 비전과 로드맵을 고객 지원 포털에 대한 일련의 백로그 항목에 설명 된 대로 제품 백로그에 추가 또는 만들기.이제 팀 정리 하 고 백로그를 예측할 수 있습니다.
[!참고]
Visual Studio Scrum 2.0 프로세스 템플릿을 사용 하는 경우 만들는 제품 백로그 항목 사용자 스토리, 요구 사항 또는 프로젝트의 결과물 일부를 설명 합니다.Agile 소프트웨어 개발용 MSF를 사용 하는 경우 만들는 사용자 스토리.MSF CMMI 프로세스 개선에 사용 하는 경우 만들는 요구 사항.
항목 내용
승인 기준을 검토 하 고 노력을 예측
캡처 스파이크 또는 비 스토리 작업 백로그
추정을 위한 추가 리소스
요구 사항
이 항목의 절차를 수행 하려면 다음이 있어야 합니다.
Visual Studio Premium, Visual Studio Ultimate 또는 Visual Studio Test Professional.
팀의 구성원 있어야 하 고 있어야 합니다의 이 노드의 작업 항목 로 권한 설정 허용.팀 그룹의 구성원 이므로 기본적으로 팀의 모든 구성원이이 권한이 있는 참가자 팀 프로젝트의 그룹입니다.
볼 수는 백로그 에 속해 있어야 페이지를 여는 전체 Team Web Access에 액세스 그룹.
자세한 내용은 내 프로필 관리 및 내 권한 보기 및 Team Web Access의 기능에 액세스을 참조하십시오.
승인 기준을 검토 하 고 노력을 예측
제공할 자세히 원하는 뿐만 아니라 백로그 항목 또는 버그를 설명 하지만 항목이 행 여부 또는 버그를 확인 하는 데 사용할 조건을 설명 하는 수정 되었습니다.승인 기준을 잘 정의 되 면 팀 후 공동으로 각 백로그 항목이 채택한 어떤 프로세스에 따라 예상할 수 있습니다.
.png "백로그 항목의 승인 기준 및 활동")
열기 Team Web Access팀 프로젝트 또는 팀에 대한 홈 페이지를 탐색 하 고 선택 보기 백로그.
검토 또는 선택 및 Enter 키를 눌러 작업 항목을 두 번 클릭 합니다.
검토 및 업데이트는 설명 및 승인 기준 팀의 합의 백로그 항목 또는 버그에 대한 필드.
.gif "팁")
팁이 필드 이름을 예를 들어, 팀 프로젝트를 만드는 데 사용 된 프로세스 템플릿에 따라 다를 수 있습니다 승인 기준 설명 또는 설명.
수용 기준에 대한: 반복 또는 스 프린트의 끝에서 고객 또는 제품 소유자 사용자 스토리를 완료 하는 것에 동의 이나 거부 합니다.스프린트가 시작되기 전에 고객 승인의 기준을 가능한 한 명확하게 기술해야 합니다.물론 예상 하지 못한 이유로 사용자 스토리가 수락할 수 있습니다.그러나 고객 승인 기준을 정의 하 고 팀 간 대화 팀에서 고객이 원하는 바를 이해 하도록 하는 데 도움이 됩니다.사용자 스토리를 사용한 작업의 완료 여부를 보다 효율적으로 평가할 수 있도록 이 승인 기준을 승인 테스트의 기초로 사용할 수 있습니다.
값을 입력 추정 방법에 따라 팀에서 사용 하는 작업량.프로젝트 초기에 대략적인 예상을 해야합니다.
[!참고]
이러한 필드 이름을 예를 들어, 팀 프로젝트를 만드는 데 사용 된 프로세스 템플릿에 따라 다를 수 있습니다 노력 스크럼에 대한 스토리 점수 for Agile, 및 크기 CMMI에 대한.
스토리 점수에 대한: 자신의 책에서 민첩 한 예측 및 계획, Mike cohn은 스토리 점수를이 이렇게 정의: "스토리 점수는 사용자 스토리, 기능 또는 다른 작업의 전체 크기를 나타내는 측정 단위입니다." Cohn 스토리 점수의 상대 값을 특정 시간 수로 직접 변환 되지 않는 설명 합니다.대신 스토리 점수를 사용하면 팀에서 사용자 스토리의 일반적인 크기를 수치화할 수 있습니다.이러한 상대적 예측 방법은 정확도가 떨어지므로 쉽게 확인할 수 있으며 시간이 지날수록 좋아집니다.스토리 점수로 예측하면 팀에서는 지금 사용자 스토리의 일반적인 크기를 제공하고 나중에 팀 멤버가 사용자 스토리를 구현할 때 작업 시간을 보다 자세하게 예측할 것입니다.자세한 내용은 추정을 참조하십시오.
선택 된 저장 하 고 닫습니다 단추.
캡처 스파이크 또는 비 스토리 작업 백로그
때때로 팀 즉 직접 구현이 아닌 사용자 스토리 또는 제품 요구 사항의 작업을 수행 해야 합니다.이 작업을 스파이크라고 합니다.일반적인 스파이크 유형으로는 조사, 수정해야 할 버그, 프로세스 또는 엔지니어링 개선의 세 가지가 있습니다.스파이크를 만들려면 Team Foundation백로그 항목 또는 사용자 스토리를 만들 필요에 따라 "스파이크" 제목에 포함 한 다음 제품 백로그에서 사용자 스토리와 함께 우선 순위를 지정 합니다.
.png "제품 백로그 페이지에 패널 추가")
제품 백로그 페이지에서 [추가] 패널에는 설명에 입력은 제목 완료할 수 및 다음을 선택 하는 데 필요한 스파이크 또는 비 스토리 작업 시간 필드는 추가 단추.
팁[추가] 패널에 표시 되지 않으면 선택의 추가 항목을 디스플레이 켜려면 연결.
비 스토리 작업에서 다음과 같은 작업에 대한 정의 고려 하십시오.
리서치: 팀 사용자 스토리 완벽 하 게 작업으로 세분 하 여 수 추정 하기 전에 응답 해야 사용자 스토리의 미해결 질문이 있으면 질문에 대답 하는 데 필요한 연구를 예측 해야 합니다.예를 들어 검토 시 팀 판단 하는 이야기를 "단골 승객, 내가 수 북 탑승권" 몇 가지 답변 되지 않은 질문 했습니다.팀의 항목을 만드는 "팀 구성원으로 어떤 '보너스 탑승권 예약' 수단. 이해할 수 있습니다" 스파이크를 나타내도록 합니다.팀 들은 다른 백로그 항목 예상 대로 같은 단위로 필요한 리서치 작업을 예측 합니다.
.gif "중요")
중요팀 연구 완료 될 때까지 연구를 필요로 하는 백로그 항목의 현재 반복에 추가 되어야 합니다.연구 작업 및 백로그 항목 이후 별도 반복에서 발생 하도록 예약 해야 합니다.
버그 부채: 찾을 때 버그를 수정 하는 가장 좋은 시기입니다.같은 날에 하는 것이를 해결할 수 없는 경우 트랙의 잃어버린 있도록 버그 작업 항목을 만듭니다.버그가 누적되지 않도록 주의해야 합니다.팀이 누적 되 면 버그, 사용자 스토리를 만들고 상용구를 예상 하 고 다른 사용자 스토리 및 스파이크와 함께 우선 순위 수 있도록 버그를 스파이크에 연결 합니다.
프로세스 또는 엔지니어링 개선: 팀 프로세스 또는 엔지니어링이 성공에 도움이 되는 개선 작업을 수행 합니다.이러한 향상 된이 기능에 종종 매일 scrum 회의 중 이나 스 프린트 회 고 식별 됩니다.예를 들어 단위 테스트를 통해 코드 검사를 개선하거나 연속 통합 서버에서의 빌드 시간을 줄여야 할 수 있습니다.
각 상용구 또는 팀을 캡처하는 비 스토리 작업 항목에 설명 된 대로 2-5 단계를 수행 "승인 기준을 검토 하 고 노력을 예측" 팀 수행 해야 하는 작업을 이해 하 고 작업을 예측 해야 합니다.자세한 내용은 제품 백로그에 추가 또는 만들기을 참조하십시오.
추정을 지원 하기 위한 추가 리소스
민첩 한 추정 방법에 대한 자세한 내용은 다음 리소스를 액세스할 수 있습니다.
Agile 추정: 민첩 한 예상 Mike cohn은 웹 사이트에서 프레젠테이션을 제공 합니다.
이 자습서에서 관련된 항목
Home | 백로그를 작성 합니다. | 보기 및 Kanban 보드를 백로그 관리 | 반복 계획 | 반복 실행 | 반복을 완료