CMMI on line

开始之前，建议先看此贴：

http://cmmionline.net/forums/thread/214.aspx

 

验证就是按照既定的标准，检查工作产品是否符合要求。工作产品可能是文档也可能是软件本身。而检查的办法一般是同行评审或者是软

件测试。

 

那什么是同行评审呢？比方说：A君是做软件设计的，B君也是做软件设计的，A君写了一份设计文档，让B君这个同行（因为大家都是做设

计的）来给给意见，这样就使同行评审。同行评审的目的就是让有同样工作经验和技能的人来评审自己的工作产品，发现尽量多的问题。

 

验证这个PA其目的是希望软件企业在软件开发整个过程中，做好相应的检查工作，把尽量问题发现前面，保证了项目的可控性，降低开发

的成本。

 

这个PA有3个Specific Goals,SG1讲述的是做好验证的准备，SG2、SG3分别讲述的是执行验证的两种办法，一种是同行评审，一种是执行

验证（通常就是测试）。

 

如果测试是在用户实际生产环境下进行的，例如：验收测试、客户试用系统等，这时这类工作就属于确认(Validation)了，请参考关于“

确认(Validation)”的帖。

 

SG1 Preparation for verification is conducted.

准备验证的工作。

 

SP1.1 Select the work products to be verified and the verifaction methords that will be used for each.

选择需要验证的工作产品以及每个工作产品的验证办法。

组织会定义要进行同行评审的工作产品，如：计划文档、需求文档、设计文档、代码等，并且规定了每种文档的同行评审办法。组织也会

定义需要进行测试的软件产品，比方说要进行单元测试、集成测试、系统测试等。

 

SP1.2 Establish and maintain the environment needed to support verification.

建立和维护支持验证所需的环境。

对于同行评审来说，支持环境可能就是会议室、投影、电脑、事先准备好的文档等。

对于测试来说，支持环境可能就是测试的软件环境、数据环境、硬件环境等。

 

SP1.3 Establish and maintain verification procedures and criteria for the selected work products.

建立和维护工作产品的验证过程及准则。

对于同行评审来说，验证过程就是同行评审开展的过程相关规定，如要事先发资料、通知大家到会、会议的组织、会议记录等等，准则可

能就是每个工作产品的评审标准。

对于测试来说，验证过程就是测试过程的相关规定，准则就是需求规格说明书，或者说是测试通过的标准。

 

SG2 Peer reviews are performed on selected work work products.

对指定的工作产品进行同行评审。

 

SP2.1 Prepare for peer reviews of selected work products.

做好同行评审的准备。

如：把要评审的文档实现发给大家，准备好会议议程，准备好会议室、投影仪等。

 

SP2.2 Conduct peer reviews on selected work products and identify issues resulting from the peer review.

执行同行评审并识别同行评审中发现的问题。

 

SP2.3 Analyze data about preparation,conduct,and results of the peer reviews.

分析在同行评审准备、执行、结果方面的数据。例如：记录评审的准备、进行时间，发现的问题数量，对每个问题进行分析等。

 

SG3 Selected work products are verified against their specified requirements.

根据指定的要求验证工作产品。

这里的验证既包括同行评审也包括测试，但因为SG2专门是针对同行评审的，这个SG可以理解成主要针对除了同行评审外的其它验证活动。

 

SP3.1 Perform verification on the selected work products.

对指定的工作产品进行验证。如：执行单元测试、集成测试、系统测试等。

 

SP3.2 Analyze the results of all verification activities and identify corrective action.

分析验证的结果，并制定修正计划。这里强调的是：除了要分析发现的问题外，还需要采取行动修正这些问题。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

张总：

您好！和你探讨一个问题：

