以道御术——CMMI 2 .0实践指南

版权信息

书名：以道御术——CMMI 2 .0实践指南

ISBN：978-7-115-54505-3

本书由人民邮电出版社发行数字版。版权所有，侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。

如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。

版　权

著　　　　任甲林 周　伟

责任编辑　陈冀康

人民邮电出版社出版发行　　北京市丰台区成寿寺路11号

邮编　100164 　电子邮件　315@ptpress.com.cn

网址　http://www.ptpress.com.cn

读者服务热线：(010)81055410

反盗版热线：(010)81055315

内容提要

本书系统解读了CMMI 2.0模型中的实践，首先介绍了CMMI 2.0相对于CMMI 1.3的变化，阐明了CMMI 2.0的核心思想与理念，然后对CMMI模型中的每个实践域进行了通俗的、详细的、案例化的解读，最后对敏捷方法与CMMI模型进行了系统化的对比分析，并提倡二者的互补融合。

本书对CMMI 2.0模型的解读通俗易懂、言简意赅，并给出了大量实际应用案例，可以帮助读者快速、准确地掌握模型的含义，并与自己的实际场景进行映射和结合，灵活实现模型的要求。

本书适合软件与硬件研发企业的中高层经理、项目经理、过程改进人员、质量管理人员、敏捷教练、咨询顾问以及研发人员等众多参与工程实践的人员阅读。

作者简介

任甲林，麦哲思科技（北京）有限公司、上海艾纵企业管理咨询有限公司创始人，CMMI高成熟度主任评估师、教员，CMMI中国咨询委员会（CAC）成员，通用软件度量国际联盟（COSMIC）实践委员会、国际咨询委员会成员，COSMIC中国分部主席，AgileCxO研究所授权的敏捷性能合弄模型（APH）评估师、教员与教练，认证的Scrum Master，大规模敏捷（SAFe）咨询顾问（SPC）。

从1993年到2020年，他积累了超过25年的软件工程经验，从程序员到项目经理、产品经理，再到研发总监，参与或管理过50多个项目。他于2005年开始从事软件过程改进工作，为200多家客户提供过咨询或培训服务。他在2014年出版了《术以载道—软件过程改进实践指南》一书，2019年翻译了《软件项目估算》一书。

周伟，麦哲思科技（北京）有限公司咨询总监，CMMI主任评估师，AgileCxO研究所授权的敏捷性能合弄模型（APH）评估师、教员与教练，认证的Scrum Master。

他从2001年到2008年，一直从事软件研发工作，经过30多个项目的洗礼，由程序员成长为开发组长、项目经理以及研发主管。他于2009年起，专职从事软件过程改进工作，迄今为止，已为百余家客户提供了咨询或培训服务。

业内专家推荐

本书作者在CMMI领域耕耘多年，具有丰富的理论及实践经验。在本书中，他们对多年的实践经验加以提炼，从与研发质量、项目管理、性能改进等有关的20个实践域对CMMI 2.0的模型深入浅出地加以阐释，这对于今天的互联网及企业的信息化，都具有很好的借鉴作用。比如在第4章中，作者对持续集成的论述与今天云计算PaaS中的CI/CD十分契合。对于在互联网行业及信息科技行业工作的读者来说，本书是值得阅读和学习的。

——国美控股集团首席技术官 黄彦林博士

本书没有空话套话，是作者及其团队多年一线咨询实施经验的心血结晶，还包含了目前国内一线优秀企业的众多实践，其中的每一个案例都值得去认真研读。

——广联达研发管理部总经理 张鹏峰

本书是对软件工程全面和实用的总结概括和实践指南。作者与时俱进，把很多实用的敏捷与DevOps实践也融入CMMI的框架中，形成完整的、强健的软件工程体系。

——敏捷、精益、DevOps专家，汇丰科技基金服务软件负责人

《猎豹行动 硝烟中的敏捷转型之旅》作者 刘华

本书从思想、模型、过程、方案、治理等方面对CMMI 2.0进行了详细阐述，尤其强调了商业目标对过程改进的驱动作用，这对企业高层管理者来说是非常重要的。书中呈现了一个生动立体的模型，不仅有过程的框架，更有丰富的实践和案例。本书还将实践经验和自身思考深度结合，对CMMI与敏捷的本质进行了深入的剖析，这也是我最喜欢的部分。

——易果集团CTO 宋华文

道为术之本，术为道之末。这本书以CMMI 2.0的实践域为主线，用通俗而详尽的语言，将CMMI 2.0模型中的道为何物、道为何理讲解得透彻明了。本书还是一本行动指南，凝聚了作者从业多年积累的宝贵知识和实践经验，对每个实践域的讲解都辅以“实践点睛”，用详实的实践案例引导读者领悟CMMI之道。本书对于从事过程改进、项目管理、质量管理的人员以及中高层领导者而言，是一本难得的佳作！

——大商所飞泰测试技术有限公司副总经理 孙瑞超

作者在CMMI领域深耕近三十年，致力于CMMI模型在中国软件研发行业的推广和实践，从而使企业实现业务目标。作者的坚持与无私分享，都凝聚在本书之中。无论你是管理者还是软件研发任何环节的从业者，这本书都值得阅读。

——中体彩彩票运营管理有限公司综合运营中心总监 李君

作者将“大道至简”重新以通俗而简练的方式阐述得“简而易解”，其中许多内容让我回想起作者在实施改进过程中讨论和分享的诸多实际案例，也进一步加深了作者及其团队在我心中“务实、公开、分享、共进”的印象。我相信本书也可作为组织培养各类软件技术人才的培训教材。改进之路漫漫，唯有不忘初心，方得始终，希望能与同读此书之人共勉！

——富德保险IT中心标准化管理高级经理 唐娜

本书不仅将研发管理的最新国际标准条分缕析，一一道明，告诉我们成熟的软件企业应该企及的高度，而且结合了作者多年一线咨询的实践经验，给出了提升研发管理的具体途径和技术。深入浅出，干货满满，的确是一本很实用的行动指南。

——中国移动子公司卓望信息研发中心副总监 刘咏亭

本书帮助我理清了新模型的框架和逻辑关系。本书延续了作者《术以载道—软件过程改进实践指南》一书的风格，详细案例多于干枯理论，丰富图表多于平白文字。每一个实践域对应一章，非常易于查阅。如果你的公司正准备做研发体系建设，或者体系版本要升级，那么无论你是高层领导，还是基层员工，都建议读一读这本书。你一定会收获颇丰。

