管理里程碑和Web开发项目

Question

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

现在我正在为我的项目实施Trac。现在问题是我应该将什么作为里程碑和门票。对于票，我应该多细粒度？例如我应该说Make X是Y功能的一部分还是只做Y功能。我制作的门票越多，制作这些门票的时间就越多。

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

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

此外，我还想考虑增强功能/错误作为门票，并将它们作为里程碑聚集在一起。

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

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

谢谢。

Answer 1

嗯，这取决于。你没有说明项目有多大，有多少程序员会工作，你计划多长时间交付一次。

说明这就是我们如何在一个跨越几年的大型项目中使用Trac，其中包括许多较小的子项目。

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

• 里程碑说明仅包含新功能列表或错误修复。文档以维基和门票编写。

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

• 门票包含必须实施的功能或错误的详细说明。

  • 错误报告故障单包含错误描述和重现步骤（几乎总是）。
  • 功能票证包含必须实施的功能的详细说明。一张票包含工作长达6小时。在计划工作的时候，把特征分成1~6小时的工作范围。如果我们估计该功能需要更多时间，那么我们将它分成几张票，这样每个功能都可以在1-6小时的工作时间内完成。我们挑选了6个小时，因为我们觉得它是我们可以估计的顶部，误差不大于30％（意味着这个6小时估计几乎总是可以在4-8小时之间的范围内完成）。当然，这些统计数据也有例外。根据我们的经验，错误估计的主要原因是我们编写的规范不好。这几乎总是发生，因为我们（开发人员）误解了我们用户的业务需求。

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

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

Answer 2

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

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

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

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

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

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

alt text http://officeadd.in/Images/articles/ProjectMilestones-scribblea.png

很抱歉，这与Trac和SVN没有直接关系，但希望这能让您大致了解里程碑的使用方式。哦，并且为过度使用Comic Sans而道歉......哎呀。

Answer 3

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

Answer 4

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

您可以考虑Feature Driven Development。您可以使用trac来支持通信而不是控制。粗粒度的任务，细粒度的门票和早期版本。

列出要开发的功能，并说明在发布和测试所有功能时发布版本，比如...版本1.0。制作所有功能的伞形票。粗粒度将定义发展节奏。

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

如果在开发过程中需要更精细的任务，不要害羞地制作它们。并使伞式任务依赖于这些较新的门票。

错误报告不需要在其中任何一个，并且可以根据需要提供尽可能多的详细信息。这些是细粒度的。这些不定义开发节奏。一个例外是压缩sprint以消除showstoppers的bug。发布具有更多已分配但未解决的错误的开发人员的名称，以迫使他们解决问题。

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

我认为对于大多数情况来说，两个数字的版本号就足够了。第一个数字表示兼容性，第二个数字表示发布。但是有几个变量可以在版本号内：源兼容性，二进制兼容性，bugfix级别，发布，伴随产品版本（ala oracle），协议兼容性等。

Answer 5

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

以下是我的建议：

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

Trac是一个非常好的工具。最好的功能或Trac是将WikiLinks放在任何地方的能力，包括变更集评论。如果您要求将ticket＃置于变更集注释中，然后将变更集编号放入故障单注释，则会将任务和更改链接到代码。稍后这些链接可以更容易地跟踪软件的发展。如果项目持续时间超过几个月，那么它可以节省生命。