当一个产品出来的时候，如：详细设计；我们要求要有同行的人进行个人的同行评审－review，但是有好多人采取的通知形式就是口头通知，作为PPQA遇到了这个问题，就跟他说：“不要以口头的形式通知，要写review票”，但是他的回答是：“为什么要写票啊？多麻烦啊，我这得写多少个票啊？我写完了，他还要处置，我还要再检查再写，艾，我说你们当领导的能不能为我们考虑一下，不写行不啊？”我跟他讲，留下证据有多重要。可是他又说“那跟我有什么关系啊？”

那到底同行评审有什么好处？这些好处有和程序员本身有什么关系？怎么来解决这样的矛盾问题呢？

谢谢！趴着等。。。

Rice

你的问题非常经典，我想问题的关键是参加同行评审的人是否已经真正体会到同行评审的好处，还是在走形式？

而作为PPQA，我们要关注的是：
1.同行评审是否真的发挥作用，对项目带来了好处。
2.是否留下了证据。
我们PPQA要先关注第一点，而不是留下证据，否则大家很容易抵触，本来有道理有价值的同行评审，大家如果因为要留下证据的问题，很容易变成大家走形式，然后就发挥不了价值，最后就会和PPQA对抗。

再说说同行评审的好处，问题越早发现解决成本越低，这个道理大家都懂，也能体会，同行评审的目的是：
1.尽快尽早发现问题。
2.采取适当的措施解决必须解决的问题。
请注意，并不是全部问题都需要解决的，并且解决问题的过程中，又会产生其它问题，然后又解决这些问题，然后周而复始，很容易很长时间都不能了结，这样就会出现类似他们的回答：“为什么要写票啊？多麻烦啊，我这得写多少个票啊？我写完了，他还要处置，我还要再检查再写，艾，我说你们当领导的能不能为我们考虑一下，不写行不啊？”
你们可以问问开发人员，问问他们同行评审应该重点检查哪些有价值的问题，同行评审的后续工作的完成标准，就是这些有价值问题解决了就可以了，而不需要规定全部问题都解决。你们可以问问参加同行评审的人员，问问他们怎样做才能发挥同行评审的好处，又不需要做这么多记录。

再说说记录的问题，如果认真做好同行评审，其实自然就会留下一些痕迹的，这些痕迹就是证据。这些痕迹，可能是：同行评审的计划、同行评审的记录、同行评审发现问题的记录。从评估的角度说，评估并不要求每一步都留下书面证据，如果为了评估强制要求大家做一些记录，大家也会抵触。当然我们也要思考，做这些记录是不是必要，是不是有利于项目组？如果是，大家自然就会自觉地做好这些记录。所以，我们PPQA也要认真思考，这些记录是不是必要？同样也可以问问参加评审的这些人员，应该做哪些记录怎样做才最简单最有效？按他们的方法进行。

PPQA和SEPG需要有软件工程的经历，否则是比较难以体会开发人员的痛苦，也很可能定出不利于大家执行的办法，要解决这个问题，就要想办法让大家参与到过程改进中，把大道理说清楚了，就问问他们应该怎样做最好，按他们的方法先做，持续改进。没有必要PPQA说怎样做，他们就怎样做，要知道执行这个过程的是他们，他们觉得痛苦的，自然就不会执行，要尊重他们的想法。
另外要吸纳一些软件工程的人参与到SEPG中，我们公司的SEPG就有很多来自项目的项目经理、开发人员、测试人员，做过程改进，一定要依靠项目成员，任何过程都应该让他们发挥主导，让他们定义做法，切忌SEPG闭门造车。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

谢谢张总的回答！

真是恰到好处，句句都说到点子上，明白呢明白呢（频频点头），而且读了好多遍您写的话，，全记在心里了。。。

觉得学完CMMI，真的是从骨子里改变了一些东西，让你的思维变得周密，灵光了，真是个好东西ね

本身还是太年轻，有些东西理解的深度还是不够啊。。。

以后还要多来请教张总！

Rice

问个初级问题：同行评审的准则有哪些？

如能回答，万分感谢。

