（对于那些还没有听说过的人来说，Pivotal Tracker“是一个简单的基于故事的项目规划工具，它允许团队协作并即时应对现实世界的变化，它基于敏捷软件开发方法，但它可以用于各种类型的项目。“）PivotalTracker最佳实践
我们即将加入基于this outline by Rein Henrichs的工作流程，并对如何将产品组件分解为项目的意见感到好奇。
我们已经试验了一些标记，但似乎如果系统中有很多组件（照片查看器，视频查看器，新闻源，通知服务），则单个项目可能会变得非常拥挤。
同时，对版本控制等，现在看来，这可能会更有意义就什么都有了在一个项目无论是杂乱的。
有什么想法？意见？注释？谢谢。
记住Tracker是一个故事为基础的规划工具，而不是基于任务的规划工具。从客户的角度来看，故事是否会影响照片查看器，通知服务或两者都无关紧要。客户有一些他们希望实施的故事（高层需求），他们对故事的成本进行了估计，并且他们有能力确定故事的优先顺序。将组件分解成任务级别的问题。
更重要的是，对于同一个产品分成多个跟踪器项目的最新报导将难以对客户进行沟通，他们如何优先考虑的故事，或得到一个很好的估计何时可以完成的故事。
我们使用跟踪器来跟踪我们的故事，我们有我们自己的船上有我们跟踪任务。我个人认为跟踪Tracker中的故事和任务会很有用，但该工具不支持它。
有趣。所以故事会有多重任务，并且团队成员可以确定完成故事需要完成哪些任务。 鉴于你的回答，我正在给单元测试问题添加一条评论。 Lmk你的想法。 – 2009-05-07 14:30:01
这可能是最好有一个单一的项目来包含你的所有故事。这样，整个团队就有一个地方可以看到项目正在发生什么，以及当前优先项目是什么。如果你的故事足够细分，以至于它们可以成为Rein的过程中的特征，那么你的状态很好！在一天结束时，拥有优先级的功能列表是所有开发团队真正需要的。使用Tracker中的标签进行过滤。他们工作得很好。在我看来，将单个产品分解为多个依赖项目实际上会掩盖信息并使得难以了解项目的真实状态。
在Namshub的帖子的光这匹Tracker是为故事（而不是任务或组件），如何将单元测试一般对应于故事？ （现在我们使用标签“单元”来说故事应该有单元测试）..理想情况下所有故事都会有测试吗？或者单元测试通常与组织项目的其他方式脱钩。 – 2009-05-07 14:34:24