2006. 6. 21 OA 项目组一周项目周报

进度评分:60
评分依据:本周基本上按照计划完成了任务。GDOCS-266,一个很难重现的bug也在周五下班之前找到了原因，并得到了客户的修改确认。
质量评分:65
评分依据:本周发现了多个自测bug，并及时通知了客户，跟新到了2.54版本。
目前虽然在代码编写上没有找到一个好的方法来避免目前遇到的问题，但是在自测上却找到了希望。这周发现的自测bug在一定程度上促进了项目的质量。现在我将之前对自测bug的处理经验，草拟一份关于OA项目组的管理制度。
1. 鼓励项目成员对目前的系统处理提出质疑，只要有疑问，既可以与项目经理或项目其它成员沟通。
2. 除了我们自己定义的系统异常，其它任何系统异常，拼写错误，逻辑错误以及不能被立即解答的质疑，都可以定为自测bug。
3. 发现自测bug后，立即将自测bug以邮件的形式发给项目经理。
4. 项目经理负责将自测bug整理到wiki上和项目管理文档中，评估后再分给项目成员。
5. 自测bug在项目中的优先级为：a. 客户报告的优先级为(0,1)的bug；b. 自测bug；c. 客户报告的优先级为(2及以上的bug)
6. 项目成员在接到自测bug后，如果不是在处理优先级为(0,1)的bug，都应该先停止目前的bug修改，来处理自测bug。对于这点的执行，项目经理应该和处理该bug的成员作充分的沟通。

对于上面提到的“没有找到一个好的方法来避免目前遇到的问题”，已经在两周前的项目周会上讨论过。当时大家实际上是提出了相应的应对方法。但我感觉那只是讨论，因为在接下来的代码检查中，我没有发觉那些想法得到了任何体现。我之所以再次强调没有找到一个好的方法，是希望大家能够实践自己的想法，而不仅仅停留在纸上谈兵的想法阶段。
在这一点上，大家都是程序员，希望我们共同努力。
在业务逻辑层面，大家也可以充分质疑，然后和客户进行沟通。这周王提出的关于Reservation Product的质疑，虽然得到了客户预期的回答，但是客户从这个质疑中发现了系统中应该记录修改Reservation Product的日志。这一点是业务层面上对系统的完善。另外这周方提出的一个质疑，由于时间关系，没有来得及和客户沟通。

 

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