project-management - 管理里程碑和 Web 开发项目

Question

我正在尝试实现 Trac+SVN。但是我遇到了项目管理问题。给你一个背景，我的大部分项目都与 Web 开发有关(它们经历了设计、编程、测试等阶段)。

现在我正在为我的项目实现 Trac。现在的问题是我应该放置什么作为里程碑和票证。对于门票，我应该获得多大的粒度？例如我应该说使 X 成为 Y 特征的一部分还是仅使 Y 特征。我制作的门票越多，我花在制作这些门票上的时间就越多。

另外，对于里程碑，我见过像 CakePHP 等项目。当他们使用 Trac 时，他们将里程碑设置为版本号(对应于 SVN 中的标签)。这是最好的方法吗？

假设我有一个客户，其最终截止日期是 X 日期。然后我将我的里程碑设置为 1.0，截止日期为 X。但是我如何每周跟踪项目？因为我不想在发布日期前一天意识到剩下的太多了。我想以某种方式每周检查一次。

此外，我还想将增强/错误也作为门票考虑在内，并将它们作为里程碑一起使用。

我想象过类似 1.x.x 的东西，其中第一个 x 对应于一组功能增强，而第二个 x 对应于错误修复。有没有更好的办法？我如何在这样的系统中管理每周状态？

有没有标准的方法来做到这一点？我该怎么做？我完全糊涂了。

谢谢你。

Answer 1

这要看情况。你没有具体说明项目有多大，有多少程序员将工作，你计划多久交付一次。

说明这一点，以下是我们如何在一个跨越数年的大型项目中使用 Trac，该项目由许多较小的子项目组成。

里程碑 被定义为我们在子项目中有一些功能可以交付的点。每个子项目的第一个里程碑通常是最长的。我们通常将里程碑命名为“Subproject Name v0.01”。版本只是增量 0.01, 0.02, ... 当我们实现子项目预期的所有内容时，我们将最后一个里程碑标记为 v1.00。随后的错误修复转到我们标记为“子项目名称 - v1.00 - 错误修复”的里程碑

里程碑描述仅包含新功能或错误修复的列表。文档是用 wiki 和票证编写的。

Trac 维基 通常至少有一页关于将在特定里程碑中实现的新功能。它通常是对应用程序预期行为的更高级别的描述。通常，会有应用程序应该产生的预期结果的示例。

门票包含必须实现的功能或错误的详细描述。

错误报告票包含错误描述和重现步骤(几乎总是)。

功能票包含必须实现的功能的详细描述。一张票包含工作长达 6 小时 .当我们计划工作时，我们将功能划分为 1 到 6 小时的工作时间。如果我们估计该功能需要更多时间，那么我们会将其拆分为几张票，这样每个票都可以适应 1-6 小时的工作。我们选择了 6 小时，因为我们觉得这是我们可以估计的最高点，误差不超过 30%(这意味着这个 6 小时的估计几乎总是可以在 4-8 小时之间完成)。当然，这个统计数据也有异常(exception)。根据我们的经验，错误估计的主要原因是我们编写的规范不好。这几乎总是发生，因为我们(开发人员)误解了我们用户的业务需求。

用于估算和时间跟踪的 Trac 插件很少。查看此页面:http://trac.edgewall.org/wiki/TimeTracking .我们使用 Timing And Estimation Plugin
.您可以输入工单的预计时间和工单上花费的时间。然后您可以获得报告您在门票/里程碑上花费了多少时间以及您需要多少时间来完成。

两年后，我们可以非常准确地估计完成一些工作所需的时间。当我们正确理解用户的需求和要求时，我们通常可以在 promise 的时间范围内交付。目前，我们的统计数据显示，我们高估了约 10% 的购票时间。