现在我正在为我的项目实施Trac.现在问题是我应该将什么作为里程碑和门票.对于门票,我应该获得多少粒度？例如我应该说Make X是Y功能的一部分还是只做Y功能.我制作的门票越多,制作这些门票的时间就越多.
此外,对于里程碑,我看过像CakePHP等项目.当他们使用Trac时,他们将里程碑设置为版本号(对应于SVN中的标签).这是最好的方式吗？
所以说我有一个客户,其最后期限是X日期.然后我将里程碑设置为1.0,截止日期为X.但是,我如何跟踪项目每周说？因为我不想在发布日期前一天意识到太多了.我想以某种方式进行每周检查.
此外,我还想考虑增强/错误作为门票,并将它们作为里程碑聚集在一起.
我想象了像1.x.x这样的东西,其中第一个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 Plugin
.您可以输入预计的机票时间和工作时间.然后,您可以获得报告您在门票/里程碑上花费了多少时间以及需要多长时间才能完成的报告.
两年后,我们可以非常准确地估计完成一些工作所需的时间.当我们正确理解用户需求和要求时,我们通常可以在承诺的时间范围内交付.目前,我们的统计数据显示,我们高估了门票所需的时间约10％.
