우리는 전통적인 화이트 보드 및 PostIt 노트에 몇 가지 스프린트를 가지고 있으며 팀 시스템 환경에 프로세스를 통합 할 준비가되었습니다. 우리가 고려중인 도구 중 하나는 Conchango의 "Team System 용 스크럼"(http://www.scrumforteamsystem.com/en/)팀 시스템 용 스크럼은 스크럼 프로세스를 관리하기위한 훌륭한 도구입니까?
실제 스크럼 프로세스에서이 도구를 사용해 본 사람이 있습니까? 당신의 경험은 긍정적 이었습니까, 부정적입니까? 귀하의 의견으로 라이센스 비용에 합당한 도구입니까?
우리는 팀 시스템 용 스크럼을 사용하며 그것을 좋아합니다. 정말 TFS와 스크럼 프로세스를 합병하는 좋은 일을합니다.
우리는 또한 태스크 보드 (당신이 지불해야하는 부분)를 얻었고 실제로 그렇게했습니다.
Team System 용 Scrum을 사용하는 경우에도 Visual Studio를 통한 TFS는 미팅 계획에 적합하지 않습니다 (단, 업 그레 이드는 괜찮습니다). 작업 보드는 남은 작업을 시각화하고 주변을 움직이는 데 많은 도움이됩니다.
우리는 Task Board를 갖기 전에 기획 회의를 위해 메모를 게시 한 후 TFS에 입력합니다. 태스크 보드가 좋다고해도 계획 회의에서 적어도 2 명이 작업하지 않는다면 충분하지 않습니다. 우리는 5 + 1 (스크럼 마스터) 팀을위한 3 대의 랩탑을 가지고 있으며 그 중대한 작품입니다. 당신이 그 때 그것을 가지고 있지 않다면, 나는 여전히 포스트 노트에 대해 생각할 것입니다.
작업 보드를 사용하면 다른 사람이 입력하는 내용을 새로 고치고 볼 수 있습니다. 우리는 한 컴퓨터를 프로젝터에 연결하여 다른 사람이 무슨 일이 일어나고 있는지 볼 수 있습니다. 우리 모두는 그런 다음 노트를 게시 할 때처럼 브레인 스토밍하지만 랩톱에있는 사람들은 TFS에 데이터를 입력합니다.
우리에게 큰 도움이됩니다.
나중에 참고 사항 : 팀 시스템 용 스크럼 템플릿을 선택하면 프로세스 지침을 읽는 것이 좋습니다. 우리는 앉아서 그것을 읽기 전에 몇 가지 어려운 점을 찾아야했습니다. 특히 버그를 처리하는 방법 (버그가있는 시점과 '진행 중'으로 돌아가는 스프린트 백 로그 항목 인 경우)
템플릿은 무료입니다. 겸손한 비용을 지불하는 것은 Task Board Application 일뿐입니다. 태스크 보드 없이도 템플릿을 사용할 수 있지만 wll로 사용하는 것이 좋습니다. 우리 팀의 가장 큰 장점은 ScrumForTeamSystem 템플리트가 VS에 통합되어 나머지 개발 환경과 매끄러운 느낌을주는 것입니다.
우리는 PBI를 체크인에 첨부하여 Daily Build 보고서에 표시하는 것을 좋아합니다.
필요한 것을 잃어버린 경우 VS 템플릿을 편집하여 원하는 템플릿을 편집 할 수 있습니다. 우리에게는 PBI 템플릿에 "Requested By"필드와 "Testing Status"필드가 추가되었습니다.
우리를 괴롭히는 2 가지 단점은 PBI의 "주"가 SBI (PBI의 테스트 준비 안 됨)와 같지 않다는 것입니다. 우리는 태스크 레벨이 아닌 기능 레벨에서 테스트/검증을 수행하고 PBI 상태를 추적하여 우리 고유의 사용자 정의 필드를 추가해야했습니다. 두 번째 쟁점은 스프린트 레벨에서 PBI burndown/up에 대해 즉시 사용 가능한 보고서가 없다는 것입니다. 따라서 이야기 전달과 작업 만 수행하는 방법을 알 수 없습니다. 너 자신을 만들어야 해.
"버그"템플릿을 많이 사용하지 않습니다 (완벽한 코드를 제공합니다 :)). 실제로, 스프린트에서 일하는 것에 대한 버그와 같은 것은 없습니다. 그래서 우리가 버그를 기록하는 유일한 시간은 클라이언트가 광고 코드대로 작동하지 않는 생산 코드에서 문제를 발견 한 경우입니다.
Vaccano에 따르면 회의 환경에서 화이트 보드 나 포스트잇만큼 빠르지는 않지만 툴을 사용하는 사람들과 노트북 두 대를 사용하면 실제로 잘 작동 할 수 있습니다.
여러 제품을 평가 한 결과, ScrumForTeamSystem의 단순함과 가격은 이길 수 없습니다.
다른 사람들처럼 Conchango 템플릿이 버그를 매우 다르게 처리한다는 점에 유의하십시오. 출시되지 않은 백 로그 항목에 버그가 없다는 아이디어는 단순한 제안이 아닙니다. 문자 그대로 현재 진행중인 스프린트의 작업에 영향을 미치는 버그를 추적 할 수있는 방법이 없습니다 (). 나는이 단점이 장점을 능가하는 것을 발견했다.
3.0 버전의 VS 2010 템플릿은 Scrum이 다중 팀 프로젝트를 효과적으로 효과적으로 지원할 수있는 방법과 일반적인 상호 작용을 찾는 방식을 변경합니다 더 큰 프로젝트.
버전에 관계없이 현재 Microsoft 환경에서의 Scrum 프로젝트에 대한 내 기본 답변입니다. 언급했듯이 작업 보드와 (새로운) ScrumMaster의 워크 벤치는 믿을 수 없을 정도로 가치가 있습니다!
우리는 직관적 인 웹 인터페이스로 Microsoft ALM 플랫폼을 확장하고 민첩한 프로젝트 관리를 단순화 한 Urban Turtle을 제작합니다. 웹 액세스에서 태스크 보드와 계획 보드를 직접 제공함으로써 아무 것도 동기화 할 필요가 없습니다. 설치는 간단한 과정입니다. 웹 액세스 서버에 2 분 설치하십시오. 클라이언트 데스크탑에 아무것도 설정할 필요가 없습니다.
현금 내 말을 오해하지 마세요 Microsoft에서 브라이언 해리는 제품에 대한 말을 한 번 봐 가지고 : 웹 사이트에서 살펴보고 나에게 의견을 보내
http://blogs.msdn.com/b/bharry/archive/2010/10/21/urban-turtle-3-5-released.aspx
을
urbanturtle.com
Dominic Danis 제품 소유자.
현재 스프린트에서 문제가 발생하면 연관된 작업이 진행중인 상태로 돌아가서 작업을 시작한다는 아이디어가 있습니다. 스프린트와 관련이없는 경우 (또는 스프린트에서 수정되지 않을 경우) 제품 소유자가 우선 순위를 지정해야하는 버그가 생성됩니다. 익숙해지는 데 익숙해졌지만 이제는 할 수있게되었으므로 정말 좋았습니다. 버그를 우선 순위를 매기고 일정대로 작업해야 할 필요가있는 것입니다. – Vaccano
오해하지 마세요. 평소 워크 플로와 다른 "제품 버그"를 처리하고 잊어 버렸거나 0으로 몰아 넣지 않고 나머지 비 스프린트 백 로그와 함께 검토하도록합니다. "진행중인"작업을보다 세부적으로 추적하기위한 메커니즘이 없다는 것을 짐작할 수 있습니다. 새로운 기능에서 10 가지 버그를 발견하면 옵션이 (1) 해당 작업에 포함되어 아무 것도 간과되지 않게하십시오 (2) 전자 메일 스레드를 시작하십시오 (3) OneNote 또는 Sharepoint와 같은 다른 공동 작업 도구를 참조하십시오. 그들 모두는 TFS 소유의 목적을 무력화시키는 것 같습니다. –