管理里程碑和Web开发项目

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

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

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

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

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

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

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

谢谢.

这得看情况.您没有指定项目有多大,有多少程序员可以使用,您计划交付的频率.

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