review设计文档

lesley

想和大家讨论一下你们公司是否有review设计文档或者code的举动。在review过程中，似乎效果不是非常明显，一般人不太愿意或者说有足够的时间去看别人写的东西，review是帮助大家找出不足的地方，这个过程会花费较多的时间和精力，但review又不能不进行，不晓得大家如何解决这个问题的

xiaonan

的确,在评审过程中需要花费较多的时间和精力,但有时候似乎效果不是非常明显,觉得评审似乎意义不大.但不能因为这样我们就放弃评审.我们要在前期就要尽量保证我们软件产品的质量.对于需求文档就要开始参与评审,不让前一阶段的缺陷遗留到下个阶段中去,已至于缺陷被放的越来越大和越来越多.导致修改这些缺陷所需的成本也越来越高,项目进度也会因为要过多修改这些缺陷而受到影响,也直接影响到了软件产品的质量.所以虽然表面上我们好象发费了大量的时间去对文档评审,但实际上我们是在早期就去除缺陷,用最少的成本修改缺陷,来提高软件质量.其实评审也是需要事先准备,计划和做好进度安排的.要例出评审点和检查点.参与评审的专家也要有足够的技术能力和经验,不然会把评审变成一种学习,找不出有价值的缺陷.评审一方面是在找出文档中和代码中错误,也可以用做对新人的一种培训和学习,看看人家写的文档和代码的优缺点.

[ 本帖最后由 xiaonan 于 2006-6-15 13:35 编辑 ]

luoyear

说说我们的搞法吧
1、做项目计划时候，要给评审留出时间，安排计划；
      假设你估算的产出50页设计文档，而本公司的评审速率一般来说是5页/小时，这就是说，你要给每个评审员10小时的时间去评审这个东西；
2、培训评审主持人，使评审主持人像管一个项目一样去管理一次评审
      事先要有评审计划；把关评审材料使其具备评审条件；跟踪评审员保证预审效果；评审会议做好主持；做好评审收尾工作；
3、总结经验，给出合用的检查单和有指导意义的质量数据

lesley

谢谢两位版主，如果时间比较紧的项目往往就把review省略掉了，后来又发现很多的不统一，实在是造成了不少的困扰，可能还是开发过程的规范问题吧。那review的时间也是安排在schedule里的是吗？
看来我们的项目要好好改进改进方式了

luoyear

是的
如果时间确实紧  与其不分重点 毫无目的性的应付性全面评审
还不如在计划时候就缩小评审范围
保证重点内容的评审效果

viviana_wdy

我们公司是关键代码是小组汇审，其他是开发人员自审，经理随机抽查

china_breezy

评审的效果是有的，但是成本也是高的。一堆人围在一块评审，就是N倍的投入。也正是这个原因，在效果和成本的性价比下，初期就让很多项目组放弃了。

如果能建立典型，有做评审的，在项目后期的效果明显好在哪，节省的bug修复、沟通交互等。典型带动下，会有人跟随的--谁有案例借我参考参考:)

songfun

楼上的又是要度量啊 呵呵

viviana_wdy

关键是有没有一个制度把评审的活动规范化和制度化，不是谁一时高兴就提了建议大家一堆人拿着用例开始头脑风暴了，结果最后效率的确很低很低
1、需要有一个内部的工作流程确定什么时候需要召开什么内容的评审
2、评审必须有专人来主持，并且定出评审规范，否则瞎评可不行
3、为了提高评审效率，我们经理一般会预先把用例内容划分一下，每个测试人员自己先单独看一遍，然后按照用例格式、书写规范、设计流程这些内容，每个人各自归纳出来一个问题清单
4、之后开大组会的时候会把发现的问题讨论，然后负责当前测试用例书写的人回去修改测试用例
5、修改完毕之后，经理把之前独立检查用例的人员角色都调整一下，每个人再回去看用例的不同地方
6、再开一次大家交换意见，然后这个模块的用例就pass了


我们这么做的效果非常好，改变了以前每个人只了解自己测的模块内容的情况，现在就算把测试人员轮岗，测试的结果出入也不会特别大