——南京联通物联网 于春青

本书是一本对理解CMMI 2.0模型并在企业有效落地非常有帮助的参考书。作者用非常通俗的语言对CMMI 2.0的各个实践域进行了介绍，使读者可以更轻松地理解CMMI 2.0的精要，同时书中的大量案例不仅有助于读者对相关实践的理解，而且对实践的落地有很好的借鉴作用。

——南京林洋电力科技有限公司总经理 陆寒熹

这本书很好地从思想、术语、结构、过程域、评估方法等几个维度整理了CMMI新老两版之间的区别，思路清晰，让人一目了然，让我这种“懒人”也可以快速抓住重点。本书不仅对CMMI 2.0各个实践域进行了简单介绍，并且融入了大量的实例讲解，配合各类图表、检查单、脑图等，尽可能地还原真实的案例现场。无论是CMMI的布道者，还是敏捷的实践者，都可以从本书中有所收获。毕竟过级不是目的，能更好地提升组织效能才是终极目标。

——银联商务股份有限公司 舒艳华

过程改进，重在实践。技术发展以及认识和实践互相促进，推动软件过程改进方法和软件过程改进评估方法持续完善。本书从多角度描述了CMMI 2.0模型带来的新变化，深入浅出分析讲解了每个实践域的精髓，相信软件行业从业者和企业管理者都能够从此书中汲取精华、受益匪浅。

——航天信息副总经理 刘海法

本书是一部难得的极具实际指导价值的工具书。作者充分总结了企业的改进经验和案例，采用通俗易懂的语言对国际通用模型进行了详细解读，涵盖了软件组织落地实施CMMI框架的所有实践域，从中、高层经理到质量管理的各环节技术人员、从刚入行的新手到资深的专业人士，都能从中获得启发和指导。

——中创软件副董事长 程建平

本书秉承了作者一贯坚持的CMMI实效咨询的理念，深入浅出地全面解读了CMMI-DEV 2.0整体框架，使读者能系统地了解CMMI模型的思想脉络和内容模块；同时带领读者从目标和商业价值角度快速领悟各类能力域、实践域的意图和价值，感受CMMI模型的思想精髓和实践经典。

本书最精彩的部分是各章节的CMMI“实践点睛”，作者结合二十年的过程改进咨询和评估经验、丰富的CMMI和敏捷教练经验，聚焦实践的疑难点，提炼了大量的企业最佳实践案例来具体阐述如何开展实践，从而帮助读者更准确地理解实践域的用意，以更好更灵活地在各自的组织中策划、设计和落实CMMI各项实践活动。强烈推荐本书给正准备学习和实施CMMI新模型的组织和人员。

——浙江中控技术股份公司研发中心总经理助理 陈敏华

CMMI模型告诉你“做什么”，而没有告诉你“怎么做”。本书对CMMI的每个实践给出了详细的解读，同时还给出了很多实际样例，架起了“做什么”和“怎么做”之间的桥梁。

——上海市规划和自然资源局信息中心副主任 汪一琛

从88%到97%!

这是我和作者一起实施CMMI一年半的成果：故障变更通过率提升了9个百分点！这意味着重复返工减少了9%，意味着负责维护工作的人力成本节省了9%，意味着项目的开发测试周期缩短了9%。从事软件工作二十余年，我总结了一句话“规规矩矩做软件”，这9%就是规规矩矩做软件最好的验证。

在创办华物信联之际，有幸拜读这本书，我更确信这将是软件团队不可多得的“红宝书”。

——华物信联创始人，原努比亚手机联合创始人 申世安

本书阐述了作者对CMMI 2.0的深刻理解。本书结构清晰简洁，内容精彩丰富，有很高的实用价值。本书针对每一个实践域，从概述、实践列表、实践点睛、小结这4个方面进行生动的讲解，并描述大量真实的案例，帮助读者更好地理解每一个实践域的目的和价值。相信本书会给正在研究和学习CMMI 2.0的读者很多启发，促进更多人参与到切实有效的过程改进工作中，从而更好地针对目标进行改进。

——上海均瑜管理咨询有限公司总经理，TMMi主任评估师，任亮

本书是对作者《术以载道—软件过程改进实践指南》一书的补充完善。前面的那本书“通过一些通俗的故事传递思想”，而本书则是“对CMMI 2.0如何结合企业的实际情况进行映射的解读”。建议读者兼备两书，对照阅读，一定会获益颇丰。

——厦门翔业集团信息部总经理助理 黄丽新

本书针对CMMI模型中的各个PA（实践域）展开讨论，探讨CMMI 2.0框架下的过程改进。其中每个实践域中的案例是我最喜欢的部分。如果你不知道如何做好这个实践，看看案例；如果你对方向心存疑惑或者不解，看看小结中的点睛之笔。你会不自觉感叹作者帮你捅破了一层窗户纸。

——质量管理工程师 李响丽

这是一本值得学习和参考的CMMI 2.0实践点睛之书！本书不仅概要地描述了CMMI 2.0的变化，为CMMI 2.0升级和导入提供了参考指南，而且对CMMI 2.0模型实践进行了点睛注解，并提供了大量的真实的实践案例以方便读者理解。

这本书与企业实践应用相结合，立足于强化CMMI实践解读，让人耳目一新！相信此书能给大家带来更多启迪、思考和借鉴，以更好地帮助企业通过过程改进持续提升业务绩效、实现业务目标！

——CMMI高成熟度主任评估师、讲师，

系统工程/规模化敏捷/DevOps/IPD资深专家，CMMI中国咨询委员会（CAC）成员 胡延军

很高兴看到作者及其团队根据多年的实践经验编写出版了这本书。作者根据多年来在软件过程改进方面的实施、咨询、评估等经验，用案例诠释CMMI 2.0的精髓，并为企业从CMMI 1.3平稳过渡到CMMI 2.0提供了一条有效的途径。

相信本书能帮助软件企业少走弯路，有效地实施软件过程改进, 特别是其中的“实践点睛”部分，非常具有现实指导意义。

——资深 CMMI主任评估师 余军安

序

