项目管理 – 管理里程碑和Web开发项目

前端之家收集整理的这篇文章主要介绍了项目管理 – 管理里程碑和Web开发项目前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在尝试实现Trac SVN.但我遇到了项目管理问题.为了给你一个背景知识,我的大多数项目都与Web开发有关(它们通过设计,编程,测试等阶段).

现在我正在为我的项目实施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%.

原文链接:https://www.f2er.com/html/227538.html

猜你在找的HTML相关文章