8

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

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

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

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

此外，我还想将增强/错误考虑在内，并将它们作为里程碑组合在一起。

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

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

谢谢你。

4

5 回答 5

11

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

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

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

  • 里程碑描述仅包含新功能或错误修复的列表。文档写在 wiki 和门票中。

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

  • 工单包含必须实现的功能或错误的详细描述。

    • 错误报告票包含错误描述和重现步骤（几乎总是）。
    • 功能票包含对必须实现的功能的详细描述。一张票包含长达 6 小时的工作。当我们计划工作时，我们将功能划分为 1 到 6 小时的工作时间。如果我们估计该功能需要更多时间，那么我们会将其分成几张票，以便每张票都可以适应 1-6 小时的工作。我们选择 6 小时是因为我们认为它是我们可以估计的最高值，误差不大于 30%（这意味着这 6 小时的估计几乎总是可以在 4-8 小时的范围内完成）。当然，这个统计数据也有例外。根据我们的经验，错误估计的主要原因是我们编写的规范错误。这几乎总是发生，因为我们（开发人员）误解了用户的业务需求。

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

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

于 2009-04-09T11:25:46.977 回答
2

一个小小的警告：我不知道使用 Trac... 或 SVN。我认为您的里程碑不应该由版本控制/错误跟踪系统设置。

通常，里程碑只是您项目中的重要事件。它们应该对所有利益相关者都很重要。一个主要可交付成果的完成是一个里程碑。一些功能的完成不是。签署所有计划和合同是一件大事，但完成 10 个模型却不是。

我倾向于使用时间表和任务来与团队合作。完成任务后勾选它们。对于其他所有人，我只报告里程碑。我们要在 5 月 15 日之前制作 UAT 吗？是的我们是。

由于里程碑是向赞助商和其他利益相关者报告的工具，因此您应该将它们设置为他们认为重要的内容。我的赞助商会想知道某个核心功能集何时完成，这是一个里程碑。他们会想知道何时签署 UAT，这是一个里程碑。

设定的里程碑太少，直到最后没人会知道你的进展情况。设置太多，值会丢失。

没有神奇的公式，但有数百个任务和数千个工时的项目可能只有 4 个里程碑。

替代文字 http://officeadd.in/Images/articles/ProjectMilestones-scribblea.png

抱歉，这与 Trac 和 SVN 没有直接关系，但希望这能让您大致了解里程碑通常是如何使用的。哦，并为过度使用 Comic Sans 提前道歉……糟糕。

于 2009-04-10T11:44:35.540 回答
0

将您的 1.0 里程碑设置为可交付日期很好，但您需要定义更早的里程碑 - 如果这对您来说是一个合适的间隔，请每周进行一次，并适当地对它们进行编号。对于一个为期 4 周的项目，0.2、0.5、0.7 和 1.0 可能会起作用。列出每个里程碑的相关位：“设计完成”、“编码完成”、“测试完成”等。如果您没有达到目标，那么真正的项目管理工作就开始了！

于 2009-04-03T17:06:46.660 回答
0

我看到你有几个选择和几个决定要做。

您可以考虑功能驱动开发。您可以使用 trac 来支持通信而不是控制。粗粒度任务、细粒度工单和早期版本。

列出要开发的功能，并说明发布，比如说……版本 1.0，当所有功能都被开发和测试时发生。为所有功能制作雨伞票。有粗粒度的，将定义开发节奏。

现在根据计划的功能数量和时间定义几个里程碑。第一个里程碑应该包含至少一个特性，因为里程碑的目标是构建项目以进行测试和反馈。定义一个或多个里程碑来标记所有功能何时完成，称它们为“测试版”、“候选发布版”或其他任何名称。

如果在开发过程中需要更细粒度的任务，请不要害羞。并使伞式任务依赖于这些较新的票证。

错误报告不需要在其中任何一个之下，并且可以根据需要包含尽可能多的详细信息。这些是细粒度的。这些不会定义发展节奏。一个例外是一个 bug squashing sprint 以消除干扰。发布具有更多已分配且未解决的错误的开发人员的姓名，以迫使他们解决问题。

制作里程碑、测试版或发布候选版本的过程的一部分是标记源以使该过程可重复，并且即使在主干源已经更改时也能够发现错误。在 SVN 上，标记的常用方法包括将主干源复制到“标记”上的目录，并确保没有人提交到该分支。

我相信对于大多数情况来说，两个数字的版本号就足够了。第一个数字表示兼容性，第二个数字表示版本。但是版本号中可以包含几个变量：源代码兼容性、二进制兼容性、错误修复级别、版本、配套产品版本（ala oracle）、协议兼容性等。

于 2009-04-07T12:18:44.650 回答
0

我已经使用 Trac/SVN 两年半了。

这是我的建议：

  • 将软件版本的生产拆分为几个迭代：Inception、Elaboration、Transition（或随意调用它们）
  • 为第一次迭代计划功能。对于其他人计划增强和错误修复
  • 任务（票证）应尽可能细化，前提是每张票证都有对客户有价值的可交付成果
  • 节省创建工单的时间不是一个好主意。更细化和更小的任务——对进度的更多控制。因此，更早地发现规划的缺陷和更多的时间来管理出来。
  • 即使在进行中，门票也可以拆分。如果开发人员达到了可以显示给客户的结果但没有完成整个任务，那么开发人员可以拆分任务并将完成的部分标记为“关闭”或“已解决”，从而提供更精细的控制。
  • 每天而不是每周（或每周至少几次）跟踪进度

Trac 是一个非常好的工具。最好的功能或 Trac 是能够将 WikiLinks 放在任何地方，包括变更集评论。如果您要求将票证 # 放入变更集注释，然后将变更集编号放入票证注释，这会将任务和更改链接到代码。稍后，这些链接可以更轻松地跟踪软件的演变。这是一个救生员，特别是如果项目的持续时间超过几个月。

于 2009-04-10T03:44:24.803 回答