不同工作产品的同行评审，标准是不一样的。我们不适宜定一个统一的标准来用于不同的同行评审。

我以代码同行评审为例，说说代码同行评审的可能的标准：
1.是否符合编码规范。
2.是否按照设计来编码。
3.代码的运行效率是够高。
4.代码是否健壮。
实际上一次代码同行评审，很难覆盖这么多内容，一般来说以上的标准1、标准2是最基本的代码质量要求，而标准3、标准4是高级的要求。代码评审循序渐进，抓住要害，如果最基本的代码质量要求达不到，就直接按照标准3、标准4来评审代码是不合适的。
对于编码功力比较差的员工，我们进行代码同行评审可能只需要就按照标准1、标准2来进行。对于编码能力比较好的员工，我们就按标准3、标准4来进行，标准1、标准2就不需要看了，因为这些员工都不会有这些方面的问题。而对于软件中核心部分的代码，则可能不管是什么员工写的，都需要按4方面的标准来评审，不能遗漏。

同行评审的威力是巨大的，但很多公司执行不好，很可能是我们指导同行评审的同事有可能经验不足，定出不太合适的评审过程和标准。如果要定同行评审的过程和标准，应该让做这个工作的人来思考应该如何定。比方说代码同行评审该如何做，最好办法就是让公司的编码高手发表一下，把他们的想法落实为过程、标准，这样才能保证做出来的过程和标准是实用有效的。

 

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

我们公司在进行同行评审的过程中也遇到类似的问题。而且比较困扰我们的是，从DP的角度，如果同行评审的缺陷没有记录下来的话，就无法进行缺陷分析和预防活动。而从开发人员的角度，他们只考虑这次或这个项目的问题修改完成即可，对于组织或其他项目的贡献考虑不多。

记录同行评审发现问题，有两层目标：
1.跟踪解决这个问题，即“只考虑这次或这个项目的问题修改完成即可”
2.“进行缺陷分析和预防活动”

如果目标1还不能很好实现的情况下，可以先放下目标2，以后项目组成熟了，就可以考虑目标2了。

最开始的时候，我们对于评审发现问题的记录，有这样的一个原则，如果问题能马上解决的，都不用记录。当时我们做CMM3评估时，丛斌博士并没有否定我们的做法，他还是比较认可我们的简单实用的原则，不过他建议我们考虑清楚，什么问题需要记录，什么不需要记录，需要记录的问题，哪怕是可以立刻解决的，也需要记录。

后来我们重新思考了这个问题，定了一些规则，大致如下：
1.文字表达之类的问题，如写错字、语法不对等，不需要记录。
2.能很快解决，如会议现场解决或者会后很快可以解决的，并且不会影响项目关键路径的问题，不需要记录。
3.影响项目关键路径，对项目成功有较大风险的问题，都需要记录并跟踪解决。

关于同行评审问题记录如何做到有效，我觉得关键是要定义清楚什么问题需要记录，记录什么问题对项目、对公司价值大，要用二八原则，抓住主要问题。不是所有问题都需要记录的，也不是全部问题都不需要记录。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

张老师,

想问下,sp2.1和sp1.3感觉有些重复啊,同行评审的准备,包括会议室啊,发资料给大家啊,不是和SP1.3一样吗,能帮忙解释下吗

首先我们得先看SG，每个PA都有相应的几个SG。简单的说就是有这个PA的几个主要的目标，或者说这个PA的初衷是什么。

然后每个SG下面有一个或者若干个SP，来实现SG所描述的目标。并且这些SP是按过程排序的。

SP1.3作为满足SG1(为Peer Review做充分的准备)的一个条件，而SP2.1是满足SG2(具体的怎么执行Peer Review)的一个条件或者说步骤。从这点来说，SP1.3说的是更为广泛适用的一个Practice,而SP2.1是做为执行一个具体的Peer Review的Practice。而这也是CMMI的严谨之处。

