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