如何提升(软件)交付质量
大家可先看看下面 Xerox 公司的缺陷统计数据
缺陷修复成本是越后越高，而且以倍数递增， 所以 软件工程有个重要原则，尽量第一次就把工作做好 (do it right the first time)，减少返工。
所以从软件质量管理，我们要：
-
尽力避免在整个开发过程中产生缺陷
-
如果有缺陷产生，要尽早排除。例如：瀑布性开发过程 - 要做需求评审，设计评审，代码走查 ， 单元测试
-
在过程中收集不同阶段发现的缺陷数，两个目标：a)把总的缺陷降低；b)把缺陷的高峰尽量往前推
下面首先会先介绍 CMMI V2.0 PR 与 VV 的 Practice 如何一一对应 以前 V1.3。
接着用一些实例解答如何从1级升到2级再升到3级，量化管理等的常见问题：
-
从1级升到2级：我们做好测试，有系统测试，有QA保证不就可以了吗，为什么要花精力做评审，尤其现在讲究敏捷、简单，评审是否已经过时？
-
为什么要把在评审中发现的问题记录下来并跟踪，让成员自发完善不是更省事吗？
-
为什么要有固定的测试环境？为什么重要？
-
为什么极少公司能做好量化管理？收集哪些数据？成功要素是什么？
-
量化管理、度量，为什么要统计？自己依据发现的问题改好是否也可以？统计出来的数据应该如何有效利用才对整个团队的提升有帮助？
例如：有效的量化管理必须依据有效的公司目标驱动,后面的金融产品开发组的量化管理例子告诉我们 - 除了要度量公司关心的结果外，也需要度量一些可控因素，才能更好帮我们改善。
最后以 ‘质量之旅’总结，让大家了解质量改进的路径图，与不同成熟度的差异。
整个讨论也对应CMMI V2.0 模型 的 ‘同行评审 PR’与 ‘验证确认(V&V)’各实践
-
目录
-
PA介绍
-
PR 1.1对工作产品进行评审并记录问题
-
VV 1.1执行验证来确保需求得到实现并记录和沟通结果
-
从1级升到2级：同行评审案例分享
-
PR 2.1开发并持续更新用于准备和执行同行评审的程序与支持材料
-
PR 2.2选择要进行同行评审的工作产品
-
VV2.1 选择用于验证和确认的组件和方法
-
Agile Tips 敏捷又如何
-
PR 2.3使用既定程序准备和执行选定工作产品的同行评审
-
PR 2.4解决同行评审中发现的问题
-
VV 2.2开发,使用并保持更新支持验证和确认所需的环境
-
VV 2.3制定、保持更新并遵循验证和确认程序
-
3级：从定性提升到度量与分析
-
与一金融产品开发组长对话
-
度量可控因素
-
PR 3.1分析从同行评审得到的结果和数据
-
VV 3.2分析和沟通验证和确认结果
-
VV 3.1制定、使用并保持更新验证和确认标准
-
质量之旅
-
附件1：敏捷团队如何有效利用度量数据分析
-
附件2：Inspection审查
-
反馈
-
References
-
PA介绍
PR (V2.0)
VV (V2.0)
VAL (V1.3)
VER (V1.3)
CMMI V2.0从V1.3特别抽出“验证”(VER) 中的第二目标“同行评审”作为一个单独的PA。 可见CMMI也认同同行评审确实可以帮助项目预早找出缺陷和问题，减少后面的返工。
在V2.0， 同行评审的大部分实践属于CMMI 2级 (分析部分属于3级)。以前在V1.3，“验证”(VER)，包括同行评审，和 “确认”(VAL) 都属于 3级，工程部分。
2.0版本和1.3版本的对应：
V2.0 对应 V1.3
什么属于 验证(VER) 或 确认(VAL) ， 一直有很多争议 (我确实见过 一些开发公司 V V 的 定义 与 CMMI 的定义刚刚相反)
V1.3 的 VER 与 VAL 本来就很相近： 如果把VER 的 中间第二部分抽出来， V 与 V 的内容基本一致：
PR 2.1 2.2 <= V1.3 VER SP2.1
PR 2.3 2.4 <= V1.3 VER SP2.2
PR 3.1 <= V1.3 VER SP2.3
VV 2.1 <= V1.3 VER / VAL SP1.1
VV 2.2 <= V1.3 VER / VAL SP1.2
VV 2.3 <= V1.3 VER SP3.1 / VAL SP2.1
VV 3.1 <= V1.3 VER / VAL SP1.3
VV 3.2 <= V1.3 VER SP3.2 / VAL SP2.2
PR 1.1对工作产品进行评审并记录问题
Perform reviews of work products and record issues.
对工作产品进行评审并记录问题。
Value 价值
Improves work product quality and reduces cost and rework by uncovering issues early.
通过尽早发现问题，提高工作产品质量，降低成本和返工。
VV 1.1执行验证来确保需求得到实现并记录和沟通结果
Perform verification to ensure the requirements are implemented and record and communicate results.
从1级升到2级：同行评审案例分享
以下例子说明, 无论是敏捷或传统开发,都可以使用一些CMMI的最佳实践，如同行评审，帮助改善质量。
敏捷开发越来越多人谈，在杭州客户现场，刚好就有本地咨询顾问，印度CMMI评估师 和我。 印度老师 除了有20年的CMMI经验外，也是敏捷的导师。有些人误解以为敏捷就是要减轻过程，可以不需要文档，只是把开发做好便可以。
我们在和测试人员讨论他们如何评审测试用例，他们说直接把写好的测试用例发主管，主管觉得可以就可以。其中一位评估组成员觉得不合适，另一位偏敏捷的觉得同行评审测试用例这活动没有价值，可以节省掉不做。
印度老师说：同行评审有多个不同的形式，有些较严格，有些较省力，如发邮件去让其他人看。
问：对不同的产物有那些不同的评审方法？ 这企业就展示出在项目计划中的一个列表：
-
需求 - 需要客户评审
-
设计 - 需要同行评审
-
代码 - 也是同行评审
问：同行评审如何定义？ 规定怎样做？
这企业不同人有不同的理解，公司级也没有明确定义。
老师接着说：如果同行评审是指审查(Inspection)，代码也用正式同行评审是很理想，但可能太花人力，所以越来越多团队使用静态（代码）检查。
评审方法有很多，常见的包括：
-
审查(Inspection) - 最正规，最严谨的方法，通常用于重要的产物，比如框架的设计
-
走查(Walkthrough) - 要求低一些，例如 一起开会，把产物投出来一起看
-
最简单也可以是两个人互相查看，或者发邮件
(附件2 详细介绍 Inspection 审查)
老师接着说：计划时也要定那些工作产品选用那种评审；例如，像以上那种只说设计/代码都是采用某种评审方法便太笼统
他还建议需要有一个项目的质量计划 (Quality Plan)，预先列出对那些阶段的那有产物采取什么方法来评审。也预定每个阶段要达到什么质量要求，如发现多少缺陷。
例如：代码评审 - 核心的代码你可能就需要做正规的同行评审。但是如果是一些用户界面那种就简单一点，但必须要质量计划(或项目计划)里面预先定好，然后按照计划去做。
PR 2.1开发并持续更新用于准备和执行同行评审的程序与支持材料
Develop and keep updated procedures and supporting materials used to prepare for and perform peer reviews.
PR 2.2选择要进行同行评审的工作产品
Select work products to be peer reviewed.
VV2.1 选择用于验证和确认的组件和方法
Select components and methods for verification and validation.
因为不同的评审方式，各有利弊，所以首先要定义好每一种方法，让团队可以挑选最佳配搭。 同样原因，也需要选择哪些产物要怎样评审/测试。 上面同行评审案例分享中的质量计划(Quality Plan) 便是一个例子 - 预先策划好那些产物采取什么方法来评审最合适。
质量计划(Quality Plan)例子
因为团队有信心采用新的代码评审方法后，可以提高代码评审的缺陷发现率，在质量计划中，代码评审的缺陷密度设定比历史数据的基线高，但是比模型预测较高的缺陷密度数低一点。
Agile Tips 敏捷又如何
如果我们不是按传统的瀑布式开发，没有明确的需求、设计阶段，按敏捷迭代来做，是否同行评审这种最佳实践便用不上？
大部分的敏捷团队都有用静态检查，效率比人工评审高；但复杂的代码还是要依赖人工评审。例如：有些金融的核心模块，因算法复杂，很难单靠测试找出缺陷，必须依赖专家查看代码(评审)。
因直接看代码，评审还是会比测试更有效率。(测试发现有缺陷，还是要看代码) 所以不要以为敏捷就不需要评审，如果你还记得较早的一种敏捷方法叫极限编程 (Extreme Programming)，它提倡的结对编程(Pair Programming)就是一种评审，只是不等到写完代码才做，而是写代码时，与坐在旁边的同伴编码与评审同时进行。而不是写完代码后才评审，发现缺陷。
目的很简单，无论评审还是测试，尽可能早做，找出缺陷。
从批量交付到持续交付的例子：
构建测试环境，端对端持续测试。
PR 2.3使用既定程序准备和执行选定工作产品的同行评审
Prepare and perform peer reviews on selected work products using established procedures.
PR 2.4解决同行评审中发现的问题
Resolve issues identified in peer reviews.
技术评审（例如：代码走查、设计评审，或者需求评审）的通病是缺乏检查单，也缺乏评审记录。为什么要检查单，其实是个经验的累积，哪些问题以前常常出现，就应该变成检查项，后面的评审要注意，评审好比测试，目的是，用最短的时间，最小的力度，找出最多的问题。
很多人说自己有做互相代码的检查，但在问有什么发现，有什么记录就记不清。
还有就是这些缺陷如果要修改，怎么确保修改正确？没有改错？因为有可能本来没有问题，改完反而出错。
VV 2.2开发,使用并保持更新支持验证和确认所需的环境
Develop, keep updated, and use the environment needed to support verification and validation.
大家可能都遇过因为环境不一样，有些缺陷测不出来。
我们一个香港政府部门客户IT部门，必须所有新开发的系统在他们一个固定的标准测试环境进行验收测试，通过后才允许放到投产环境。证明稳定的测试环境很重要。
从批量交付到持续交付的例子：
确保环境稳定并持续可用。
VV 2.3制定、保持更新并遵循验证和确认程序
Develop, keep updated, and follow procedures for verification and validation.
如何写好测试用例，如何做好功能或性能测试 本身是一个很大的题目，也有很多专门针对测试的书籍，尤其是自动化测试，大家可能比我更熟悉。
3级：从定性提升到度量与分析
”没有度量，就没有管理”这话大家都赞同 但有多少软件开发公司真正的使用一些可靠数据，帮助团队持续改进？ 大部分公司都用一些工具来管理缺陷，但系统地统计并利用这些数据的团队不多。
敏捷团队度量分析例子1
当听到数据驱动，大家可能立马想到一些包含仪表板的工具，如SonarQube和Jira:
-
如图1所示，SonarQube关注的是代码度量:复杂性、单元测试覆盖率、重复等等。
-
如图2所示，Jira关注的是过程度量:问题解决时间、团队速度等等。
一团队实现数据驱动连续改进过程时，领导只是单看 仪表板上的新增代码行数(LOC)，导致开发人员。 只为了追求这数字，想尽办法出增加这个数，而不是如何提升生产率和代码质量，最终导致整个度量分析改进计划告吹。
所以软件分析仪表板虽然是非常有用和重要,但必须谨慎引入，而且动机要正确。如组织缺乏敏捷文化，管理层很容易以为度量程序是用来从外部“管”质量和生产力，导致团队会把它理解为管理者不信任他们，反而影响了团队的动力。
测试也一样，如果只是单一的追求开发过程中缺陷密度(或缺陷数),效果也会一样。
例子2
研发主管问： 我们每个开发工程师都有用静态检查查代码质量，但为什么要统计？自己依据发现问题改好是否也可以？ 你不是提倡研发人员自主管理吗？
答：理论上是可以，但实际上如果公司没有系统地统计，你估计开发工程师会主动定期记录/统计吗？
| 我的老同学在深圳东莞，有一家"知识工厂"，专门为国外做英文输入。例如他有一美国老客户，提供网站专门为客户寻找自己的祖宗信息，需要把大量老报纸，书籍，船票的扫描，利用人工配合电脑辅助，输入成英文文档。因为项目的利润都很薄。生产率很关键，如果生产率低项目就亏本。同样质量也很重要，错误率也要很低。 生产场所坐满时有二三百人，很多小组组成。每小组大概十人，有组长。每个组的大长桌上面都有一显示，显示当前的生产率与错误率。管理服务器也会不断收集与统计每个小组的度量。每个小组和组长都很清楚自己组的表现。组长会尽力帮自己组提升水平。生产总经理会与各组长每天回顾成绩和如何提升。 |
我说完以上故事，便继续问研发主管，如果这"知识工厂"没有系统地收集，统计与显示生产数据，只靠每小组或每个工人自我管理，可以保证项目的利润吗？
所以回应你的提问，我估计不会，或最多统计几轮便不继续。没有度量，没有压力，我没见过你说会自动不断自我提升的‘圣人’；而且人不是机器，骨子里是很厌恶不断做一些重复性工作 - 手工收集与统计数据。
度量分析例子3
问研发主管：你们怎么利用缺陷的统计工具来确保产品质量？
答：我们现在用自动检测工具，比如:静态检查 / SonarQube，可以帮我发现一些问题，当我从这些报告发现有一些错误时，就会问相关的开发人员，叫他改正。
当我在访谈下面的开发团队时，问他们怎么利用度量数据来帮助确保质量，他们都说不出来，只是说后面会有系统测试来做检测，QA人员也会定期检查来保证质量等。
以上例子2可看成是McGregor XY管理理论中的X型管理(家长式)，团队人员是受主管指挥，而不是自己主动来利用统计数据来不断改善。如果单靠X型管理，整个团队的质量就局限于主管有多少时间来检查，而不是由团队自发依据数据持续改进。
与一金融产品开发组长对话
从以上例子我们了解度量要与团队过程改进配合，也需要系统支撑，下面我们看看当主管与高层已经意识到数据的重要性，也有系统支撑，如何完善研发的度量与分析：
一家专门做金融产品的公司。上层对团队都有很明确的目标， 例如：
-
2周：需求交付周期——从想法提出并确认，到上线的时间
-
1周：需求开发周期——从需求设计完成到上线的时间
-
1小时： 测试验证时长——在集成过程中，对变更的测试验证时长
问：你们高层有这么高的要求， 你们究竟要度量什么？
组长答：交付吞吐率 （单位时间内交付需求数）、交付周期、开发周期，发布频率、交付后线上的缺陷数，与修复缺陷所需时间，开发过程中发现的缺陷数与排除数等。（如图）
问： 确实很多要求。但你们还度量什么来确保可以达到以上是要求？
组长有点迷茫地望着我，然后答：我们主要就是度量这些。
| 度量与分析有一个很重要的概念——不应仅仅度量结果，也要度量那些会影响结果的因素。 好比如果要减肥就不能每天仅仅度量体重，还要每天收集运动量与吸收了多少卡路里。 |
我继续问组长：你们团队用什么方法去提高交付率，也同保持质量？
答：把本来复杂的大模块细分成小模块，也尽量减小之间的耦合度，本来是类似瀑布性的开发，最后才集中力量测试，改成持续的迭代开发，控制每两周发布。
问：效果如何？
答：非常好。
他立马在电脑展示过去六个月他们用了新方法后的结果。
虽然这组长没有度量可控因素，但他心里很明白以下的原理：
-
软件越复杂，质量就越难控制
-
控制每个迭代的周期：两周。持续交付是可以提高交付率，也保证质量。
这些最佳实践在很多成熟的国外软件团队都验证过，证明有效。
我表扬了组长的好成绩后。便介绍他可以利用 GQM(goal-question-metric)来找出一些会影响结果的度量来帮我们更好控制结果。
我先沿用他已有的度量：
G: 提高交付率，也同保持质量
Q: 程序越复杂，模块越大，越容易出问题？
M: 度量程序的复杂度、模块的大小、耦合度，
也度量效果：交付周期，新增缺陷/关闭缺陷，线上缺陷与问题解决时长
一方面帮我们验证一下他的假定是否正确？另一方面，如果我们发现有些模块，复杂度高便要预警。
因这些很可能会导致后面出现质量问题。 GQM也可以系统地帮我们把要度量的可控因素与希望结果关联。
我接着跟他分享了我们杭州案例：
| 我们很清楚如代码本身不好，肯定会影响质量与交付，所以我们一开始便培训开发团队编程，避免一些陈旧的语法， 如 if - else, for, switch - case...。代码尽量简单直接。 培训后我们便要求团队每两周度量有多少陈旧语句，测试发现缺陷多少？交付了多少新功能点，我们收集了六轮，陈旧语句迅速降低，交付与质量也逐步提升。 |
我再问组长：你估计每次变更代码多少，是否也会跟缺陷有关？
答：很可能。
问： 你们好像也开始用静态检测。
答： 是的
问： 是否对提高代码质量有帮助？
答：肯定
问： 有没有想过也应收集这方面的数据来预测交付质量？
我便继续与组长把所有他觉得影响也可以收集的度量列出来。
组长问：我们定了那些度量如何收集？
答：比如代码变了多少是可以从配置管理系统收集。当我们帮企业改善度量时，常见问题是客户没有系统收集数据，大家可以想象，人工收集是无法长期的，也很难确保数据是否正确。 直接从系统导出可避免这些问题。因你们一直用 GIT ， JIRA 与 SonarQube，可考虑类似下图，定期导出数据。
我接着说：你们一直强调要定期做复盘。以前复盘时缺少中间影响因素数据。只有结果数据。后面做复盘分析是否会更全面？
组长答：我们过去讨论时，大家都会说很多理由。但最终选择怎么改进还是依赖那些有经验的人士说的算。我估计多了这些数据讨论会全面多了。
我说：你们有影响因素的数据，便可以针对问题，对症下药。比如确实某些语句的问题影响到质量。便要更新编码指南，加强培训等，预防后面质量出问题。
不仅仅有这个好处，你们不是也做了一些大数据分析，机器学习项目？当我们不断收集数据，到了一定的数量便可以用这些新的方法去量化管理。 例如预测哪个模块会缺陷较多。
度量可控因素
当我学软件工程时，数据挖掘、机器学习没有这么流行。开发的环境工具和现在不一样。那时候的预测模型，比如预测缺陷、预测工作量会用一些很主观的因素，例如团队成员经验与能力、过程成熟度、团队合作性，也有一些较客观的因素，如语言、复杂度等，但如何校正模型的参数是个难题。导致模型很难可以在不同公司使用。而且那些时候大部分项目都是传统的瀑布性开发，不一定适用于现代迭代，持续交付的开发模式。
请不要误会，以为上面这些因素，如经验、能力不重要，这些都重要，只是非‘可控因素’(controllable factor)。对度量分析的预测作用不大，预测其中一个目的是希望我们可以在过程中凭一些过程中的指标，预测结果。例如,我们发现静态检测的缺陷数与后面发布后的产品质量，或遗漏缺陷数相关。例如,我们发现代码模块大小与复杂度与后面的质量相关，就可以在开发过程中收集这些数据来预计最终的质量，不要等到发布后才发现质量不行。
反过来，我们很难使用团队人员经验或能力来预测/控制结果。
除了主观判断以外，主因是这些因素难以在过程中改变，一旦发现人的能力和经验达不到要求的话，你可以在团队开发中换人吗？估计不太可能。
所以我们更需要一些过程中的客观、可系统收集并可控的因素来预测结果。
下面让我们看看如何对应 上 CMMI V2.0 VV PR 3.X
PR 3.1分析从同行评审得到的结果和数据
Analyze results and data from peer reviews.
VV 3.2分析和沟通验证和确认结果
Analyze and communicate verification and validation results.
从上面组长对话 与“附件1 :敏捷团队如何有效利用度量数据分析”，大家可看到数据分析与有效沟通同等重要，可以互补，所以在V2.0 也加入沟通。
VV 3.1制定、使用并保持更新验证和确认标准
Develop, keep updated, and use criteria for verification and validation.
当我们有历史数据支撑，知道过程中的哪些因素会影响最终目标，我们便可以更具体规定开发过程中，无论是编码，静态检查，单元测试，系统测试， 要达到什么程度。
质量之旅
质量改善绝非一步到位，CMMI “创始者”已故Humphrey先生概述以下七步“质量之旅”:
-
尽快开发出产品，测试，改错 (Test and Fix)
-
开始在测试前做检查（评审）希望尽早找出缺陷并解决 (Inspect)
-
开始使用一些数据来改善评审过程 (Partial measurement)
-
开发工程师从参与回顾，开始意识到要预先自我评审自己的产出物，减少错误(Quality ownership)
-
为了提升，工程师开始记录自己的引入缺陷数，排除数，产出物规模，花费时间等 (Personal measurement)
-
工程师完善设计方法 (Design)
-
度量+设计已降低了大量缺陷引入，再系统地避免缺陷，进一步提升质量(Defect prevention)
-
最终应度量客户重视的质量要素，驱动整体质量的持续改进 (User – based measurement)
我们也可以利用CMMIV2.0 判断公司质量改善的成熟度 (V2.0 比以前V1.3版更明确), 从下面汇总表，大家可以看到公司验证、确认、同行评审过程改善的阶段：(也可以把下图看成一张地图，帮我们更好理解上面案例 / 例子在整个“质量之旅”中的位置)
从上面的总表，你是否觉得你认识的软件开发公司很少处于较高成熟度？ 为什么？ 因公司要推行度量与分析必须：
-
高层要有较高的交付与质量的量化要求。因要开始团队做度量分析，开始时要有不少投入，如果没有提升压力，很多时候会半途而废。
-
培训与系统同样重要。单靠团队自己摸索，或依赖人手收集数据都很难成功。
-
沟通也非常重要：团队必须有‘以数据说话’的文化，定期分析数据做改进。
所以当质量工程师问我，如何帮他们公司推进量化管理，我会反问她领导的主要关注点。
如果他们都觉得已经很清楚项目的情况，不需要客观数据，无论这质量工程师如何努力都不会有什么结果。
附件1：敏捷团队如何有效利用度量数据分析
公司已创立了十多年，正在使用敏捷方法，但没有使用很多度量标准来监视和优化。由于复杂性增加，团队面临着越来越多解答不了的问题，包括:
-
是否和十年前一样快速高效?
-
如果不是，什么原因可以解释慢速度吗?
-
如果速度确实慢了一些，那么在质量和可持续性方面有什么提升?
-
是否应该引入或调整一些过程来改进某些方面?
这些都是复杂问题。没有数据就很难进行有根据和建设性的讨论，也很难评估为改善这种情况而采取的任何行动的影响。
这个案例很有趣，因为开始时，有很多历史数据可用。版本管理系统中的数据、问题跟踪服务器、代码评审平台等。 越来越多研究如何应用数据挖掘和可视化技术，从这些知识库收集数据，被称作软件分析(software analytics)。
最终目的是帮助他们发现有价值的信息。进行沟通，最后记录并分享他们的见解。步骤:
-
运用目标-问题-度量(GQM, Goal-Question-Metric) 方法来决定具体的分析目标，推导出一些相关的具体问题，并定义可以用什么度量来回答这些问题。。首轮选择的目标是：评估交付的速度是如何随着时间演进。
-
访问公司软件数据库:版本管理系统,问题跟踪,敏捷规划工具和代码评审平台等。利用一些软件从这些库中提取数据,为建立统一的模型和 可视化准备。
-
然后，组织了一个研讨会，让团队讨论软件和组织的演进。为了支持这讨论，我们将一些可视化结果打印在大型纸质海报上(请参见下图），该示例显示了跨存储库的团队活动和发布的频率。此外，我们还配合一些交互式可视化投影。在工作坊中，参与者走进房间，看着可视化展示的数据，很自然地参与了小组讨论。我们观察了这些参与者，并记录下讨论要点。
-
我们将在数据分析过程中获得的事实见解和在研讨会中获得的观点集成在交互式报告中。我们的软件分析平台使生产交互故事成为可能，它结合了叙述和数据可视化。这些故事总是为特定的读者而写。例子：
-
某人想写一篇关于测试驱动开发价值的故事，并针对加入团队的新开发人员
-
CTO 想编写一故事来支持他与管理团队的交流
-
某团队想编写一故事来庆祝成功采用了一个新过程，以及在质量或交付时间上的好成绩
-
从这个实验的经验教训：
-
数据可视化和媒体的影响：在大家参与讨论的工作坊中，墙上的海报起到了吸引参与者积极主动参与的键作用，单靠幻灯片投影绝不会达到同样的效果。以视觉形式看到过去十年发生了什么，对参与者来说也有情感方面的影响，引发更多多讨论。
-
讲故事的形式提供了有效的方式来传达信息，有效地补充仪表板数据的不足。这两个界面的目的不同，但它们都可以构建在相同的软件分析平台上。
附件2：Inspection审查
-
是一种正式评审， 目的是严格与正式地识别工作产品缺陷
-
详细检查，明确地检测和识别缺陷
-
作者不得担任主持人，管理者通常也不允许参加，以确保公正
-
必须正式跟踪处理所有主要缺陷
-
系统地收集缺陷数据并存储到检查数据库，对缺陷数据进行分析，以改进产品、过程和检查过程
Inspection 包括:
-
验证工作产品既满足其规格要求
-
验证工作产品是否符合适用标准
-
识别与标准和规范的偏差
-
收集工程数据(如，缺陷和工作数据)
-
不检查风格问题
虽然它需要的投入比其他评审方法高，但它最能找出缺陷。
审查员的职责
选择审审员:
-
识别和描述产品或产品组件中发现的主要和次要缺陷(检查)
-
代表不同的观点(需求、设计、开发、测试、独立测试、项目管理、质量管理等等)
-
分配特定的评审主题以确保有效的覆盖
-
符合特定的标准
-
整体的一致性
最低进入条件：
-
产品或产品组件完整，并符合标准
-
可用自动错误检测工具
-
有支持类文档
-
对于重新检查，缺陷清单上的所有项目都已解决。
-
有训练有素的主持人和足够数量的熟练审查员
审查准备工作
审查组长必须确认审查人员是否已做好准备。如果没有充分准备，组长可以重新安排日期;
审查缺陷列表;
记录员负责记录每个主要和次要的缺陷、与位置，缺陷列表上的描述和分类。作者应该准备好回答提问。如果对某个缺陷存在异议，则应在会议结束时记录并标记为潜在缺陷。主持人负责与团队一起评审缺陷列表，以确保它的完整性和准确性。
反馈
一位总工对文章初稿的反馈：
从三年前，我们开始用静态代码检查工具，确实有效果。但需要注意两点：误报的剔除（有些问题其实严格讲不算问题），另外，不能为了消除警告把原本的业务逻辑改坏，或者是修改导致性能降低。
一位很熟悉银行业务的IT顾问反馈：
很棒，通俗易通。目前在企业中的软件开发过程PR、VV的实施中存在如下困境，你看是否对您编辑稿件有触发作用。
-
评审缺乏专家，耗时较多，但评审出来的问题质量不高，较多的问题并未被发现，参评人员参与度不够，存在部分评审过程只是走流程或形式。
-
评审材料本身需准备较长时间，领导层、技术人员比较看重技术实现的结果，对于评审的关注度不够，甚至认为浪费时间。
-
关于度量，目前过程中的数据类型很多，但前期度量规划、分析不到位，导致数据很多，但没有有效的汇总、分析和利用。
References
Humphrey, Watts: TSP; Leading a Development Team
Kasse, Tim: Practical insight into CMMI 2/e
Liechti, O.: Beyond dashboards: on the many facets of metrics and feedback in agile organizations
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