希望没有让你更加糊涂。 :)

---

-=P.CHi=-

SG1 Preparation for verification is conducted.
准备验证的工作。

SG1的意思有两个层面：
一、组织过程中要有验证相关的过程，规定什么东西要被验证，如何验证，验证标准是什么，采用什么方法等等。
二、具体项目开展时，各项目要根据组织级的相关规定，制定更加具体明确的，适合于本项目的验证过程。

SG1下面的全部Practice全部说的都是准备活动，还没有真正实施验证这个动作。

SG2 Peer reviews are performed on selected work work products.
对指定的工作产品进行同行评审。

SG2说的是具体的验证工作。

不知道你清楚这两个Practice的区别没有？
SP1.3只是在过程中和项目定义的过程中，将要做的事情写下来。
而SP2.1就是真正做这些事情了。

其实你只要多多留心，你会发现其实很多PA的SG1都是说组织规定和项目级的规定应该怎样，而SG2说的是具体的执行应该怎样。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

我们公司在做同行评审时，参与人员不全是同行。

比如需求规格说明书的评审，就需要客户、作者的同行、测试人员、EPG参加。

我觉得测试人员属于下游相关人，他的参与还算有道理。

但是客户和EPG参加就比较奇怪了，客户对需求的确认应该单独进行，而EPG也无法从技术角度给工作产品提建议。

不知我这样想对不对？

我们首先不要将公司的一些做法，硬是要和CMMI标准或者什么同行评审对得上。

我要先问问为什么要这样做？你们公司确实是客户、作者的同行、测试人员、EPG一起来评审需求规格说明书的吗？在客户参加评审之前，你们自己内部不先进行评审吗？

一般情况下应该是项目组内部进行评审，报高层领导审批后，才给客户签署的。
当然也不是非要这样做的，不知道你们的具体情况，你们觉得合理就可以的。

再回到同行评审的问题，CMMI要求要做同行评审，没有要求同行评审非要单独做，不能很其他东西一起进行。
以你们的做法为例，你们的评审，其实是混合评审，不是单纯的同行评审，每个角色根据自己的角度来提各自的评审意见，作者的同行就提同行的意见（这部分是同行评审），测试提可测性方面的意见，客户提是否满足他们要求的意见。至于EPG为什么要参加？EPG可能是想监控整个过程，同时也可能想发掘一些过程改进点。
你不必将这个评审冠上一顶帽子——同行评审，总之有效有用就行，不需要管叫什么名字。你可以和制定这个过程的人，还有执行这个过程的项目组一起来思考一下这个问题。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

谢谢专家的解释，非常清楚。

我们公司当前的确是这样做的，我是QA，但是评审这部分工作也由我来做，评审只有一次，就是大家一起做。

其实我也认可公司流程上的这种安排，虽然我们的评审没有起到该有的效果，但是问题的原因肯定不在参与评审的人员安排上。总体来说，我是非常认同根据每个机构的实际情况，来安排开发的流程的。

但是，我也一直有一个困惑，如果我们真的根据实际情况对CMMI的各个PA进行了大幅度的裁剪，那么我们的流程还叫不叫作CMMI?是不是仅仅是一个对CMMI借鉴很多的流程了？

虽然流程设计只要适合就好，但是因为我们是CMMI 3企业，我很想知道如果我们现在做的还算不算CMMI（以CMMI评估的标准）？

请澄清一点，CMMI中的裁剪，不是指可以根据需要选择性地做部分Practice甚至是PA。关于裁剪，请看：
http://cmmionline.net/forums/thread/1756.aspx

前面我提到“我们首先不要将公司的一些做法，硬是要和CMMI标准或者什么同行评审对得上”，意思并不是说CMMI很多地方不适用，而是我们对CMMI的各项要求还不是很理解的时候，很容易“生搬硬套”，一些合理的其实符合CMMI要求的做法，会误判为不符合要求，并且还会“硬生生”的将一些貌似符合CMMI要求但自己又觉得不合理的做法强制要求大家执行。