2018年3月，CMMI研究院发布了CMMI-DEV V2.0模型。在2019年春节之前，已经有客户开始实施CMMI 2.0，他们和我探讨了CMMI 2.0模型中的内容，在沟通、解释的过程中形成了一些文字记录。于是，我萌发了把每条实践都解读一下的想法。我给自己定了目标：在2019年春节期间完成20个实践域的解读工作。但在实际去做的时候，我发现没有那么容易：一是时间没有保证，二是我自己也需要对模型的某些描述进行反复阅读、提炼，并查阅资料。经过2019年春节期间的努力，我的这些解读终于形成了“白话CMMI 2.0”系列博客。在博客中，我侧重于解释模型的含义，并没有给出更多实例；并且限于CMMI 2.0的版权，我仅仅列出了模型的实践，并没有给出对模型的详细描述，所有的通俗解读，也都基于我自己的理解，并非复制模型中的描述。有的实践很简单，所以就没有进行过多的解读；有的实践中有一些关键字眼不是很好理解，我就仅对这些关键字眼着重加以阐述。

2020年春节期间，我请同事周伟、王新华、徐丹霞、刘晓峰帮我对“白话CMMI 2.0”系列博客进行了补充完善，增加了更多咨询实例，以便于读者更直观地看到模型的每条实践和企业的实际做法之间的映射关系。经过这一轮的修订，终于形成了本书的初稿。在此过程中，周伟为本书的最终定稿付出了巨大的努力，使本书的内容更加丰满。

2020年春节后，我又做了多次关于CMMI 2.0的培训，在培训过程中，我有意地将本书的初稿作为辅助教材，并请学员们提出一些修改意见。2020年5月，我又结合自己在CMMI 2.0的评估与教学中的一些新的感悟，对书稿进行了进一步修订。

2014年，我曾经出版了《术以载道—软件过程改进实践指南》一书，这本书对于如何实施过程改进、如何进行软件项目的质量管理提出了一些建议。现在看来，我的这两本书是互相补充的，可以结合在一起阅读。

与《术以载道—软件过程改进实践指南》一书的风格类似，我希望本书言简意赅、简单实用，能帮助读者在自己的场景中灵活运用CMMI 2.0模型。

任甲林

2020年6月22日

前        言

本书定位

与CMMI-DEV V1.3相比，CMMI-DEV V2.0在理念与评估方法等方面都有显著变化，更加强调聚焦于业务目标进行改进，这也契合了麦哲思科技多年来的实效咨询理念。

本书是对CMMI 2.0如何结合企业的实际情况进行映射的详细解读，是落地实施CMMI 2.0的参考指南。本书总结了我们10多年来的实际经验，关注企业在实践中聚焦于业务目标而进行的改进，希望给大家提供在CMMI V2.0 框架下的过程改进建议。

本书的目标读者

本书适合以下人员阅读：软件与硬件研发企业的中高层经理、项目经理、需求人员、过程改进人员、质量管理人员、咨询顾问、敏捷教练、开发人员、测试人员、培训专员、采购专员，等等。

本书结构和建议的阅读顺序

本书的内容可以分为3个部分，共22章。

第1章从思想、术语、结构、过程域以及评估方法5个方面介绍了CMMI 2.0相对于CMMI 1.3的变化，可以让有CMMI基础的读者快速了解这些变化，也可以帮助没有CMMI基础的读者了解CMMI 2.0的结构。

第2～21章介绍了CMMI-DEV V2.0模型中的20个实践域，其中：

• 第2～4章是工程开发类的实践域；

• 第5～7章是质量类的实践域；

• 第8～11章是项目管理类的实践域；

• 第12～14章是支持类的实践域；

• 第15～17章是过程管理类的实践域；

• 第18章是定量管理的实践域；

• 第19章是采购管理的实践域；

• 第20～21章是固化体系执行类的实践域。

第22章从目标定位、思想焦点、核心理念、内容范围以及推广难度5个方面对CMMI与敏捷进行了对比分析，并提倡二者的互补融合。

对不同类型的读者，我们建议的阅读顺序如下表所示。

致谢

感谢麦哲思科技的客户，多年来他们实实在在地进行实效改进，为本书提供了大量的案例。

感谢徐丹霞、姜红梅、郭玲、曾巧、刘晓峰、徐斌、王新华、葛梅、田丽娃、吕英杰、王敬华、赵红星、陈正思、罗振宇等同事，他们给笔者提供了很多在咨询过程中的经验教训和案例，在本书编写过程提出了大量修改意见。本书是我们10多位顾问集体经验的总结。

感谢卓望信息研发中心的副总监刘咏亭先生，在本书校稿过程中提出了150多处修改意见！

本书谨献给那些在中国过程改进领域不断探索、持续改进、真抓实干的人们！

意见反馈

受到作者视野的局限，本书难免会存有疏漏之处，请大家不吝赐教。如果您对本书有任何疑问，可以加入过程改进之道的QQ群（133986886）与作者进行讨论，也可以直接发邮件到renjialin@measures.net.cn。

资源与支持

本书由异步社区出品，社区（https://www.epubit.com/）为您提供相关资源和后续服务。

提交勘误

作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。

当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，点击“提交勘误”，输入勘误信息，点击“提交”按钮即可（见下图）。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。

与我们联系

我们的联系邮箱是contact@epubit.com.cn。

如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。

如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区在线投稿（直接访问www.epubit.com/ contribute即可）。

如果您来自学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。

如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。

关于异步社区和异步图书

“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。

“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社近30年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、AI、测试、前端、网络技术等。

异步社区

微信服务号

第1章　CMMI-DEV V2.0的变化

2018年3月28日，CMMI研究院正式发布了CMMI 2.0，这是CMMI研究院从卡内基梅隆大学剥离出来，归并入国际信息系统审计协会（Information Systems Audit and Control Association，ISACA）之后的第一次版本更新，自2011年11月SEI发布CMMI 1.3之后，已经7年没有更新版本了。在这7年中，Scrum、极限编程、精益看板方法、SAFe、DevOps、LeSS等各种敏捷方法百花齐放，快速流行，极大地丰富了软件组织将CMMI框架落地实施的方法。根据CMMI研究所的统计（见图1-1），2017年有82%的CMMI评估组织使用了敏捷方法。CMMI 1.3的评估次数最近几年也在快速增长，2019年在全球的评估次数达到了3377（见图1-1），其中，我国占比70%。

图1-1　2010年到2019年全球CMMI评估次数的变化趋势

