(들어 본 적이없는 사람들을 위해 Pivotal Tracker "은 팀이 공동 작업을 수행하고 실제 변경 사항에 즉각적으로 대응할 수있는 간단한 스토리 기반 프로젝트 계획 도구입니다. 민첩한 소프트웨어 개발 방법을 기반으로합니다 하지만 다양한 유형의 프로젝트에서 사용할 수 있습니다. ")PivotalTracker 모범 사례
우리는 this outline by Rein Henrichs에 기반한 워크 플로를 준비 중이며 제품 구성 요소를 프로젝트로 분해하는 방법에 대한 의견이 궁금합니다.
우리는 태깅을 실험했지만 시스템 (사진 뷰어, 비디오 뷰어, 뉴스 피드, 알림 서비스)에 많은 구성 요소가있는 경우 단일 프로젝트가 꽤 혼잡 해 질 수 있습니다.
동시에 버전 관리 등을 위해 혼란에 관계없이 하나의 프로젝트에서 모든 것을 가질 수 있습니다.
의견이 있으십니까? 의견? 코멘트? 감사.
트래커는 작업 기반 계획 도구가 아니라 스토리 기반 계획 도구임을 기억하십시오. 스토리 텔링이 사진 뷰어, 알림 서비스 또는 둘 모두에 영향을 미치는지는 고객의 관점에서 중요하지 않습니다. 고객은 구현하고자하는 몇 가지 이야기 (높은 수준의 요구 사항)를 가지고 있으며, 이야기 비용에 대한 견적을 가지고 있으며, 이야기의 우선 순위를 매길 수 있습니다. 물건을 구성 요소로 분해하는 것은 작업 수준의 문제입니다.
동일한 제품에 대한 이야기를 여러 트랙커 프로젝트로 분할하면 고객이 이야기의 우선 순위를 지정하는 방법을 전달하기가 어려워지고 이야기 완성 시점에 대한 좋은 평가를 얻지 못할 수 있습니다.
우리는 우리의 이야기를 추적하기 위해 트래 커를 사용하고, 우리는 우리 자신의 보드를 가지고 우리가 작업을 추적하고 있습니다. 개인적으로 Tracker에서 스토리와 작업을 모두 추적하는 것이 유용 할 것이라고 생각하지만 툴은이를 지원하지 않습니다.
흥미 롭습니다. 따라서 스토리에는 여러 가지 태스크가 있고 팀원은 스토리를 수행하는 데 필요한 태스크를 결정할 수 있습니다. 당신의 대답에 비추어서, 단위 테스트에 관한 질문에 코멘트를 추가하고 있습니다. 생각 해보십시오. –
이것은 약간의 질문입니다. 그러나 질문을 한 후 : 이야기에 수락 테스트 (사용자 스토리가 올바르게 구현되었는지 확인하기위한 테스트)가 있어야합니다. 거의 모든 코드에는 단위 테스트가 있어야하는 것이 이상적입니다. 중요하게 고려해야 할 점은 고객과 개발자가 공유하는 우선 순위가 지정된 스토리 목록을 갖는 것이 여러 가지 이점이 있다는 것입니다. 일부 팀에서는 개발자를 위해 두 번째로 우선 순위가 높은 작업 목록을 만드는 것이 유용하다는 것을 알게됩니다.추적 작업이나 스토리 추적에 여러 Tracker 프로젝트가 고려되고 있는지 여부는 확실하지 않습니다. – NamshubWriter
Pivotal 내에서 스토리에 대한 작업을 활성화 할 수 있다는 것을 알고 계셨습니까? – jkp
이야기를 모두 포함하는 프로젝트가 하나만있는 것이 가장 좋습니다. 그렇게하면 전체 팀이 프로젝트에서 진행중인 작업과 현재 우선 순위 항목이 무엇인지 파악할 수있는 단일 장소가 생깁니다. Rein의 프로세스에서 기능을 충분히 발휘할 수 있도록 스토리를 세분화 한 경우 멋진 모습을 유지할 수 있습니다! 하루가 끝나면 기능의 우선 순위 목록을 갖는 것이 개발 팀이 진정으로 필요로하는 모든 것입니다. 트래커에서 태그를 사용하여 필터링하십시오. 그들은 잘 작동합니다. 제 생각에는 단일 제품을 여러 개의 종속 프로젝트로 나누면 실제로 정보가 흐려져 프로젝트의 실제 상태를 알기가 더 어려워집니다.
Pivotal Tracker가 (작업이나 구성 요소가 아닌) 이야기를위한 Namshub의 게시물에 비추어 볼 때, 단위 테스트는 일반적으로 이야기에 어떻게 대응합니까? (지금 우리는 'unit'태그를 사용하여 이야기에 단위 테스트가 있어야한다고 말하고 있습니다.) 모든 이야기에 테스트가 있습니까? 또는 단위 테스트는 일반적으로 프로젝트를 구성하는 다른 방법과 분리되어 있습니다. –