agile planning with microsoft team foundation server
이 자습서에서는 프로젝트 관리자가 팀 전체에서 작업을 계획하고 추적하는 데 도움이되는 Microsoft TFS를 사용하여 Agile Planning을 수행하는 방법을 설명합니다.
예제와 함께 유닉스의 정렬 명령
DevOps의 SoftwareTestingHelp.com에 게시 된 다양한 기사 중에서 Microsoft TFS, AWS 및 확실히 Ansible과 같은 오픈 소스 도구를 사용한 지속적 통합 및 지속적 배포의 관점에서 DevOps에 대한 좋은 기사를 보았습니다.
DevOps의 전제 조건 중 하나는 전체 SDLC 프로세스에 민첩성을 제공하는 AGILE과 같은 강력한 프로세스로, 초점 영역은 짧은 릴리스주기와 빠른 피드백으로 매우 적시에 소프트웨어를 릴리스하는 것입니다. 즉, 애자일 프로세스는 주로 속도에 중점을 둡니다.
학습 내용 :
Microsoft TFS 2017을 사용한 애자일 계획
이 기사의 다른 섹션을 살펴보기 전에 다음 중 일부를 알아 두는 것이 좋습니다. Agile에서 사용되는 중요한 용어입니다. 이러한 용어는이 기사 전체에서 사용됩니다.
전제 조건 : Microsoft TFS 2017
SCRUM 프로세스 템플릿을 사용하여 TFS 팀 프로젝트 만들기
먼저 아래에 언급 된 단계에 따라 SCRUM 템플릿을 사용하여 TFS 팀 프로젝트를 만드는 것으로 시작합니다.
Microsoft TFS 2017에 로그인하고 새로운 프로젝트.
프로젝트 이름을 입력하고 스크럼 템플릿으로. 클릭 창조하다.
프로젝트가 생성되면 버튼을 클릭하여 프로젝트에 구성원을 추가합니다. + 상.
제품 백 로그 생성
Microsoft TFS는 작업 항목을 만들고, 프로젝트 계획을 수행하고, 수동 테스트를 수행하는 기능을 사용하여 빌드 정의 및 릴리스 정의를 만드는 데 도움이되는 통합 ALM 도구입니다.
애자일 계획을 세우기 전에 먼저 스프린트 작업을 수행하기 위해 미리 정의 된 기간입니다. 클릭 설정-> 직장 그런 다음 시작 및 종료 날짜로 스프린트를 정의합니다.
Sprint를 선택하고 시작 및 종료 날짜를 설정합니다.
여기서는 Agile 계획의 필수 부분을 구성 할 작업 항목을 만드는 데 초점을 맞출 것입니다. 이제 애플리케이션 또는 제품의 일부가 될 모든 기능의 우선 순위가 지정된 목록이 포함 된 제품 백 로그를 생성하여 시작하겠습니다.
제품 소유자는이 백 로그를 유지하고 스크럼 팀의 도움을 받아 특정 스프린트에서 작업 할 가능성을 결정합니다.
제품 백 로그를 생성하려면 작업 섹션 메뉴에서 백 로그를 선택합니다.
새로 만들기를 클릭하고 백 로그 항목의 제목을 입력 한 다음 더하다 .
제품 백 로그 항목이 백 로그에 추가됩니다. 이론적 인 의미에서 제품 백 로그 항목을 사용자 스토리 또는 변경 요청으로 간주 할 수 있습니다. 일반적으로 여러 개발자 작업 및 테스트 케이스에서 분해됩니다.
우선 순위에 따라 다시 주문할 수도 있습니다. 작업 항목을 위 또는 아래로 끌어서 놓기 만하면됩니다.
메이크 파일 C ++ 만드는 방법
작업 항목을 열고 노력을 추가하십시오. 여기에서 노력은 스토리 포인트 또는 며칠 또는 시간의 프로젝트 요구에 따라 될 수 있습니다. 항목이 작업으로 분해되면 노력 추정치가 추가됩니다. 할당 소유자 'Assigned To'섹션에서 'State'를 승인 됨 개발을 위해. 클릭 저장하고 닫습니다.
다음으로 Sprint 1에 드래그 앤 드롭하여 항목을 Sprint 1에 할당합니다.
반복 경로는 아래 이미지와 같이 항목을 Sprint1로 변경합니다.
항목을 이동할 때 끝난 상태, 스크럼 팀이 스프린트에서 달성 한 총 스토리 포인트 수를 정의하는 Velocity는 오른쪽 상단 Velocity 차트를 클릭하여 표시됩니다.
요약하면 위의 속도 차트에 표시된 것처럼 팀이 Sprint 1에서 8 개의 스토리 포인트를 완료했다고 말할 수 있습니다.
용량 계획
모든 Sprint에 대해 각 구성원이 할당 된 프로젝트에 대해 작업 할 시간을 정의 할 수 있습니다. 각 스프린트의 용량보기가이를 정의합니다. 이보기는 또한 각 구성원이 설계, 개발 또는보고 등과 같이 작업하는 활동을 캡처합니다.
적절한 Sprint를 클릭하십시오. 이 경우 열기 스프린트 1 그리고 용량보기 . 아래와 같이 업데이트하십시오.
위의 스크린 샷에서 Dev1 사용자는 10 일 (영업일 기준) 인 2주의 스프린트 기간 동안 하루에 4 시간 만 작업합니다. 그만큼 할당 된 작업 2주의 스프린트 기간 동안 40 시간 중 완료하는 데 8 시간이 필요한 태스크에 배정되었음을 보여줍니다. 이는 4 (하루 시간) * 10 (2 주) = 40 시간으로 계산됩니다.
Dev2 사용자에 대해서도 유사한 계산이 수행됩니다.
작업 생성
이제 제품 백 로그 항목 또는 사용자 스토리가 정의되고 프로젝트의 모든 사용자에 대해 계획된 용량이 있으므로 이제이를 개발자 작업으로 나눌 수 있습니다. 작업 화면에서 스프린트 1 그런 다음 제품 백 로그 항목에 대해 작업 추가 기호 +를 클릭합니다.
개발자에게 할당하고 값을 입력하십시오. 시간 나머지 작업 필드를 위해. 저장 후 닫기를 클릭하십시오.
생성 된 작업은 제품 백 로그 항목에 연결됩니다.
여기서 남은 작업 필드는 작업을 완료하는 데 남은 시간입니다. 위의 예에서 필드를 8 시간으로 설정하고 하루가 끝날 때 개발자가 작업에 대한 작업을 2 시간 만 완료했다고 가정하면 나머지 시간 필드는 6으로 업데이트됩니다. 더 이상 작업이 없거나 1 시간 이하의 작업이 남아 있거나 0 ~ 1 시간 사이에있는 경우 0입니다.
이 값에서 TFS는 Agile에서 매우 유용한 메트릭 중 하나 인 스프린트에 대한 번 다운 차트를 만들 수 있습니다. 위의 프로세스는 SCRUM 템플릿 용이며 작업 작업 항목에 Original Estimate 필드가 없습니다.
TFS 팀 프로젝트가 Agile 또는 CMMI 프로세스 템플릿을 사용하여 구성된 경우 Original Estimate 필드를 입력 할 수있는 옵션이 있습니다.
Original Estimate 필드를 추가하려면 ( Microsoft.VSTS.Scheduling.OriginalEstimate ) SCRUM 프로세스 템플릿을 사용하는 작업 작업 항목 유형에서 사용자 정의 필드로 추가해야합니다. 사용할 수 있습니다 witadmin exportwitd , 이는 명령 줄 옵션입니다. 내 보낸 XML 파일에 필드를 추가하고 팀 프로젝트로 다시 가져옵니다.
미래 스프린트
제품 백 로그 항목 또는 사용자 스토리는 항목을 다른 향후 스프린트로 끌어서 놓는 방식으로 향후 계획 할 수도 있습니다.
Taskboard 사용
스프린트 계획이 마련되었으므로 이제 작업 보드보기에서 각 작업의 진행 상황을 볼 수 있습니다. 따라서 Taskboard는 작업 및 상태의 시각적 흐름을 제공합니다. 따라서 모든 스크럼 회의 중에 구성원에게 할당 된 각 작업의 상태를 볼 수 있습니다.
완료해야 할 총 남은 작업의 요약을 볼 수도 있습니다.
상태 및 진행 상황을 모니터링하는 것은 매우 중요하며 작업 보드를 통해 수행 할 수 있습니다. 클릭 보드보기 스프린트를 위해.
이 게시판은 매우 유용한보기이며 일일 스탠드 업 회의 중에보고 목적으로 사용할 수 있습니다.
오라클 DBA 인터뷰 질문과 경험이 풍부한 답변
에) 할당 된 작업이있는 개발자가 작업을 시작했다면 다음에서 작업을 이동할 수 있습니다. 할 것 상태 진행 중 드래그 앤 드롭 기능으로 상태.
비) Dev2 사용자의 남은 작업 시간을 8 시간에서 5 시간으로 변경합니다. 그에 따라 진행중인 작업 시간이 업데이트됩니다.
씨) 번 다운 차트는 오른쪽 상단 모서리를 클릭하면 자동으로 업데이트됩니다.
디) 이제 작업을 드래그 앤 드롭하여 Dev2에 할당 된 작업을 닫습니다. 끝난 상태. 이 작업의 남은 작업 시간은 자동으로 0으로 줄어들고 번 다운 차트도 업데이트됩니다.
스프린트 검토 및 회고
이제 작업이 완료되었으며 스프린트 기간은 끝났습니다. 팀은 이제 휴식을 취하거나 휴식을 취할 때라고 생각합니까? 절대적으로 큰 NO. 지금은 SCRUM 수명주기의 매우 중요한 부분 인 검토 및 회고에 대해 논의 할 때입니다.
Sprint 검토는 결과물에 초점을 맞추고 DONE 제품 백 로그 항목을 살펴보고 고객에게 데모를 제공합니다. 또한 수행되지 않은 제품 백 로그 항목과 그 이유를 논의하고 가장 중요한 것은 고객의 피드백을 수집하고 향후 스프린트를 위해 계획하는 것이 매우 중요합니다. 스프린트 검토는 일반적으로 제품 소유자, 개발 팀 및 고객간에 이루어집니다.
Sprint 회고전은 잘 된 것과 그렇지 않은 것과 같은 프로세스 측면에 중점을 둡니다. 따라서 프로세스 및 사람에 대한 피드백도 캡처해야합니다. 이것은 Agile 라이프 사이클의 매우 중요한 측면이므로 자세히 알아볼 수 있습니다. 회고전.
따라서 모든 스프린트에서 미완성 작업이있을 수 있습니다. 이 시나리오에서는 PBI / 작업을 제품 백 로그 또는 제품 소유자가 결정하는 다음 스프린트로 이동합니다.
그러나 지금은 리뷰와 회고전을 어디에 저장합니까? 작업 항목 토론의 일부로 저장하거나 새 작업 항목을 만들어 소급 조치 지점 및 피드백을 저장할 수 있습니다.
결론
이 기사에서는 ALM 도구 인 Microsoft Team Foundation Server가 Agile Scrum 프로세스에 따라 애플리케이션 작업을 시작하는 빠르고 깔끔한 방법을 제공하는 방법을 살펴 보았습니다.
Agile SCRUM 프로세스를 따르는 모든 팀이 팀의 작업을 적절하게 계획하고 관리하기 위해 다음과 같은 측면을 정의하고 생성해야합니다.
- Microsoft TFS에서 적절한 SCRUM 프로세스 템플릿 사용
- 제품 백 로그 생성
- 스프린트 일정 및 팀 용량 지정
- 스프린트 백 로그 항목 선택
- PBI 또는 사용자 스토리를 작업으로 분해
- 번 다운 차트를 사용하여 진행 상황 추적
- 진행 상황을 모니터링하기 위해 Taskboard를 사용하는 것이 매우 중요합니다.
- 마지막으로 효과적인 스프린트 검토 및 회고
추천 도서
- 애자일 테스트 세계에서 훌륭한 팀 멘토, 코치 및 진정한 팀 수비수가되는 방법? -영감
- Agile 및 Scrum 용어 : Agile / Scrum 개념에 대한 용어집
- 플래닝 포커로 애자일 추정 프로세스를 쉽게 만드는 방법
- 테스트에서 애자일 방법론을위한 최신 테스트 원칙
- 자급 자족 스크럼 팀 : 자급 자족 팀을 만드는 방법?
- Agile Retrospective Meetings-필요한 이유와이를 수행하는 몇 가지 재미있는 방법
- 애자일 프로세스로의 성공적인 전환을위한 애자일 테스트 마인드 개발을위한 4 단계
- ISTQB Foundation 시험 형식 및 논문 해결 지침