那么从CMMI 1.3更新到CMMI 2.0究竟有哪些变化呢？

1.1　思想的变化

首先是关于思想的变化或强化，之所以可以称为强化，是因为这些思想在之前的版本里也有，但是并没有像在2.0版本里那么明确强调。

1. 进一步强调业务目标对过程改进的驱动作用

在CMMI 1.3中，只在第5级中强调了围绕业务目标进行过程改进，但是在2.0版本中，无论哪个等级都强调了围绕业务目标进行过程改进，这是2.0版本的一个基本思想，也是过程改进的本质。每个实践域有目的、有价值，每个实践有实践描述，也有实践的价值，这都是围绕业务目标进行改进的体现。

2. 要通过性能变化衡量改进效果

是否围绕业务目标进行改进，要体现在组织级的性能变化上，要通过度量数据体现出来，而不能仅仅是主观的判断。在CMMI 2.0 的评估方法中，每次评估都要提交组织的性能报告，要通过定量的数据说明组织级性能的变化。

3. 高层经理对过程改进参与情况的具体化描述

在CMMI 1.3中，高层经理对过程改进、项目管理的参与是通过共性实践来体现的，而CMMI 2.0将高层需要参与的活动提炼为GOV实践域，进一步强调高层参与过程改进的重要性。

4. 员工的行为要固化为工作习惯

确保过程发挥作用，需要体现在具体的工作人员按照过程要求在实践中切实执行，即使在面临工期压力的情况下，也不能放弃。从混乱到规范，从有意识到养成习惯。最高的境界就是体系规范的执行深入到每个人的意识中，本能地按照规范做事情。

在组织内进行过程改进时，过程的固化通常会经历图1-2所示的4个阶段。

图1-2　过程纪律的4个阶段

• 阶段1：没有意识，也没有纪律约束。

• 阶段2：有意识，但是没有纪律约束。

• 阶段3：有意识，有纪律约束。需要刻意去遵守纪律。

• 阶段4：不用刻意去遵守纪律，已经把遵守纪律养成习惯，与日常行为融为一体了。

5. 过程灵活映射到模型

CMMI模型中的实践定义了“做什么”，而“怎么做”是由每个组织自己定义的，并且要紧紧围绕着组织的业务目标来定义。在能满足组织级的业务目标后，再来判断是否可以将组织的“怎么做”映射到CMMI模型的“做什么”。“怎么做”可以有很多不同的做法，相当灵活。软件组织执行的一系列过程并不是生搬硬套模型，正相反，模型恰恰是为组织过程服务的。

6. 随机抽样检查有助于过程固化

按照CMMI 2.0评估方法的要求，所有参与评估的项目应该是随机抽样的，在CMMI 1.3的评估方法中，所有参与评估的项目是由主任评估师与评估的出资人协商确定的，而在CMMI 2.0中，则是由被评估的组织上报所有可能的参评项目，由CMMI研究所的评估系统自动随机抽取参评项目。这种抽样方法的变化，重点在于要求企业真正能够将自己的体系推广到每个项目，而不是仅仅在参评项目中按照规范的方法做事情。

1.2　关键术语的变化

1. 过程域（process area）修改为实践域（practice area），简写仍然是PA

当提到过程的概念时，过程中的活动之间是有先后顺序关系的，但是其实CMMI模型中的实践之间是没有顺序关系的，修改为实践域则避免了这个误解。

2. 新增能力域的概念

在模型中对能力域有一个正式的定义：

A capability area (CA) is a group of related practice areas that can provide improved performance in the skills and activities of an organization or project. A capability area view is a subset of the CMMI 2.0 model that describes a predefined set of practice areas that make up a specific capability area. Capability areas are a type of a view.

通俗地讲，能力域就是针对组织要解决的特定问题的一组相关实践域。能力域的名字就是针对要解决的问题的一种概括描述。CMMI V2.0 的能力域有：确保质量、设计和开发产品、交付与管理服务、选择和管理供应商、规划并管理工作、管理业务弹性、管理员工、支持实施、维持习惯性和持久性、改进性能等。

在CMMI 2.0中，能力域类型、能力域与实践域的对应关系如图1-3所示（见文前彩插）。

图1-3　能力域类型-能力域-实践域对应关系图

3. 过程域类型修改为能力域类型

在CMMI 1.3的连续式表示方法中，将过程域分为了4种类型：工程类、项目管理类、支持类以及过程管理类。而CMMI 2.0中的能力域归为4类，称为能力域类型，即：行动（doing）、管理（managing）、实现（enabling）、提高（improving）。可以将两种分类方法做一个近似对等映射，即：

• 工程类→行动；

• 项目管理类→管理；

• 支持类→实现；

• 过程管理类→提高。

4. 新增视图（view）概念

视图是由最终用户选择的或CMMI研究所预定义的、对模型的最终用户很重要的一组实践域及实践组的集合。

CMMI研究所预定义的视图有：

• CMMI Development V2.0；

• CMMI Service V2.0；

• CMMI Supplier Management V2.0；

• CMMI Planning and Managing Work Capability Area。

最终用户选择的视图如：

• CMMI-DEV V2.0和CMMI-SVC 2.0；

• 其他任意的实践域或能力域或实践组的组合。

图1-4是CMMI-DEV 2.0的2级预定义视图，有10个实践域满足了第1级和第2级的实践（见文前彩插）。

图1-4　CMMI-DEV 2.0的2级预定义视图

CMMI-DEV 2.0的3级预定义视图如图1-5所示（见文前彩插）。

在3级预定义视图中，20个实践域都包含了。SAM和CMMI 1.3一样，是唯一一个可以排除在外的实践域。

预定义视图的评估等级称为成熟度等级，最高为第5级。自定义视图的评估等级称为能力等级，最高等级为第3级。评估自定义视图时必须包含治理（Governance，GOV）与实施基础条件（Implementation Infrastructure，II）这2个实践域。

图1-5　CMMI-DEV 2.0的3级预定义视图

1.3　结构与描述方式的变化

1. 采用平实的语言描述

2.0版本的模型尽量采用平实的语言进行描述，通俗易懂，还原最初CMM模型的描述风格，更加易于理解和学习，对模型的英文原文进行词频统计，发现仅有3500多个单词。

2. 整合了People CMM 等多个模型

