基层研发管理－巨头的成功实践－第四招：走读、检视、

作者：fujoey 提交日期：2005-6-2 19:24:00

　　
　　个人感觉这三项操作比较类似，所以放在一起。走读主要是代码走读，记得英文原名是walk through。 检视也称为正规检视，，英文原名是formal review，检视的对象一般是设计文档等。 评审一般是评审各种文档，与走读和检视的区别在于审核作用，通过评审的文档相当于得到了授权，作为企业的正式文档使用。走读和检视、评审通常都与IT办公系统中的电子流结合，便于跟踪和记录。
　　代码走读和正规检视都是先把设计文档、代码、测试用例、工作计划等要检查的对象先发给几个相关的人员，请他们先预审。检视人员要在看的时候，记录下发现的所有问题，并记录下来。看完后再选定一个时间开走读/检视会议。当然，会议时间在确定代码走读和正规检视时就要确认，在码走读/检视通知时就要说明，要给检视人员流足够的检视时间。会议过程中，发现的问题要仔细记录，责成作者会后解决。解决问题后的设计文档、代码、测试用例等，还要再发给检视人员确认。如果有必要，可以再开一次会议讨论（通常第一次会议开两个小时，所以这次会议也叫第三小时会议）。
　　走读/检视会议上一行一行的朗读检视对象。每朗读完一段，只有经过所有人员确认后，才能进行下一段。朗读人必须不是作者，而且要给其它人解释有些模糊的地方。只有朗读人解释不清楚的时候，作者才能出来说明。朗读的时候，大家就跟着看，同时思考检查对象有没有问题。如果有人认为朗读的部分可能有问题，不管是预审发现的还是当时发现的，就进行详细讨论。
　　走读/检视会议的参加人数最好不要超过十人，个人认为5－8人最合适；最好在会议室中进行；时间控制在2小时左右，超过3小时的话可以在中间安排休息。
　　在实践中，发现走读/检视确实很有效，所有参加人员都比平时思考得更仔细，更能发现问题。朗读过程中，作者、朗读人都会处于精神高度集中状态，大脑都会超速运行。作者因为害怕自己的设计文档、代码、测试用例等被其它人检查出问题，所以会加倍的仔细思考。这种公众场合，给作者产生了很大的压力，也是巨大的动力。在实际场合中，经常发现作者自己就发现了问题。为什么作者平时看了一遍又一遍，没有检查出问题，在检视会议上，就能很快发现问题？应该是作者在高度紧张的情况下产生的灵感。朗读人由于要读设计文档、代码、测试用例等，自然就很仔细；而且他还要给其它人解释，所以会快速思考，因而也会仔细的检查设计文档、代码、测试用例等。其它人思考得也比平时认真。我认为原因有好多，一个原因是人的天性就偏向给别人挑错，所以找别人错是一件很有成就感的事；第二个原因是参加人员想学到更多知识；第三个原因是希望表现自己得技术水平。
　　由于走读/检视很有用，可以经常挑选一部分代码举行代码走读。每位员工每半年应该举行一次，项目组每月至少举行一次。但是也不要太多，最好每位员工每个月参加的走读/检视会议不超过两次。
　　评审主要用于工作（主要是各种文档、计划）完成后由部门同事、领导、其它部门相关人员进行审核和确认。虽然评审也找问题，也进行修订，但是更多是起审核和确认的作用。评审完成后这些文档、计划就归档了。评审一般都使用电子流，这个电子流也可以用于走读和检视。电子流中有提交人、主审人、评审人员、作者等角色。大多数时候，提交人就是作者，至少是责任人。提交人创建电子流，提交给主审人。主审人指定参加评审（走读和检视）的人员。评审人员一般有同行、领导、上下游相关人员、测试人员。评审人员审查这些文档，提交意见。提交人根据意见修改，再请评审人员审查；直到所有评审人员都认为可以通过。主审人确认后，就关闭电子流。所以评审流程和走读、检视的流程差不多。但是评审可以不开会议，评审人员直接在电子流上反馈意见，作者直接在电子流上处理意见；可以在电子流上进行多个回合的交互。
　　计划、设计文档都应该经过评审才能归档。
　　走读/检视/评审的作用都很大，可以起到培训人员、质量审查、工作审计等作用，甚至可以起到批评和教育人的作用。有次有个同事写的文档比较，语句不通。我给他说了后，他说他认为没有问题。于是组织了一次评审会议，其它同事给他提了很多意见后，他就认认真真改了。
　　评审时的主要问题是评审人员不能认真参与。由于不是自己的专门任务，有些人员只是走过场。而且有时文档、代码量太大，在短时间内无法完成。时间最好控制在两个小时内，大了就进行拆分，分给不同人进行评审。
　　有时也由于评审对象质量不高，评审人员找出低级问题后，就不再研究深层次问题。避免这种情况需要作者先自己把握好质量关，或者预先请一个相关人员检查一遍。第一个相关人员可以作为第二责任人，排在工作计划中。
　　为了督促作者自己把好质量关、督促评审人员认真参加评审，评审完成后要统计每位评审人员花费的时间、每位评审人员找出的问题数（还分别统计提示问题数、一般问题数、严重问题数）、总问题数（还分别统计提示问题数、一般问题数、严重问题数），从而对作者和评审人员进行考核。主审人根据问题统计给各个评审人员打分（排序）。打分时，主审人可能都打高分，应该限制总分数；也可以根据评审文档、代码的大小制定总分数，分数代表工作量大小和好坏。
　　
　　请问你的公司经常使用走读/检视/评审吗？
　　请问你认为走读/检视/评审的作用有什么额外作用吗？
　　请问在举行走读/检视/评审过程中，发现有参加人员走过场的吗，你是怎么避免的？
　　请问你参加走读/检视/评审的频率大概是多少？
　　请问你在走读/检视/评审过程中学到过新知识吗？
　　请问走读/检视/评审过程中为你的代码、文档找到过错误吗？