对于同行评审，CMMI没有规定一定要单独做，这也是我前面提到的。类似你们这个评审，你没有必要非要冠上“同行评审”的帽子，以“同行评审”的标准来看待，好像有一些非同行存在就觉得不合适一样。是否合适的标准，是你们觉得这样做是否合理和有效。
一个评审，有同行参加，也有客户、QA参加，甚至高层参加，这些都很正常，CMMI关于同行评审的要求可以体现在这些评审活动中，关键是你们怎样定义这些评审过程的。如果是多个角色参加的评审，那就需要订好相应的评审指导，先评什么后评什么，各种角色的评审标准是什么。
一般来说，不应该太多角色参加的，例如同行发表具体的意见的时候，QA、EPG等可能会听不懂，当QA、EPG等发表意见的时候，同行可能会觉得比较无聊，浪费他们的时间。太多异种角色参加评审时，不同角色都会有一定的时间损失，评审效率可能不高。但这些要靠你们自己判断怎样做合理，不是绝对的，你们觉得合适的做法就去做就行了。
按照你的描述，你似乎觉得目前的评审做法可以改进一下，如果是这样的话，你就提出来嘛，你们一起来思考怎样改进。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

我是你的fans，你的所有文章我都整理好了，做成PDF，作为工作宝典了。怎么可能没看过裁剪这一篇。：p

你好像没有理解我的问题。我没有想完全僵化的执行CMMI，你上面说的那些我也都知道。

虽然裁剪的意义很丰富，但是它是包括干脆不执行某个PA或者SP这种形式的。如果，我是说如果，一个团队因为各种各样的原因，有很多PA不执行了，而且这样做是最合适的。那么，这个团队的开发流程是不是还非要打着CMMI的幌子？

我们可以将我们正在执行的CMMI做各种更改，使之适应企业的特点。但是我觉得，如果有一天我们的流程真的成熟了，如果再进行一次CMMI评估，那一定不会通过。如果真是这样，我们还要不要违心的说，CMMI帮助了我们，CMMI本来就是敏捷的，甚至CMMI是万能的呢？

依我之见，CMMI并不敏捷。企业在选择是否上CMMI之前，要经过慎重的考虑。即使我们是从事这方面工作的，希望大家认为我们的工作重要，也没有必要将这套理论解释成万能的，“百变CMMI，总有一变适合你”，呵呵。

也许该先回答一个问题，CMMI适合谁？

zhangcb:

请澄清一点，CMMI中的裁剪，不是指可以根据需要选择性地做部分Practice甚至是PA。关于裁剪，请看：
http://cmmionline.net/forums/thread/1756.aspx

前面我提到“我们首先不要将公司的一些做法，硬是要和CMMI标准或者什么同行评审对得上”，意思并不是说CMMI很多地方不适用，而是我们对CMMI的各项要求还不是很理解的时候，很容易“生搬硬套”，一些合理的其实符合CMMI要求的做法，会误判为不符合要求，并且还会“硬生生”的将一些貌似符合CMMI要求但自己又觉得不合理的做法强制要求大家执行。

对于同行评审，CMMI没有规定一定要单独做，这也是我前面提到的。类似你们这个评审，你没有必要非要冠上“同行评审”的帽子，以“同行评审”的标准来看待，好像有一些非同行存在就觉得不合适一样。是否合适的标准，是你们觉得这样做是否合理和有效。
一个评审，有同行参加，也有客户、QA参加，甚至高层参加，这些都很正常，CMMI关于同行评审的要求可以体现在这些评审活动中，关键是你们怎样定义这些评审过程的。如果是多个角色参加的评审，那就需要订好相应的评审指导，先评什么后评什么，各种角色的评审标准是什么。
一般来说，不应该太多角色参加的，例如同行发表具体的意见的时候，QA、EPG等可能会听不懂，当QA、EPG等发表意见的时候，同行可能会觉得比较无聊，浪费他们的时间。太多异种角色参加评审时，不同角色都会有一定的时间损失，评审效率可能不高。但这些要靠你们自己判断怎样做合理，不是绝对的，你们觉得合适的做法就去做就行了。
按照你的描述，你似乎觉得目前的评审做法可以改进一下，如果是这样的话，你就提出来嘛，你们一起来思考怎样改进。