除了CMMI 1.3中的开发、服务、采购3个系列仍然包含在CMMI模型中，2.0版本的模型中还集成了People CMM模型。虽然People CMM模型在全球的评估次数不多，但是作为一个优秀的人力资源管理模型，仍然值得推广，People CMM模型在企业的能力提升中同样扮演着重要的角色，所以将People CMM模型集成进来是一个明智的决策！另外，2.0版本的模型中包含了关于安全与保密的实践域。

3. 不再对实践域划分等级，而是对实践划分等级

这是一个很显著的变化，这个变化更符合实际、更合理。比如对于CAR实践域而言，第3级的企业也应该执行原因分析，只是与第4、5级的企业相比，进行原因分析的方法手段有差别而已。在一个实践域中，相同等级的实践集合称为一个实践组。

在20个实践域中，只有CM仅包含第1、2级的实践，而GOV、PLAN、PCM和SAM这4个实践域包含了第1、2、3、4级的实践，CAR与MPM包含了5个等级的实践，其他实践域都包含了第1、2、3级的实践。

第2级的实践累计有79条，第3级的实践累计有73条，第4级的实践累计有11条，第5级的实践累计有4条。CMMI-DEV V2.0的实践个数统计参见表1-1。

表1-1　CMMI-DEV V2.0 实践个数统计表

4. 过程域的目的修改为实践域的意图与价值

过程域的目的描述了该实践域期望的输出结果。实践域的价值描述了通过实施该实践域的实践所实现的业务价值，即收益。这个变化更强调了模型的实施要聚焦于为组织带来商业利益，提升企业的业务能力。

5. 为每个实践域、每个能力域设计了图标

为了便于模型的理解、记忆与推广，每个实践域、每个能力域都有自己的图标，这些图标简单易记，很形象，有助于理解模型的含义。

6. 不再区分特定实践与共性实践

所有的共性实践被整合到2个实践域中，即GOV与II。GOV描述了高级管理者在过程改进、过程实施中需要做的活动。II描述了过程改进、过程实施所需要的基础设施。这2个实践域都是为了确保过程规范能够在组织中固化为习惯。

7. 区分了内核信息与特定场景内容

每个实践域都分解为一个共通描述章节（内核信息）与可适用的特定场景描述章节，目前提供了针对Scrum的特定场景描述，以后还会灵活增加其他特定场景内容。

8. 模型展示工具的变化

CMMI研究院提供了模型的在线展示工具，可以在线查阅模型，也可以下载pdf 格式的模型供个人使用。主任评估师与教员可以全年使用该工具，对于接受Intro课程培训的学员，则提供了7天的时间窗口。下载的模型中印有学员的账号信息，不经过CMMI研究所授权的非法传播都是被禁止的。

1.4　过程域的变化

CMMI-DEV V1.3中有22个过程域，而目前发布的CMMI-DEV V2.0中有20个实践域。其中有些实践域保留了原来的名字，如CAR、CM、DAR、OT、PI和SAM等；有些实践域对名字做了微调，如MC、PLAN、PAD、RSK和PQA等；有些实践域是新增或者剥离出来的，如EST、PR、GOV和II等；有些实践域则由原来的多个过程域合并而来，如MPM、RDM和VV。2.0版本与1.3版本的映射参见表1-2。

表1-2　CMMI-DEV V2.0的实践域与CMMI-DEV V1.3的过程域的映射

1.5　评估方法的变化

1. 抽样规则发生变化

这是评估方法中最显著的变化。通过提前60天由系统自动随机抽样参评的项目，确保了抽样的代表性，更能客观地考察组织是否达到了CMMI的某个等级，同时也降低了企业为了获得证书而临时编制证据的可能性。

例如某公司划分了两类管理流程不同的项目，合计有7个项目适合参与评估。有一个项目刚刚启动，有些实践还未做，对应的实践域标注为了NY（not yet）。将项目的基本信息输入CMMI的随机抽样系统中之后，7个项目全部都要提供证据，但是不同的项目覆盖的实践域不同，详细抽样结果参见表1-3（见文前彩插）。主任评估师可以和评估的出资人协商增加某些项目的覆盖或者在同一类项目中进行实践域覆盖的替换。

表1-3　随机抽样结果案例

表1-3的图例说明参见表1-4（见文前彩插）。

表1-4　随机抽样图例说明

2. 新增了维持性评估

在1.3版本中，区分了Class A、Class B、Class C 3种不同严格程度的评估，而在2.0版本中，则区分为了基准评估（benchmark appraisal）、维持性评估（sustainment appraisal）、评价评估（evaluation appraisal）以及行动计划复评（action plan reappraisal）。其中基准评估类似原来的Class A评估，有效期仍然是3年。评价评估可以映射为原来的Class B、Class C评估，而行动计划复评也是原来1.3版本的评估方法所有的。变化比较大的是维持性评估，维持性评估的要点如下。

（1）维持性评估最少需要2名评估员，包含评估师。

（2）有效期为2年。

（3）1/3的实践域要深入分析，其他可以概要分析。如果是高成熟度的评估，则包含高成熟度实践的实践域是一定要深入分析的。

（4）评估时对上一次评估发现的弱项（实践）要进行考察。比如某个实践有弱项，则下次维持性评估时，该实践要深入分析。这是在1/3深入分析的实践域之外附加的。

（5）最多可以连续做3次维持性评估。即第1次做基准评估，第2、3、4次可以做维持性评估。第5次就必须做基准评估了。

（6）最新的维持性评估结论将替代上次评估的结论。如果上一次评估的到期日是2022年5月1日，成熟度等级是第3级，而该组织在2022年的1月1日完成了一次维持性评估，评级为成熟度等级第2级，则该组织的等级就是第2级，原来的第3级结论作废。

（7）最新的维持性评估将中止上次评估的有效期。如果上一次评估的到期日是2022年5月1日，该组织在2022年的1月1日完成了一次维持性评估，则该组织的评估有效期就是2024年的1月1日。

（8）维持性评估的等级不能比上一次评估的等级更高。即如果上一次评估是第3级，则维持性评估不能是第4、5级。如果要评第4、5级，必须是基准评估。

（9）满足了以下条件才可以做维持性评估。

　（i）抽样因子类型和上一次评估相同或是其子集。

　（ii）抽样因子取值和上一次评估相同或是其子集。

　（iii）评估的单位不变或是上一次评估的子集。

　（iv）至少有一个项目是上一次评估延续过来的。

