评审是一项重要的质量措施，但是某些项目中组织的评审效果不好，事倍功半。
结合个人的经验，总结出一些有效评审的注意事项：
1、评审员的选择，在于精而不在多，建议选择1－3个真正的“专家”即可。
人多了，有的人可能会觉得我不认真审反正还有那么多人在审呢，导致“三个和尚没水喝”的结果。
一个“专家”胜过十个外行，一个“负责”的人胜过十个敷衍的人。
2、评审对象不易过大，可以参考“90分钟原则”（90分钟内能够完成个审）。
如果一次对几百页的文档进行评审，很可能是前几十也看得认真，越往后就越快了。连续审查时间过长会大大影响效果。
任务拆分有个80小时原则，这里可以学习，来个“90分钟原则”什么的，如果评审对象过大应考虑拆分成多个进行评审。
3、评审过程的一头一尾要抓住。
一头，是指个审，这个评审会议的前置条件要卡住，如果个审不充分，宁可评审会延期也不要仓猝召开。
一尾，是指评审会结束之前，需要对评审会的决议进行回顾，明确哪些是缺陷。
质量措施的重要性，大家没有异议。但是，当项目面临巨大的进度或成本压力时，质量这个隐形属性相比较于产品特性、时间进度等“看得见、摸得着”的显性属性，通常是最容易被舍弃的。而现实中的软件开发往往都是在较大的进度压力下进行的。为了保证基本的质量措施在各种压力下得以落实，想到对质量措施进行“分级保护”的办法。
1级，最高级，任何情况下都不可以省略；
2级，高层经理批准后可以省略；
3级，项目经理批准后可以省略。
大家把驾驶技术不高的新手，形象的称为“马路杀手”，形容这类人员对马路上的他人和自己存在巨大的威胁性。其实，在软件开发中，没有良好编程习惯的新手，即便是名校毕业的高才生，也会给软件系统带来无穷无尽的BUG。很多职业都有准入门槛（如职业资格认证），反而是难度大、要求高的“软件工程师”这个职业，基本没有门槛要求。在绝大部分公司，应届毕业生是没有经过严格培训就直接上岗了。所以，提高软件质量的有效手段之一：
严防“软件质量杀手”！应该为软件工程师上岗设置门槛，培训合格的人员才能参与实际系统的开发。
在这章学到两点知识：
1）螺旋模型
面向风险的模型，每个环解决一个或多个主要风险因素。
以前在软件工程书里虽然学过，但是没有很好理解。这次通过这章的案例，有了理解。
2）面向进度的模型（design-to-schedule）
关键特征是按照优先级进行阶段交付，以可能损失低优先级的产品特性为代价，确保确定的交付期限。
Powered by Haiwit