非常荣幸，也很感谢你对我们网站的支持！

CMMI还有一种评估方法，叫连续式嘛，其实每个公司都可以选择一些适合自己公司的PA，甚至是某些Practice。CMMI提供的其实只是标准，不是方法，我们可以敏捷地做CMMI，也可以“重型”地做。SEI也并没有期望用CMMI标准来“框”死各企业，其原意还是希望大家灵活利用CMMI来做改进。各企业情况不一样，肯定不可能一本经书普渡众生了。

在我们公司，我们的过程改进方针就是简单有效，所有走形式的事情，都坚决取缔。在这个过程中，我们也不断思考CMMI这些Pracitice到底是啥意思、什么目的，有一些Practice我们开始也会觉得不合理，我们觉得不合理的地方就不会勉强去做。

举一个例子：关于记录评审中发现的问题。
我们04年做CMM3评估时，我们的做法是评审时现场能解决的问题就不用记录，我们也是直接这样跟我们的评估师说的，而且我们也认为这样做很合理。我们的评估师丛斌博士很赞赏我们简单适用的做法，他并没有因为我们这样的做法就记录为weakness，不过他问了这样一个问题：这些现场能解决的问题是不是都完全没有记录的价值呢？
这触发了我们的再次思考：所谓问题记录，首先应该分析清楚我们都有些什么问题，哪些问题值得去提早规避，这些问题就应该做记录。

其实大家对CMMI和敏捷的理解都可能不一样，但无论如何，公司做改进目标应该还是为了改进的，而不是为了满足什么标准拿什么证，觉得不合理的地方就不要去做。不过确实有很多公司是硬着头皮上CMMI，这样会导致很多问题，得不尝试。

不知道你能不能分享一下工作中遇到的一些具体问题呢？例如你前面提到的同行评审的例子就非常不错。通过具体问题的讨论，才能进行具体的探讨和分析。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

也许我所在的公司情况比较特殊。国企，说话算数的领导有很多都是没有工程经验的，有的虽然有工程经验，对CMMI可以说知之甚少（过三级时还不是这个领导），真正能讨论一下的同事，也没有什么发言权，而且领导之间心也不齐。我这个小小的QA说话没分量的，呵呵，我在工作中会遇到很多问题，但是解决方法一般都是自己想想罢了。

你的思路很开阔，我就没有想到连续式。不过一个企业最开始决定过连续还是阶段的时候，也许跟选择过还是不过CMMI一样迷茫。由于过CMMI要花钱的，因此一旦过了CMMI，没有人希望被刷下来，所以只好硬着头皮继续推。

以所以对CMMI是否是敏捷的发出疑问，是因为我们现在的项目真的很小，简单，而且项目经理水平参差不齐，多数不晓得什么是管理，流程不符合实际情况时，除了抱怨，一点建设性的意见都没有。作为QA，听多了抱怨就会去想问题出在哪里，我怎么想，都觉得如果采用合适的流程，那一定不符合CMMI的标准了。所以我觉得，像我们这样的企业就不该过CMMI。

你说的评审记录问题，我遇到过几乎是一模一样的。我们的流程规定，PPQA在发现不符合问题时，要出具不符合问题单，然后在后来的问题解决过程中，根据问题单的解决情况来填写不符合问题跟踪表。我来到这个公司后，对能够立即解决的问题就不写问题单了，只是直接记入跟踪表。不能马上解决的问题才写问题单。