　（v）模型范围和上一次评估一样或更小。

如果成熟度等级原来是第3级，维持性评估可以是第2级或第3级；如果原来评估了SAM，维持性评估也要评估SAM；如果原来对10个实践域评价能力等级，维持性评估可以减少几个实践域。

4种类型的评估对比可以参见表1-5。

表1-5　4种类型的评估对比

3. 一次评估可以包含多个视图

每个组织在评估时，可以选择CMMI研究所预定义的视图，也可以自定义视图。自定义视图时，可以自由组合预定义的视图，也可以自己选择实践域组合视图。评估选择的视图是针对组织的业务目标而来的，也是针对组织的业务能力而来的。这种自由组合的视图，更有针对性，同时也降低了组织的评估成本。

4. 每次评估要提交性能报告

性能报告是一组度量数据，是由被评估组织自定义的、展示组织的过程能力的数据，这组数据并非由CMMI研究所指定，不会被公开，不会被用于横向比较各个组织的差别，也不会被用来评价被评估组织的能力高低，仅仅是提供给出资人的数据。帮助出资人客观了解过程改进带来的组织性能的变化，并提醒出资人要通过定量数据关注组织的能力变化。

性能报告中主要包含了如下信息：

• 组织的业务目标；

• 组织的度量与性能目标或质量与过程性能目标；

• 目标对应的度量定义、具体数值；

• 目标的适用范围；

• 目标之间的关联关系；

• 过程性能基线与模型；

• 影响目标达成的原因、关键成功因子；

• 达成目标的措施有哪些；

• 这些措施的实际效果对比分析；

• 与CMMI模型的对应关系；

• 与本次评估发现的对应关系。

性能报告在评估结论报告时必须给出资人进行汇报，它是对目标驱动的过程改进效果的结构化梳理，提醒管理者、过程改进人员、评估组成员以及评估师要紧紧围绕业务目标实施改进行动。

5. 评估组成员要通过认证考试

在1.3版本的评估方法中，只要求评估组成员（Appraisal Team Member，ATM）接受了Introduction to CMMI的培训和评估方法的培训，在2.0版本中要求ATM成员在完成两天的模型基础课程后要通过Associate认证考试，督促ATM真正学习并掌握CMMI模型，理解CMMI模型的要求，能够和被评估组织的实际做法建立一个有效的映射，从而保证评估的价值。而后ATM还要再参加一天关于构建卓越能力的培训课程。高成熟度的ATM还必须参加一天的高成熟概念的培训。成为CMMI 2.0 ATM的路线图如图1-6所示。

图1-6　成为CMMI 2.0 ATM的路线图

第2章　需求开发和管理（RDM）

2.1　概述

需求开发和管理（Requirement Development and Management，RDM）合并了CMMI 1.3的RD与REQM两个过程域。它覆盖了需求获取、需求分析、需求描述、需求验证和确认、需求管理这5个需求工程的活动。

Standish Group对23000个项目的研究结果表明，近45%的项目因为需求的问题而最终失败，而导致项目失败最重要的8大原因中，有5个原因与需求相关：

• 不完整的需求（13.1%）；

• 缺乏用户的介入（12.4%）；

• 不实际的客户期望（9.9%）；

• 需求和规范的变更（8.7%）；

• 提供了不再需要的功能（7.5%）。

因此，需求过程能力的高低直接关乎项目的成败。

2.2　实践列表

本实践域的实践列表参见表2-1。

表2-1　需求开发和管理（RDM）实践列表

2.3　实践点睛

RDM 1.1　记录需求

需求必须文档化，需求不能是传说。

文字描述、需求列表、界面原型等都是需求文档化的常见形式。

可以用一份文档描述需求，也可以区分客户需求文档与需求规格说明书等多份文档来描述需求。

在传统的开发方法中可以采用IPO（输入-处理-输出）、用例等方式描述需求，在敏捷的方法可以用用户故事描述需求。

RDM 2.1　引导干系人的需要、期望、约束、接口或连接

在CMMI 2.0模型中，除了GOV实践域，其他实践域的实践描述都没有主语，在组织中实现模型时，可以根据自己组织的实际情况分配责任人。在需求获取时，一般是产品经理、产品负责人（product owner，PO）、需求工程师、系统工程师或项目经理等角色负责引导、获取需求。这些角色应该有领域经验和需求工程的经验，掌握了需求获取的技术，否则无法引导客户提出真正的需求。

引导意味着需求分析人员要启发需求提供者提出自己的真实需求，要有引导的手段，如：

• 头脑风暴；

• 访谈会议；

• 原型法；

• 现场观摩；

• 问卷调查；

• 需求工作坊；

• 影响地图；

• 用户故事地图；

……

可以从以下多个维度识别干系人。

• 客户、最终用户、间接用户。客户是花钱购买系统的人，如银行的科技部、高层经理等。最终用户是真正使用系统的人，如银行的柜员等业务人员。间接用户既不出资也不使用产品，但是他会对系统能否上市有影响力，如银行监管机构等。

• 高层、中层、底层的人。高层提出目标层的需求，即系统要解决的问题、当前的痛点、系统的业务目标等。中层提出业务层的需求，即系统要覆盖的业务有哪些。底层提出操作层的需求，即具体的功能需求、易用性需求等。

• 内部客户与外部客户。内部客户是开发方的人员，如百度提供的搜索功能要能够竞价排名，这就是内部人员为了商业利益提出的需求。外部客户是开发方以外的人员，如作为搜索用户，我们希望搜索网站能够检索到最符合我们需求的信息。内外部客户的需求是不同的。

• 系统生命周期各个阶段的干系人。系统的策划、开发、测试、部署、推广、运维等各个阶段的干系人的需求也是不同的。

【案例】识别需求提供者的策略

某客户将自己公司的产品划分为两大类：成熟产品与新产品，针对不同类型的产品需求获取时要访谈哪些角色，定义了表2-2所示的策略。

表2-2　识别需求提供者的策略

干系人识别不全，会导致需求的遗漏，比如某管理信息系统上线后，客户希望提报的申请在审批不通过时直接退回，研发最初选择的技术框架不支持该流程，增加此功能花费了一个月。对此问题追根溯源后，发现主要原因是在需求调研阶段只识别了提报申请的部门参与调研，遗漏了该业务流程涉及的其他干系人。

