管理里程碑和Web开发项目

时间:2009-04-03 16:21:32

标签: project-management trac

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

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

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

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

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

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

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

谢谢。

5 个答案:

答案 0 :(得分:11)

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

说明这就是我们如何在一个跨越几年的大型项目中使用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%。

答案 1 :(得分:1)

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

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

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

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

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

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

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

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

答案 2 :(得分:0)

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

答案 3 :(得分:0)

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

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

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

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

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

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

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

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

答案 4 :(得分:0)

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

以下是我的建议:

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

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