Project management 在ExtremePlanner中是否有更简单的方法跟踪范围更改？

我将在一个项目的中途加入一个新的软件团队。他们正在使用ExtremePlanner跟踪他们的进度

虽然他们在跟踪已完成的任务，但并不跟踪项目的估计规模随时间的变化。在我监控项目的短短时间内，这个估计的变化速度超过了任务的完成速度。我的直觉告诉我，这不仅仅是一个小问题，而是一个贯穿整个项目生命周期的问题

但我如何证明或反驳这一点

我还没有发现ExtremePlanner指标对此有用。我一直在将数据导出到MS Excel，但导出的任务和故事信息缺少重要数据，如创建日期。解决这个问题需要一点努力。有更好的方法吗

---

我是不是太重视这个了？我的一些潜在队友认为，由于没有添加新功能，所以范围没有改变，这不是问题。然而，我认为，由于功能中的新工作不断被发现，范围正在变化，因此在估计发布日期时需要考虑到这一点。

如果这是一个敏捷项目（例如，使用Scrum、XP等），那么您可能正在迭代（或Sprint）中工作

所以我的问题是——在一次迭代中，事情是否变化如此频繁，以至于需要对其进行度量？通常，敏捷项目通过在单个迭代中冻结功能来指导。是的，您可能会发现新的可能的实现细节或技术障碍，但它们都只是2周迭代中的细节

如果您的迭代太长，我确实看到了您的担忧，因为如果每次迭代需要一个月或6周的时间，那么您要纠正的过程会有点长

我想我会问——如果你有这些报告，你会怎么做，报告上会写些什么

任务评估最初是什么以及现在是什么的基线？ExtremePlanner确实提供了有关任务原始估计的信息，因此您可以将这些信息与迭代的当前状态进行比较（请参见任务视图-您可能需要单击该视图的“自定义”链接以显示原始估计列）

如果是更多的东西，我会感兴趣的是你会发现哪些有用的东西（我们也使用ExtremePlanner，但还没有遇到这种需要，尽管我们使用2周的迭代）

---

希望这能有所帮助。

我一直警告管理层该项目遇到了麻烦，但这种观点并不受欢迎。我给了他们图表，显示如果你在任务级别跟踪完成情况，这个项目将需要10年的时间。如果你在故事层面进行跟踪，那将花费无限的时间，因为他们不是在完成故事，而是在完成任务。他们在估算、故事大小、在制品和完成定义方面存在问题。我换了一个项目，最终离开了公司。一两年后，他们取消了这个项目。这就像看一场慢动作的火车相撞一样不真实。我们本应该使用功能驱动的开发，迭代时间为2周，但它更像是符合流行语的瀑布。