在需求获取时，要捕获如下4类需求。

• 需要：必需的、不可裁减的需求。

• 期望：最好能实现、越多越好、可以裁减的需求。

• 约束：实现需求与期望的前提条件，可能是技术的、管理的、商务的、环境的限制。

• 接口或连接：系统与其他设备、系统之间的衔接关系，任何一个系统都不是孤立存在的！

以某车载导航系统为例：

• 目的地定位与导航是需要的；

• 使用某名人的语音进行播报是期望的；

• 该系统的实现技术、上线日期以及嵌入式环境下的可用资源限制是多种约束；

• 该系统还会存在与其他设备、系统的软硬件接口。

我总结了需求获取的4个原则供大家参考，以提高需求获取的质量，如图2-1所示。

图2-1　需求获取的4个原则

需求获取时要有主线。这样才能让需求提供者高效地、系统地提出自己的需求。

Gojko Adzic的《影响地图：让软件产生真正的影响力》一书提出了以“Why-Who-How-What”为主线来获取需求：

• Why 即系统的业务目标，也就是系统要解决的问题；

• Who即哪些人可以影响目标的达成；

• How 即这些人的哪些行为影响了目标的达成；

• What 即系统提供了哪些功能可以帮助这些人的行为来达成系统目标。

这是一种聚焦于系统目标的需求识别的方法，可以减少无用的功能，最大限度地提高系统的投入产出比。

以业务流程为主线，了解客户的业务是如何处理的，然后从中识别出需要系统完成的功能，是客户比较容易接受的方法，因为客户最了解自己的业务，能够从业务的开始到业务结束，以时间为主线将业务梳理清楚。用户故事地图与此思考方式类似。

用户故事地图是所有用户故事的全景图，可以让我们从总体上了解系统的完整需求。它是一个二维图，以时间线为横轴，以优先级为纵轴，基于横轴的用户业务活动识别用户故事，再对用户故事划分优先级，定义出每次发布的内容，图2-2给出了一个咨询项目管理系统的用户故事地图案例。

为了把需求沟通得更清晰透彻，在传统的需求工程方法中采用“输入-处理-输出”或用例的方式来描述沟通需求，即描述清楚需求的输入、输出是什么，如何从输入转换为输出，人机交互的动作序列是什么。在敏捷的方法中，每个用户故事都要沟通清楚其验收准则，通常采用“Given-When-Then”（给出-当-那么）的方式来描述，如下所示。

【案例】咨询项目管理系统的用户故事地图案例

图2-2　咨询项目管理系统的用户故事地图案例

用户故事：作为一个储户，我想从ATM中提取现金，这样我就不用在银行排队等待了。

验收准则：

　　场景1：

　　给出：账户是信用卡，并且

　　　　　卡是有效的，并且

　　　　　ATM有现金

　　当：客户请求提取现金时

　　那么：

　　　　　确保账户余额被扣除，并且

　　　　　现金被吐出，并且

　　　　　确保信用卡能够退还

一图胜千言。文字描述是抽象的，图形表格是具体的。原型法是需求获取时的有效工具，和实例化需求类似，可以结合在一起帮助理解需求、引导需求。

获取需求时，除了要考虑客户如何使用系统以外，还要考虑实施人员如何部署系统，运维人员如何日常维护管理系统，将来系统如何升级，系统报废时如何卸载等方面的需求，因此要考虑产品的全生命周期阶段涉及的各类角色的需求。

客户在提需求时，往往会遗漏非功能性的需求，而仅仅关注了功能性的需求，或者即使关注了非功能性的需求，也不知道如何表达这类需求，此时，需求调研人员可以准备好针对非功能性需求的问题单、案例以及缺省数值，以启发客户提出非功能性的需求。

RDM 2.2　将干系人的需要、期望、约束、接口或连接转换为排列了优先级的客户需求

客户需求中要包含需要、期望、约束、接口或连接，并且需求要划分优先级。

在一款商品化软件中，用户真正常用的功能往往不足20%，所以需求一定要划分优先级。没有划分优先级的需求后续无法根据优先级排列开发顺序，无法尽早给客户交付有价值的需求，无法进行多快好省的平衡。所以，请记住一定要划分需求的优先级！需求的优先级至少与需求本身同等重要！

划分需求优先级有以下多种方法。

• 卡诺模型：从需求实现程度的高低及客户满意程度的高低两个维度将需求划分为必备的需求（痛处）、期望的需求（痒处）、兴奋型需求（暗处）。

• 百分制法：参与划分需求优先级的每个人都有100点，可以根据自己对需求重要性的理解将100点分配到每个需求上，重要的需求点数高，次要的需求点数低。然后累计每个需求得到的点数，从高到低排序即可得到需求的优先级。

• ROI（投入产出比）方法：让客户或客户代表对每个需求的业务价值给出相对分值，让开发团队针对每个需求给出开发成本的相对分值，二者相除得到相对的投入产出比，然后排序得到优先级。

【案例】基于ROI的需求优先级分析（见表2-3）

表2-3　基于ROI的需求优先级分析

RDM 2.3　与需求提供者就需求的含义达成一致的理解

此实践强调需求理解的外部一致性，即开发方和需求提供方（客户方）要对需求的理解达成一致。需求误解是我们在系统开发中要努力克服的现象，如图2-3所示。

图2-3　达成对需求的一致理解

在图2-1中提到的需求实例化、需求原型化可以很好地帮助客户方、开发方对需求达成一致理解。在实践中有以下多种常见的需求沟通手段。

• 需求交底：产品经理给开发人员讲解需求。

• 需求反讲：开发人员给产品经理讲解对需求的理解，业务人员矫正误解。

• 需求评审：产品经理、开发人员、测试人员、客户（有可能的话）都参与需求评审。

• 原型评审：开发人员给产品经理、客户、用户讲解原型，干系人提出修改意见。

• 需求工作坊：各类干系人一起召开头脑风暴会议，沟通需求；

……

RDM 2.4　从项目的参与者处获得他们对需求可实现的承诺

本实践讲需求理解的内部一致性，即实现需求的人要对需求理解一致，认为在技术上需求是可以实现的，从工期上也是可以保证的。这是需求实现者对需求提供方的承诺，不是需求方承诺需求不变。

需求沟通的方法参见RDM 2.3的描述。

【案例】某企业的需求交底规则（见表2-4）

表2-4　某企业的需求交底规则

