Project management PivotalTracker最佳实践

（对于那些没有听说过它的人来说，“是一个简单的、基于故事的项目规划工具，允许团队协作并对现实世界的变化做出即时反应。它基于敏捷软件开发方法，但可以用于各种类型的项目。”）

我们即将推出一个基于around的工作流，我们很想知道如何将产品组件分解成项目

我们已经尝试了一些标记，但似乎如果系统中有很多组件（照片查看器、视频查看器、新闻提要、通知服务），那么单个项目可能会非常拥挤

同时，对于版本控制等，将所有内容都放在一个项目中似乎更有意义，而不管项目是否杂乱无章

---

有什么想法吗？意见？评论？谢谢。

最好用一个项目来包含您的所有故事。这样，整个团队就可以在一个地方查看项目的进展情况以及当前的优先事项。如果你把你的故事分解得足够详细，它们可以成为Rein过程中的特征，那么你的状态很好！归根结底，任何开发团队都真正需要一个功能的优先列表。使用Tracker中的标记进行过滤。它们工作得很好。在我看来，将一个产品分解为多个相互依赖的项目实际上会模糊信息，并使项目的真实状态更难获得可见性。

请记住，Tracker是一个基于故事的规划工具，而不是基于任务的规划工具。从客户的角度来看，故事是否会影响照片查看器、通知服务或两者都会影响并不重要。客户有一些他们想要实现的故事（高级需求），他们有关于故事成本的估计，他们有能力对故事进行优先级排序。将事物分解为组件是一个任务级问题

更重要的是，将同一产品的故事分解为多个跟踪项目会使客户难以沟通他们如何对故事进行优先级排序，或者很难对故事何时完成做出准确的估计

---

我们使用跟踪器来跟踪我们的故事，我们有自己的董事会来跟踪任务。我个人认为在Tracker中跟踪故事和任务会很有用，但该工具不支持它。

有趣。因此，故事将有多个任务，团队成员可以确定完成故事所需的任务。根据您的回答，我将对有关单元测试的问题添加一条评论。这有点离题了，但既然你问了：故事应该有验收测试（验证用户故事是否正确实现的测试）。理想情况下，几乎所有代码都应该有单元测试。重要的一点是，在客户和开发人员之间共享一个有优先级的故事列表有很多好处。一些团队发现为开发人员提供第二个优先任务列表很有用。这个问题不清楚是否考虑在跟踪任务或跟踪故事中使用多个跟踪器项目。您知道现在您可以在Pivotal中启用针对故事的任务吗？鉴于Namshub的帖子，Pivotal Tracker用于故事（而不是任务或组件），单元测试通常如何对应于故事？（现在我们使用标签'unit'来表示故事应该有一个单元测试）。。理想情况下，所有故事都会有测试吗？或者，单元测试通常与组织项目的其他方式是分离的。