2009.8.2 OA项目组一周工作报告

质量评价:60 评价依据: 在代码检查和测试中没有发现大的问题。 进度评价:55 评价依据: 1. 本周计划中的关于可用性代码的重构没有处理，而这个重构会影响到后面2个bug的处理。 2. 本周向客户提交了DevExpress的演示版本，客户对这个演示版本很感兴趣，可能会

质量评价:60

评价依据:

在代码检查和测试中没有发现大的问题。

进度评价:55

评价依据:

1. 本周计划中的关于可用性代码的重构没有处理，而这个重构会影响到后面2个bug的处理。

2. 本周向客户提交了DevExpress的演示版本，客户对这个演示版本很感兴趣，可能会在当前的2.55版或2.56版实现它

3. 本周Employee网站已经实现了登陆功能，客户提出需要运行这个网站。为了方便客户，我们会在下周一给客户发一个这个网站的安装版本。

本周重要的事情有两件，一件是没有完成可用性代码的重构，我会在下周赶上进度。另外一件是客户给我们发了一个关于JIRA的使用策略。这个策略我在周五已经发布到了项目的wiki上，但是由于那个时候我本人对这个策略仍然存在疑问，所以没有将这个策略的链接发给大家。

现在客户希望我们对项目中的每个任务所需的时间都要做出评估，以小时为单位。时间管理作为成本控制的一部分，在这里我不想做过多的评价。对于这个策略，我们项目组对每周的计划做如下调整：

1. 我会向往常一样给大家发任务清单

2. 请大家根据我的任务清单，制定一个project时间表，精度为小时

3. 请大家在为每一项任务估计时间时，一定要加上项目在内部沟通上的时间。

4. 请大家在为每一项任务估计时间时，将测试和改bug的时间估计在内，但是一般将该任务的测试放在周五进行。

5. 如果在执行任务的过程中，有需要客户确认或询问客户的内容，请详细记录该任务停止的时间，精度为小时；重新开始这项任务时，请明确记录该任务开始的时间，精度为小时。

6. 如果出现了5描述的情况，即项目执行的时间不连贯，请同样分段表示该任务的执行情况，例如该任务计划3小时，在执行1小时后，发现有问题需要客户确认，请该任务在project中的设置改为1小时，并在备注中注明原因。当收到客户的回复并打算继续处理这个任务的时候，请另外为这个任务建一个名称相同的任务，后面加上序号，并在备注中说明原因。

7. 我会每天根据每个人的project文件跟踪进度，如果发现进度落后，我会和客户沟通。

以上调整是我根据客户的新策略指定的应对方案，在实践中可能会有问题。记住，在没有这个方案之前，我们项目组也工作得很不错，这个方案只是为了满足客户对项目管理的需要，同时也会提高我们自己的项目控制水平。

另外，关于代码的重构，我也给Lucy提到过，认可代码重构的必要性，所以我们在执行项目的过程中，如果发现有需要代码重构的地方，仍然可以重构，只是要在备注中注明。

不管用什么方式去管理，只要对项目本身有意义，不会影响项目的提交时间，我想客户都会和我们商量的。

 

更多内容，请参见我的项目周报