RDM 2.5　建立、记录、维护需求与活动或工作产品之间的双向可跟踪性

本实践的目的是要确保：

• 所有的需求都被分配到人了；

• 所有的需求都被设计了；

• 所有的需求都被实现了；

• 所有的需求都被测试了。

也就是说，不要有被遗漏的需求！

所谓双向可跟踪性是指能从需求跟踪到对应的设计，也能从设计跟踪到对应的需求，其他跟踪关系以此类推。

接口需求、非功能性需求是在实践中最容易被忽略跟踪的需求。

系统越大、参与人员越多、研发周期越长，需求双向可跟踪性的粒度越细，复杂度也越高，在汽车电子、铁道交通、核电等行业标准中，往往要求使用专业的工具（例如DOORS）进行管理；当然，也可以通过自行设计的Excel表格或编号规则进行管理。

在敏捷的场景中，这种双向可跟踪性体现在了产品待办事项列表（product backlog）、冲刺待办事项列表（sprint backlog）、用户故事、看板、影响地图与用户故事地图中。

RDM 2.6　确保计划与活动或工作产品与需求保持一致

通过各种评审、测试、验证和确认活动确保设计、代码、测试用例、计划等与需求保持一致。当需求发生了变更时，也要维持相关配套文档与活动与需求的一致性。

RDM 2.5中双向可跟踪性的建立与维护也是支持本实践实现的一种手段。

RDM 3.1　开发解决方案及其构件的需求并保持更新

解决方案和构件需求就是产品和产品构件需求，就是需求规格，就是对需求的详细定义。

需求文档的多少、格式是不限制的，可以根据组织的实际情况灵活定义。

【案例】某企业需求描述的4W1H分析（见表2-5）

表2-5　某企业需求描述的4W1H分析

需求变更时要执行需求变更影响的分析、评审、认可。需求变更的影响主要有以下3个方面。

• 对管理的影响：对规模、工期、工作量、成本的影响，存在风险。

• 对技术的影响：对设计、编码、测试以及对其他需求的影响。

• 对人员的影响：该变更影响到了谁的工作，需要谁参与进来，需要通知谁。

RDM 3.2　定义操作概念和场景

操作概念，就是对用户在各种场景下如何使用产品的全局描述；操作场景，就是各种正常或异常的业务操作路径，要包含产品全生命周期的场景。

如果使用用例技术分析需求，则系统用例图可以看成操作概念；用例本身描述各种交互响应的正常流和异常流可以看成操作场景。

在敏捷方法中，在我们编写每个用户故事的验收标准时，我们需要清晰地描述出来正常与异常的各种场景，这种做法可以映射到本实践。

【案例】某航空公司货物装舱系统的用例图（见图2-4）

图2-4　某航空公司货物装舱系统的用例图

RDM 3.3　分配待实现的需求

所谓的分配需求就是把整体的系统需求分配到每个产品构件上。比如：一个杯子分为杯盖与杯桶，关于容量的需求主要分配给杯桶，关于温度的需求要分配给杯盖与杯桶，杯盖要承受110℃的温度，杯桶要承受105℃的温度，这就是把整体的系统需求分配到每个产品构件上。

【案例】借鉴QFD（Quality Function Deployment）方法分配需求（见表2-6）

表2-6　借鉴QFD方法分配需求

注：▲ 强，△ 中，⊕ 弱

RDM 3.4　识别、定义接口或连接需求并保持更新

接口需求分为外部接口需求与内部接口需求。外部接口需求在需求获取时是必须获取的，内部接口需求是在分配了待实现的需求后产生的，就如同上边那个例子，把杯子划分为杯盖和杯桶之后，就产生了二者之间的接口需求，这是产品内部不同构件之间的接口，是内部接口。

接口需求可以在需求说明书中描述，也可以作为单独的一份文档定义并持续维护；接口需求定义的是接口的用途（例如需要支持微信与支付宝支付，则涉及支付的外部接口）、接口的设计定义的是接口的调用与实现细节。

在描述外部接口需求时，采用系统环境图（接口关系图）可以增加需求的可读性，如图2-5所示。

RDM 3.5　确保需求是必要的和充分的

所谓需求是必要的，就是需求不是多余的，不是可有可无的，不做无用功。所谓需求是充分的，就是需求是不可缺少的。

所以这条实践就是要求需求不多不少，刚刚好！

调研需求时，更多的是做加法，尽可能多地、充分地挖掘和收集需求；分析需求时，则应多做减法，弄清楚可以不做什么，少做什么。这两个活动应该交叠进行。

图2-5　使用系统环境图描述系统间接口

在评审需求、确认需求时可以检查需求是否是必要的、充分的。

在互联网行业当中，最小可行性产品（Minimum Viable Product，MVP）是非常流行的一种做法，即快速开发最少而必需的功能并发布出去，到市场上进行验证，获得反馈，再进行迭代优化，这种做法可以视为本实践的一种实现。

RDM 3.6　平衡干系人的需求和约束

平衡需求和约束，就是做多快好省的平衡，把需求和工期、质量、投入进行平衡。平衡的前提是要对需求划分优先级，参见RDM 2.2。

可以通过以下手段进行需求的平衡。

• 采用相对优先级矩阵进行需求的比较与平衡。

• 客户提出的需求，特别是号称紧急的需求，需要阐述如果不实现或者延迟实现，到底会产生什么样的影响。

• 对于已上线的需求，可以跟踪实际使用的状况（例如频率、人次、时长等），作为后继平衡的依据。

RDM 3.7　确认需求以确保最终的解决方案可以在目标环境中按照预期运行

要确保需求满足了用户的真正需求，此条实践确认的是需求而不是最终交付的产品，所以对需求的确认是通过评审、模拟或原型演示来实现的。也可以采集类似系统在实际使用中常见的问题和关注点（例如提升用户体验的若干条细节），作为前期需求分析和评审的补充。

需求要早确认、多方确认、频繁确认、全生命周期确认，确保做了正确的事情！

2.4　小结

需求获取、需求分析、需求描述、需求验证和确认、需求管理这5个需求工程的活动是提升需求过程能力的关键，应该借鉴模型的实践并结合自身的场景加以规范和改进，图2-6是Karl E. Wiegers在《软件需求（第3版）》这本书中总结的需求开发和管理的活动场景。

图2-6　需求开发和管理的活动场景