如何进行项目跟踪

软件项目的目的是什么呢，简单说就是要在最后向客户交付一个产品。计划是什么呢？计划就是对项目过程的一个整体规划。跟踪（我理你你其实就是在说项目监控），就是要保证项目按照计划的中安排逐步进行。

想要监控的好，就首先要有一个好的计划。正如ls所说，项目计划总是会变动的，其实进行项目计划改动这本身就是项目监控的一部分。对于项目阶段的划分因为使用开发方法不同，划分的方法也不同，最起码要保证每个阶段的目标准确。至于每个阶段的时间，开始估算的可能不准，但是随着项目的进行，应该能够逐渐的接近实际需要时间。毕竟一个组织的生产效率是比较平稳的。

对于lz后面说的因为项目计划粗糙没法进行细节跟踪，我并不是很理解？这个细节到底要多细？假设你们公司会划分里程碑，那么你项目计划做到每一个里程碑会很困难吗？我觉得这是完全可以做到的。至于每个里程碑里面每天需要什么进度则需要灵活的掌握，不管使用什么方法，xplanner也好别的什么工具也好，里程碑的任务分解也是比较容易做到的。不管项目经理在里程碑是用什么方法去控制只要能达到里程碑计划项目进行就不会有什么问题。当然里程碑计划在开始的时候也能会估算的不准确，但是每个里程碑过后项目经理都可以去修正。重要的是不是说我这次没达到目标我就直接把计划往后退就可以了。每次出现问题都要去分析原因。推迟和提早完成都不是什么好事。假如说这次推迟了就要找到原因，想办法解决。是因为项目计划估算的不好就改计划，是因为某个技术问题或者某个人的问题导致了推迟就要想办法再下一个里程碑把这个问题解决掉。

所谓突发性的问题不管是什么问题，在一个公司里这些问题基本上都是会经常出现，这样的问题就应该开始的时候就纳入风险。

有个要点是要形成团队内成员的自管理氛围，成员自己汇报进度比采集进度更有效。我初步了解了scrum后发现这是一种很实用的模式，只是我们确实没有理论化，上升到方法论的高度。scrum同样强调“自管理”，缺乏自管理的开发团队，很难实施有效的敏捷开发。

之前我一度认为需要将任务作为参考基线，后来在看到'硝烟中的Scrum和Xp'的时候提出一个观点是任务本身就是因人因时间变化的，所以拿一个易变的东西作为参考量是不够合理的。
因为编程本身就是一个群人复杂的活动，很难真正量化到具体每小时干什么，所以取一个平衡的话，以功能(story/uc/backlog)作为整体进度，然后以一个相对短的时间作为sprint进行划分任务作为评估内部进度，通过burn-down chart(燃尽图)能够合理的体现出开发速度，进行相应的调整。

在这里学习的东西真是太多了.LZ的知识之广.佩服.

在我们公司，目前对于项目的跟踪主要从做了以下工作
1、每个项目开始时，都要制定里程碑计划。这个应该是少不了的，可能需要销售+PM+售前等一起定。一般两个里程碑之间的间隔不要过长，一个月为宜。
   项目里程碑计划允许变更，但是要进行审核。
2、每个项目开始时，预估一下项目共需多少工作量。大致是多少人月。
3、每个项目开始时，先预估一下每月的人力投入情况，主要根据里程碑计划的需要。这个人力投入的合计与工作量要大致吻合。

这样，经过QA，项目立项就可以通过。
项目开展时，每个项目每周编写周报，周报里的本周任务不管完成没完成，都要把该时间段内里程碑的计划进行体现。周报里的下周计划也要体现里程碑计划。

我们目前这是比较粗粒度（每周）的跟踪，主要目标是控制进度和成本。

我觉得做软件开发项目，在一开始就把从项目头到尾三四层的WBS做好很难。项目开始阶段，根据经验先估算一两层的WBS，在每个阶段的进展过程中，逐步细化下一个阶段三四层的WBS

1、项目一定要进行生命周期的选型，确定各个里程碑的时间段。
2、用代码行或者经验值估算编码周期从而估算出各个阶段的时间及工作量。
3、需要项目经理对任务进行详细分解，包括文档的书写。
4、确定项目的会议机制，定期汇报项目进展情况及发生的问题及风险跟踪。
5、分配好QA的检查机制，由QA定期上报项目进度及问题、风险发生情况。
6、及时确定各阶段的进度对总体计划进行调整。
7、将项目不能解决的问题上报公司及用户，由项目管理委员会来确定项目的进度。

敏捷+迭代开发确实好。
我赞同楼上有人提出的团队内成员的自管理氛围要有。
我发现团队内有人为了计划而忽略了代码的质量（计划是合理的）。
这个问题很严重