详情
本书是作者从事二十多年CMMI咨询、软件质量管理工作的经验总结。本书从实践者的角度出发，介绍了实施CMMI的方方面面，内容涵盖了软件过程改进的方法、实践问题的答疑、过程改进中使用的技术、软件过程改进的实际样例等等。本书内容全面而实用，对于如何实施过程改进、如何进行软件项目的质量管理提供了很好的建议。
北京
当今世界已经进入以信息技术为核心的知识经济时代，人类能够综合利用物质、能量和信息 3种资源，信息资源成为与材料和能源同等重要的战略资源。以云计算、物联网、大数据、智慧工程为特征的新时代的信息技术不断涌现，但我们仍需要关注美国卡内基•梅隆大学软件工程研究所（CMU/SEI）倡导的已经走过了近30 年旅程的以CMMI 为核心的过程改进技术。根据CMU/SEI的研究，正确实施以CMMI 为核心的过程改进，对软件项目来说，可以降低成本34%，缩短进度50%，提高生产率61%，减少缺陷48%，改善客户满意度14%，总的投资回报为4:1。以CMMI 为核心的过程改进技术成为各行各业信息化的助推器。
本书作者采用理论与实践相结合的方法，从CMMI 实施、敏捷方法、过程体系、项目策划与监控、需求工程、设计与实现、测试与同行评审、质量保证、配置管理、量化项目管理、CMMI 的评估、人员管理等方面，描述了CMMI 过程改进技术的理论要点与实施经验。
工程过程组（EPG ）是企业实施过程改进的策划与执行机制。作者指出EPG 应遵循主动改进、循序渐进、先敏捷再规范、先下游再上游、测试先行、善于总结、各个击破、教育与培训并重、充分利用工具、内外结合等成功策略；同时指出要防止对模型研究不够、不善于与项目组沟通、不善于理解企业高层管理人员的意图、作业不规范、违背循序渐进、忽略裁剪指南、缺乏足够的工程经验等弊病。
这个世界是一个充满项目的世界。任何企业都是通过实施项目达到其目的，过程改进也是一个项目。作者具体刻画了做好项目管理应该遵循平衡、高效、分解、实时控制、分类管理、简单有效以及规模控制等六个原则，并根据项目都是需求牵引、技术推动的原理，详细描述了需求工程技术。
确定过程改进的切入点是任何企业进行过程改进的一个难点。作者指出通过过程评估、过程裁剪、不符合问题分析、缺陷分析、经验教训总结、度量数据分析、过程改进建议以及高层经理的改进需求分析等方面，可以精准地找到过程改进的切入点。
作者指出过程改进没有灵丹妙药，需要技术、人员、过程三要素的协同改善；过程改进不能一蹴而就，要坚持不懈、持续改进；过程改进要循序前进、理论与实践结合、与企业的创新文化融合；过程改进要勇于实践，允许犯错误，在实践中完善；过程改进要有专人负责，还要求全员参与。作者还特别中肯地指出：我国的CMMI 评估，存在“重视证书、忽视实效”的倾向，呼吁企业管理人员、政府主管部门、媒体舆论以及评估咨询人员，共同努力，创造过程改进的良性生态环境，促进我国的软件过程改进事业持续、健康地发展！
总之，本书以 CMMI 为主线，总结了作者 12 年来的软件开发与管理经验以及 8 年多的过程改进咨询经验，记录了作者所做、所思、所见与所闻，并融合了很多敏捷实践，语言生动，描述具体，是作者软件管理思想的生动记录。我认为本书既是一本很好的教科书，又是一本很好的指南，非常适合过程改进人员、项目经理、中高层经理和开发人员阅读和参考。我深信，本书在我国各行各业信息化的进程中，一定能起到推波助澜的作用。
北航软件工程研究所 周伯生
bszhou@cyberspi.com.cn
2013年12月18日
项目管理、软件开发、CMMI 介绍的书籍比比皆是，软件过程改进之道更是曲折前行的，这是一本软件研发管理者需要的，实操性更强的引领软件研发管理和过程改进之道的书籍。
黄海悦 东方电子股份有限公司项目部部长
一直关注和拜读任老师无私分享的实践经验，在公司研发管理体系建立和推进CMMI 评估过程中碰到问题时，总感觉能量强大的任老师就在你身边，使各种问题迎刃而解。如果你置身于过程改进的长河中，那么，本书一定能为你指点迷津、拨云见日。
李君 中体彩技术管理部经理
本书没有生硬地去照搬和讲解标准，而是以一个实践者的感悟，分享了作者对过程改进的思考，为软件企业过程改进提供了可借鉴的流程和方法，也为行业内过程改进的经验传播架起了桥梁。相信软件企业的管理者和团队在持续改进的过程中会从这本书获得收益。
田丽娃 中创软件（CVICSE）质量总监
在这样的一个全新时代，消费类电子面临着智能化的趋势，面临着互联网的强烈冲击，产品更新换代的速度越来越快，产品的功能越来越复杂，同时又要求有更好的用户体验、质量及更低的成本，公司业务中软件的价值贡献越来越大。本书从实用的角度阐述了软件过程的方方面面，有理论，更有实践，相信每个团队的各个岗位上的人，都能找到自己适用的部分，并受益匪浅。
舒卫平 TCL 集团工业研究院项目推进与管理部部长
读这本书时让我想起十年前接触过程改进时初读CMMI 模型的感受，没有浮夸的辞藻或动人的故事，但每句话细细咀嚼都有味道，平实的文字中蕴含着过程改进的丰富经验和深刻哲理，所谓大道至简，大象无形。在自己的过程改进经历中，也曾有过无数的迷惑和困难，而这些问题基本都能在书中的案例中得到启发和解答。希望这本书成为每一个投身于过程改进工作中的人案头必备的工具、指南。
李旸 广联达软件股份有限公司PMO 项目管理主管
本书作者一直秉承实效重于证书、实施方法重于标准模型的理念并将该理念贯彻到其过程改进的研究、实践和咨询中，本书是作者20余年软件工程实战的深刻感悟和经验升华，为软件过程改进的同行提供了一套非常实用的实践指南。本书从改进的本源出发告诉你什么才是真正的有价值的改进及如何开展神形兼备的过程改进，是软件研发过程改进领域难得一见的佳作。
赖晓健 浙江中控技术有限公司研发中心主任
任老师是软件过程改进行业公认的劳模，工作认真扎实，书中所记载的是他多年来从事软件过程改进咨询所积累的资料和笔记，充分利用数据、图表、案例阐述软件过程中存在的问题及最佳实践，这是目前业内最为落地实践的软件过程改进著作之一，特推荐给软件业同行阅读。
张友生博士 希赛顾问团首席顾问
不论是对质量管理人员，还是对软件研发人员，本书都堪称一部难得的宝典。作者以其丰富的行业经验对软件过程改进做出深入浅出的分析，并给出基于实践的指导意见，通过学习本书，你会领略各种最佳解决方案。
刘军 大连飞创信息技术有限公司总经理
任先生的专著即将付梓，我有幸先睹为快。CMMI 评估体系在国内已推广多年，帮助数以万计的 IT 企业日益成长成熟，以任先生为代表的咨询服务专家功不可没。尽管类似的书籍在国内外有许多，但该书以全新的视觉、丰富的实践和严谨的思辨逻辑为我们展示了一幅精美的画卷，有理论、有方法、有案例、有感悟，一切都是鲜活的、汉化的、深入浅出的。跳出IT领域来看，精益的理念和方法在管理上是通用的，因此该书无论对业界人士还是对企业管理者都有裨益。
孙茂杰 江苏金恒信息科技有限公司总经理
与任老师初次相识是2006年4月。当时，长虹正着力扩大软件团队，提升软件研发能力。经过几轮比较，最终选择了任老师作为长虹项目的主要咨询师，全程指导了体系实施和评估。后来，我们从CMMI -L2一直做到了L5，全部由任老师实施咨询，2012年11月底，长虹顺利通过了CMMI -L5的现场评估。在这个漫长的过程中，我们和任老师一起研究模型、梳理实践、把握精髓，实现了软件研发能力的实质提升。对他理论与实践结合、注重实效、细节致胜的咨询风格留下了深刻印象。这本书是任老师多年过程改进实践体会的系统总结，内容详实，案例丰富，实用性强，相信会对国内软件企业的健康、持续发展提供良好的方法论指导。
张恩阳 四川长虹电器股份有限公司技术中心总经理
这本书不同于其他的项目管理书籍，不单纯的讲“道”，而是以道御术、以术载道， 并且难得的人将“人”和“文化”这两个管理中最关键的因素融入其中，无论你是刚入行还是资深的项目管理人员，这本书都能给你新的启迪。
林亦雯 中国海运集团中海信息系统有限公司副总经理
我曾经见证了任先生为实施CMMI 的组织提供服务，并且，我也对他指导过的实施CMMI 的组织做过评估。任先生非常博学，并且他有着多年实践性很强的、附加价值丰富的过程改进经验。这本书为读者提供了学习任先生的价值驱动方法的手段，以便读者们能够采用相似的方法来改进他们的软件开发过程。
Shane Atkinson，ATKOTT Inc. CMMI 高成熟度主任评估师
这本书恰好是过程改进社区所需的。Dylan勾画了一副蓝图以帮助人们理解CMMI 如何适应他们的改进需求，并且提供了大量的详细案例以帮助组织改进其性能。敏捷和传统方法的完美无缝融合使软件工程更加高效，提高了生产率。无论你是一名工程师、EPG 人员，还是管理人员，这本书都会帮你更好的策划、准备、实施提升您公司的业绩并提高您公司的实际成熟度。
Bruce Hoffman，麦哲思科技CTO，CMMI 主任评估师
任甲林，山东大学计算机科学专业工学硕士, Scrum Master、CMMI 主任评估师、国际通用软件度量协会国际咨询委员会（COSMIC IAC）成员。。从1993 年到2013 年，他积累了20年软件工程经验。从程序员发展成为研发总监，参与或管理过50多个项目。2005年开始从事软件过程改进咨询工作，为接近100家客户提供过咨询或培训服务。2007年创立麦哲思科技（北京）有限公司， 2008 年至 2011 年度，他连续三年被评为“中国CMMI 咨询行业年度人物”。
本书是对我20多年在软件工程方面的所做、所思、所见、所闻的总结。在2005年6月之前我写了一些文章发表在www.51CMM.com，2005年6月之后开始在MSN建立自己的共享空间，后又转为在blog.ccidnet.com建立博客，做咨询的各种体会、客户的各种问题的解答慢慢地总结记录在博文中。本书的内容来源大抵如此。
我自己比较懒，英文名字Dylan Ren也源于此，我希望读为“大懒人”。所以我自己没有想起来整理博文。还好，有朋友激励我。最初是常州国光的杨建华先生花时间对我的博文进行了汇总，后来富士康的陈东源先生也想整理我的博文，于是我将杨先生整理的材料发给了陈先生。陈先生长我10岁之多，老大哥不吝时间，对这些材料建立了目录，标识了他认为重点的字句，让我甚为感动。而后成都虹微的王小康先生也希望帮我整理这些资料。为了不辜负各位的厚爱，于是2007年年初我就自己开始整理这些资料了。
在整理时，我重新对这些文章进行了分类，修改了某些文章的标题，并补充了未公开发表的一些资料，对某些口语化太浓的字句进行了修改。其实，修改后反倒发现丧失了博文中的那种自由与亲切。
修订这些资料的过程也是自我反思的过程，是与自己对话的过程，温故而知新，累并快乐着。有时发现很难准确地把一个思想表达得很严谨，因此而烦恼、灰心，于是就放下一段时间，冷处理后再拾起来重新修订。
本书是以CMMI 为主线，也融合了敏捷的很多实践，是我的软件过程改进思想的记录，是一己之见。限于能力，书中的描述有很多地方不尽人意，观点也存在偏颇，希望阅读本书的朋友能够多多拍砖，以使本书更加完善。
我的理想是能够写一本通俗的书，借鉴佛教、基督教传播其教义的方法，通过一些通俗的故事传递思想；也希望能学习郭德纲的相声、学习金庸的武侠小说，把跌宕起伏、高潮频现、引人入胜的写作手法与软件工程的科学严谨融为一体。理想和现实有很大的差距，虽然我自己不满意，但是我尽力了。
2008年11月，陈冀康编辑找到我，希望将我的博文整理成书。陈先生将书籍命名为《术以载道—CMMI 咨询札记》，取自于我的一篇博文《术与道》，我甚以为然，于是大家一拍即合。2013年初再给陈先生看此书稿时，他认为内容有了很大的充实，于是更名为《术以载道—软件过程改进实践指南》。
每次重读自己写的内容，每次都不满意，都需要静下心来修改，以至于出版的日期一拖再拖。
我希望本书能够成为一本实用之书，但未必完备而严谨，这是现实和理想的平衡。
变化是永恒的，改进是永恒的！
2013年1月19日
本书写作的目的
本书总结了我12年的软件开发与管理经验、8年多的过程改进咨询经验，记录了我所做、所思、所见与所闻，希望本书能够给从事软件过程改进、软件企业管理咨询、软件项目管理、软件开发的人士提供一些具体实践的借鉴与参考。
本书读者对象
● 过程改进与质量管理人员。
● 项目经理。
● 软件企业的中高层经理。
● 软件开发人员。
如何阅读本书
本书共13章，每一章的主要内容与适用的读者如下表。
本书编写体例说明
正文中重点强调的文字采用了黑体字。
所有的案例全部加框并用楷体排版。
致谢
感谢我的计算机启蒙老师吕云龙先生。从1986年高中入学时，就跟着您在Apple及中华学习机上学习Basic语言，您带领我参加信息学竞赛，训练了我的逻辑思维能力。和您一起在泰安、长岛度过了2个愉快的假期，情景历历大目。
感谢我的大学母校山东师范大学。为我大学 4 年提供了宽松的上机学习环境，在机房上机的日日夜夜，极大地提高了我的动手能力。感谢我的指导教师刘芳爱老师，在您的指导下我在大学里完成了编辑器软件的开发。
感谢对我一生的做事风格影响最大的王虎老师。从1993年到2004年，11年的时间里从您这里我学到了做人、做事的方法，您对我的教诲与爱护让我受益终生。
感谢在1998年指导我做过程改进的郑玉林老师。您的认真让我感慨至今。
感谢 2004 年引导我进入 CMMI 咨询行业的周伯生老师。和周老一起做评估，是我最快乐的日子，周老的睿智、对问题的敏感，周老的软件工程经验、不懈的奋斗精神，一直是我奋斗的标杆。
感谢以长虹集团、富士康集团、TCL、大连飞创、北京体彩、山东中创、南京润和、中海信息、浙江中控、深圳酷派、天源迪科、厦门联想等为代表的忠诚的客户。通过和大家一起成长，我学到了很多最佳实践，激发了我的灵感，积累了大量的案例。
感谢我的同事吕英杰、周伟、刘军、徐栋哲、Bruce、王婉荣、徐浩伟、洪艳艳、王新华、柯能江、关钦杰、雍迪、温丽莎等。大家任劳任怨地帮我做了很多工作，在和各位的沟通交流中，校正了很多我的错误观念。
感谢我的家人。你们承担了所有的家庭事务，在我“有工作，没生活”的状态下，帮我消除所有的后顾之忧。
谢谢你们！
关于勘误
尽管我花了很多时间和精力去核对书中的文字，但是因为时间仓促和水平有限，可能对某些错误熟视无睹，本书仍难免会有一些纰漏。如果大家发现什么问题，恳请反馈，相关信息可发到我的邮箱renjialin@measures.net.cn。
对于本书中的任何疑问或想与我探讨，可以访问我的个人博客：http://blog.csdn.net/dylanren或者直接在我公司的网站上进行实时沟通：www.measures.net.cn。
CMMI 是Capability Maturity Model Integration 的缩写，译成中文称为能力成熟度集成模型，或者更通俗地称为集成的能力成熟度模型。CMMI 的前身是SW-CMM（SoftWare Capability Maturity Model），SW-CMM 是美国国防部委托卡内基梅隆大学软件工程研究所（SEI-CMU）开发的用于评价软件开发组织过程能力的模型。SW-CMM 1.0 版本发表于1991 年，两年后发布了SW-CMM 1.1 版本，该版本成为CMM 历史上最经典的一个版本，长达13 年的生命力，直至2006 年，SEI 宣布CMM 1.1 版本“太阳下山”。2000年12月SEI 发布了CMMI 1.0版本，随后CMMI 1.1 版本也成为一个影响巨大的版本，CMMI 1.1 是集成了SW-CMM，SE-CMM（系统工程能力成熟度模型）、IPD-CMM（集成产品开发能力成熟度模型）之后发展而成的一个版本，在CMMI 1.2版本之后又划分为 CMMI -DEV+IPPD、CMMI -ACQ、CMMI -SVC三个系列，分别应用于开发类（包括集成产品类）、采购类、服务类组织。2010 年11 月发布了CMMI 1.3版本。相对于CMMI 1.2版本，1.3版本增加了对于敏捷方法和产品线管理等新技术的描述，吸收了很多敏捷的实践，并且对于高成熟度的实践进行了细化说明。
CMMI 是一个过程框架，给出了一组管理企业的最佳实践。何谓框架？比如我们走在马路上看到一幢正在建设中的高楼，建筑者浇灌了水泥，搭筑了整个大楼的基本结构，我们看到了整座楼面的概貌与主体，但并不是一幢装修完整的楼，在这个框架基础上，我们可以进行后续的加工定制，使其成为各式各样的漂亮的楼。
在CMMI 中定义了一个企业（注：为通俗起见，本书中以企业指代各种组织，如公司、研究所、技术中心等之类）要管理的各个过程域，正如我们定义一幢楼的各个子系统一样，比如一幢楼有电梯系统、照明系统、供水系统等等。CMMI 中也定义了每个过程的核心实践，正如我们定义了建设照明系统的最佳实践一样。
何谓最佳实践？就是得到业内认可的、多家成功企业的成功做法。
为什么判定这些实践是最佳的呢？因为多家成功的企业都是那么做的，并且获得了成功的。前车之鉴，后车之师。
是否存在你认为是最佳实践，而我认为不是最佳实践呢？CMMI 中的最佳实践是美国卡内基梅隆大学软件工程研究所（全球最好的软件工程科研机构之一，自2013年1月1日起专门成立了CMMI 研究所）组织了很多来自工程界与理论界的高手一起讨论总结出来的，是经过了多次评审得到的共识。如果你有证据表明确实有更好的实践，你可以认为它们不是最佳实践。
是否高手们认可的最佳实践就适合我们的企业呢？未必，但是应该基本适合。之所以说未必，是因为每个企业有每个企业的特点，别人的成功实践在你的公司未必能够完全对症。之所以说是基本适合，是因为这些实践是抽取了成功企业的共同点、共同实践而得到的，应该能够以很大的概率适合你们公司的情况。
如果不适合你的企业怎么办？裁剪！只有适合你的才是最好的！
如果裁剪了就不能满足CMMI 模型的要求，怎么办？CMMI 模型中的要求分成三种严格程度。
（1）必需的。目标是必需的，即无论你如何做，只要满足目标即可。怎么判断呢？经验判断！谁来判断？评估时的评估组成员！评估组成员累计的工程经验（除主任评估师以外）要超过25年才可以。在评估时只要有评估组成员都一致同意才可以（都同意或大部分同意、有个别人保持中立，没有人反对）。灵活吧？CMMI 不是死的，不是刻板的，做得刻板了不是CMMI 的错，是你没有理解CMMI 的要求，不能因为你刻板，而说CMMI 不好，这是社会上很多人常犯的错误。如果主任评估师不同意怎么办呢，讨论啊。主任评估师也是有经验的人，是懂工程实践的人，是经过严格选拔与培训的，是讲道理的。如果真不认可你的做法，要么你的实践确实有问题，要么你被冤枉了，这是小概率事件，哪个庙里都有冤死的鬼。
（2）期望的。实践是期望的，所谓期望，是说你最好那么做，你不那么做也可以，但是你要证明你的替换做法是可以满足目标要求的。怎么判定是否满足了目标要求？同样也是由评估组成员进行经验判断。
（3）参考的。子实践、实践的名字、目的描述、对目标与实践的解释说明、文档案例、注释、参考、共性实践的细化说明、其他案例等，都是参考的说明，是解释性的资料。但是，需要注意的是，SEI 认为很多企业没有理解模型的要求，是因为没有关注CMMI 中这些参考的解释性说明。
CMMI 模型每 3～5 年就会发布新的版本，为什么？与时俱进！最佳实践在今年是最佳，明年就可能不是最佳了，出现了更好的实践，也需要吸收进来。
以上是解释最佳实践的相关含义。再返回来说说框架的含义。如图1-1所示，在这个框架中，还有很多东西都是空的，等待补充、等待装修，模型应用到每个企业后需要各个企业补充完善那些空白。用什么去补充完善呢？用你们公司的实际做法，用你们公司能做到的做法，用敏捷的方法，用ISO，用什么都可以，只要你能满足“必需的”！CMMI 并不排斥其他的最佳实践，在满足“必需的”前提下，什么都可以！还是那句话，CMMI 是活的，不是刻板的。有最低要求，有可变通的要求。
CMMI 模型分为三个分支。
适用于供方、乙方的模型如下：
CMMI -DEV：主要是针对开发类组织；
CMMI -SVC：主要是针对服务类组织；
适用于需方、甲方的模型如下：
CMMI -ACQ：主要是针对采购类组织。
CMMI -DEV 提到的开发，是包括了软件、硬件等类型的开发。CMMI -DEV 模型还可以适用于复杂多学科产品开发的IPD模式，在CMMI 之外称为IPD，在CMMI 之内称为IPPD。IPPD并没有涉及市场、财务等。多出来的一个P代表过程，IPD中包含了市场与财务，所以IPD与IPPD是有一定差别的。IPPD有其适用范围，IPD也是同理。国内有些企业盲目追随华为实施IPD，成功者少，失败者众。为什么呢？没有注意IPD的适用范围。IPD适用于以下范围。
（1）复杂产品的开发，需要多学科配合协同的产品开发。
（2）市场驱动的产品开发，产品需要随时判断是否满足市场需求，投入产出是否合适，如果不可以，需要随时终止产品的开发。
（3）项目团队规模比较大，需要划分为多个小组进行协同工作。小组之间的沟通是项目成功的一个制约因素。
CMMI 模型在1.1 版本中对IPD 的支持包含了 2.5个过程域，在1.2 版本中是通过描述的附件来支持，在1.3版本中则直接融合到了OPD和IPM这2个过程域中。
CMMI -DEV 包含了22个过程域。何谓过程域（Process Area，缩写为PA）？过程域是一类最佳实践的集合，这些最佳实践属于同一类过程。CMMI 中有167条特定实践，264条共性实践，需要将它们分类管理，以便于实施，便于记忆。分类方法是人们分析、认识问题的一种主要的方法。CMMI 将所有的实践划分成了22类，每一类包含的特定实践个数从4个到 14个不等。这种分类是否就完全合理呢？仁者见仁，智者见智，没有绝对的合理，有的实践放在某个PA中很自然，有的就有点牵强，CMMI 就那么划分了，你就那么记忆吧。
要注意过程域与过程的概念不同，过程域是实践的集合。何谓集合？集合中的元素是没有严格的先后顺序，是一个堆（堆是数据结构中的专业术语）。过程是活动的偏序集（偏序关系是离散数学中的专业术语），活动之间是存在先后顺序的。不要搞混了这两个概念，否则是很囧的。
22个过程域分成4大类，项目管理类、过程管理类、工程类、支持类，其核心内容见表1-1。
通过表 1-1 我们可以看到，CMMI 模型中包括了很多开发活动。没有包括什么呢？没有包括考核，没有包括市场，没有包括财务、行政、人事等其他非开发管理活动。对于开发活动是否都包含全面了呢？项目立项、技术预研、系统维护等活动并没有描述在里面。没关系，立项、预研、维护的活动都可以分解为上述PA中的活动，也可以认为是含在里面了。
每个过程域有其名称与简写，一般我们都称呼其简写，比如一说REQM就知道是需求管理过程域，一提DAR就代表了决策与解决方案过程域。不一定要刻意去背诵它，知道每个缩写代表的英文单词，自然就记住了。
CMMI 的内容是按照成熟度等级或过程域类别、过程域、目标、实践、子实践的方法进行分类管理的，这些概念之间的整体与部分关系可以参见图1-2。
每个过程域（PA）都有一个目的，在英文里明确区分了Purpose与Goal这两个单词，我们翻译为目的与目标。在中文里这两个单词并没有特别明显的区别。Purpose是一种抽象的、宏观的期望，Goal是一种具体的、微观的期望。
PA之间有一定的关联性，互相影响，比如RD的输出为TS的输入；TS的输出又影响了RD的输出，如此交织在一起。在CMMI 模型中有多张图描述了各个PA之间的关联关系，也仅仅是一个概念的视图，不能全面描述复杂的交织关系，参考而已。
在每个过程域里对实践进行了细分类，即又分为多个目标，目标是对实践的一种分类方式。目标又分为特定目标与共性目标，所谓特定目标是指某个PA所特有的，即这个PA有其他PA没有。所谓共性目标是指每个PA都有的，你有我有他也有。目标是CMMI 模型中必需的构件，是不可以裁剪的，是评估时必须考察、必须满足的。
对应于每个目标有能够满足此目标的实践。特定目标有对应的特定实践，共性目标有对应的共性实践。实践是期望的模型构件，所谓期望即最好这么做，如果不那么做，你可以替换这些实践，但替换后必须满足目标的要求。每个目标对应的实践之间没有严格的先后顺序关系。比如需求管理过程域对应的5条特定实践：
SP1.1 与需求提供者对需求达成一致的理解；
SP1.2 获得需求实现者对需求的承诺；
SP1.3 管理需求的变更；
SP1.4 建立与维护需求的双向可跟踪性；
SP1.5 识别需求与工作产品间的不一致。
这 5条特定实践之间没有严格的先后顺序关系。在管理需求的变更之前，我们已经建立了需求跟踪矩阵，根据需求跟踪矩阵进行了需求变更波及范围的分析，所以不能认为 SP1.3与SP1.4之间存在严格的先后关系。
每条实践都有一个编号，如前所述，SP代表的是特定实践，GP代表的是共性实践，1.2代表第1个目标的第2条实践。比如SP1.2代表第1个特定目标的第2条实践，GP2.3代表第2个共性目标的第2条实践。
在CMMI 模型中绝大部分实践都列举了工作产品的样例，这些工作产品样例并非都是必需的，而是可选的，只要你能证明你的工作产品满足了这条实践的要求即可，不必从文档名字、文档个数等方面和模型保持一致。
每条实践都可能有子实践，这些子实践是对实践的细化描述，是对实践的解释说明，可以根据企业的实际情况选择适用的子实践。我也曾经看到有的企业在做CMMI 时，把每条子实践都定义在体系中。如果真有用，还可以理解；如果不是这样，就太机械了。
对于过程域、实践、子实践都有一些解释性的说明，这些解释性的说明在正式评估时是供参考的，对我们准确理解模型的要求有一定的帮助。
对于CMMI 的构件一定要注意“必需的”、“期望的”、“解释说明”三种严格程度之间的区别，不要把后两种上升为“必需的”，这是很多公司常犯的错误，切记切记。
为了加深对过程域中各个构件分布的理解，我对CMMI -DEV 1.3 版本中的特定目标与特定实践的分布做了统计分析，如表1-2、表1-3、表1-4和图1-3所示。
CMMI 分为两种表示方法：一种称为阶段式表示方法；另一种称为连续式表示方法，如图1-4所示。
我们可以从以下几个方面来理解这两种表示方法的区别与联系。
1．包含的过程域相同，但是过程域分类的维度不同。
阶段式表示方法为我们所熟悉，我们通常说的过了2级、过了3级都是针对阶段式表示方法而言的。在CMMI -DEV V1.3 中，阶段式表示方法将22个过程域分别放置在4个等级中，其中2级7个过程域、3级11个过程域、4级2个过程域、5级2个过程域；在连续式表示方法中将22个过程域分成了四类，其中工程类5个过程域、项目管理类7个过程域、支持类5个过程域、过程管理类5个过程域。
2．改进的路线图不同。
阶段式表示方法给出了固定的路线图，即必须先是2级的7个过程域，然后是3级的11个过程域，依此类推，在实施高等级时也必须实施通过低等级的过程域。而在连续式表示方法中，企业可以自己选择你想改进的过程域，可以针对自己企业的弱点进行针对性的改进，可以灵活选择改进点。在CMMI 模型中项目管理类、支持类与过程管理类的过程域又区分了低级和高级的PA，比如对于过程管理类的过程域，OPF、OPD、OT是低级的PA，OPP、OPM是高级的PA。按照连续式表示方法改进时，建议先从低级的过程域开始改进。
3．评估级别的评定维度不同。
在评估时，阶段式表示方法是针对整个组织进行统一评级，即评价组织的成熟度等级为2级或3级等，简写为ML2或ML3。连续式表示方法是针对整个组织的某些过程域评级，即评价组织的某个PA的能力等级为2级或3级，简写为CL2或CL3。注意两种表示方法对管理水平等级称呼的区别：阶段式称为组织成熟度等级（简写为ML），连续式称为过程能力等级（简写为CL）。成熟度等级是从1到5计数，能力等级是从0到3计数。
两种表示方法之间的等级有如下的换算关系。
（1）ML2级的7个PA都达到了或超过了CL2级，则可以评价为ML2。
（2）ML2和ML3的18个PA都达到了CL3，则可以评价为ML3。
（3）ML2、ML3和ML4的20个PA都达到了CL3，则可以评价为ML4。
（4）ML2、ML3、ML4和ML5的22个PA都达到了CL3，则可以评价为ML5。
注：在22个过程域中，SAM是唯一一个可以在评估时裁剪的过程域。
4．满足的商务需求不同。
根据上面的描述我们可以发现，连续式表示方法为企业的改进提供了灵活的方法，更加实用。可是为什么很多企业选择了阶段式表示方法呢？我认为主要的原因是对外宣传的简洁性，以及政府补助驱动的作用。
那么到底应该选择哪种表示方法实施改进呢？
如果你只要证书，当然选择阶段式。但是，记住了，不要找我们咨询。
如果你要实效，不要证书，你就选择连续式。这是我最喜欢咨询的企业。
如果二者都要，你可以先选择连续式，再选择阶段式。鱼和熊掌兼得，需要好好平衡一下。
了解CMMI 的人都知道，CMMI 的阶段式表示方法有5个等级，但是要将5个等级的区别真正说明白、说透彻，不太容易。下面我们用一个表格概括之。如表 1-5 所示，表格中并没有1级，1级在CMMI 的阶段式表示方法中没有对应的过程域，是起始级，所以不加描述。
表中比较内容解释如下。
1．过程改进的侧重点
CMMI 的2级是已管理级，是项目组对自己的过程实施了基本的管理，并不一定是组织级统一的管理规范。项目组可以自己管理自己的流程，也可以由组织级统一定义流程。3 级是由组织级统一发起过程改进活动，统一定义流程，项目组基于组织级的标准流程进行裁剪。而4级则要求在组织级对度量数据进行统一的分析，发现规律，建立组织级的过程性能目标、过程性能基线与过程性能模型。5 级则要紧紧围绕企业的商业目标实施过程改进，解决过程改进的实际商业收益问题。
2．管理制度的复杂度
CMMI 的2级包含了7个过程域，3级包含了11个过程域。2级是基本的管理过程，是从无到有的过程；3级是逐步完善、提升、统一的过程，达到3级时，企业的过程覆盖了18个过程域；4、5级分别包含了2个过程域。是否意味着在4、5级增加了过程域，过程定义就更加复杂了呢？不是的！4、5级的核心是解决了量化地刻画了过程的性能，围绕商业目标优化过程！所谓优化并非是指越优化越复杂，而是指越优化越经济！做最少的事情满足目标，取得投入与产出的最好平衡。
3．过程能力
过程能力指的是过程持续稳定实现过程目标的能力。
我们可以用职业运动员与业余运动员的水平差别进行比喻。比如职业的射击运动员，他每次出枪总能命中9环左右，而业余选手可能有时打飞，有时打中10环，当他抬手射击时我们无法预料他下一枪究竟多大的概率命中9环以内，也就是说我们可以从稳与准两个维度判断其水平的高低。
稳：每次射击的命中环数很接近，没有大起大落的现象，这样才可以预测。即使你每枪都脱靶，我们也可以认为你过程很稳定啊（必须脱靶在相近的位置）。为什么呢？因为我们可以预料到你下一枪还会脱靶。
准：每次射击的命中环数接近靶心，是我们期望的结果，这样才可以说你水平高，可以参加世界级的比赛。
CMMI 的2级和3级对过程没有稳与准的要求，而4级要求稳定，消除过程偏差的特殊原因，5级要求又稳又准，持续优化，优化过程偏差的一般原因。2级的过程由项目经理自己掌握，只要满足了CMMI 2 级7个PA 的要求即可，3 级要求组织级必须定义标准过程，项目组进行裁剪，过程基本统一即可。这也是2级称为已管理级与3级称为已定义级的由来，已管理级即项目组已经实施了基本的管理；已定义级指组织已经定义了标准过程。
4．过程定义的可行性
过程定义指的是过程设计。做一个项目，我们拿到需求后会在技术上进行设计，考虑需求在技术上如何实现，从管理上也需要进行设计，考虑这个项目在管理上如何实现，管理上的设计主要是过程的设计，两者的对比关系参见图 1-5。过程设计在CMMI 模型中描述了3个层次。
层次1：生命周期模型的选择与项目阶段的划分，这是2级PP过程域的要求。
层次2：组织级标准过程的裁剪，这是3级IPM过程域的要求；
层次3：子过程的裁剪及验证过程或子过程对目标的可实现性，这是4级QPM过程域的要求；
层次1的要点是阶段设计，层次2的要点是过程设计，层次3的要点是子过程设计，要求是逐步深入，过程设计的颗粒度越来越细化。
5．管理的前瞻性
项目管理类的过程域在2级中有4个：项目策划（PP）、项目监督与控制（PMC）、供应商子合同管理（SAM）、需求管理（REQM）。在3级中有2个PA：集成项目管理（IPM）、风险管理（RSKM）；在4级中有 1个PA量化项目管理（QPM）。3级的IPM与RSKM是在2级的 3个过程域（PP、PMC、SAM）基础上更高的管理要求，尤其是IPM过程域。PP要求做计划，PMC要求在计划执行过程中进行事中与事后的监督与控制，而IPM强调了事前对照计划的管理活动，强调了计划的合理性、可行性，强调了过程与人员的协调一致问题，而4级的QPM则要求对过程定义的可行性、项目目标的可实现性进行量化的预测与管理。从2级到4级项目管理的变化，是一个从无到有，从简单到完备，从经验到量化，从事中、事后的反应式管理到事前的预测式管理的变化过程。
6．目标的可度量性
CMMI 2 级和 3 级并没有对项目目标提出要求，即项目组可以定义也可以不定义项目的质量与过程性能目标，即使定义了也不需要证明目标的可实现性，可以凭经验定义目标。而在4级和5级则明确提出，项目必须定义质量与过程性能目标，并且要求目标应该是文档化的、量化的、可以实现的，目标要符合SMART原则。
● Specific：文档化，明确。
● Measurable：可度量。
● Attainable：可实现。
● Relevant：和商务目标的相关性。
● Time-bound：在规定的时间。
目标的可实现性是需要重点解决的问题。怎么保证目标是可以实现的呢？（1）目标是基于历史的性能制定的，不能与历史偏差太大，如果偏差很大，必须有充分的理由证明之。（2）可以采用过程性能模型预测目标实现的可能性，即在什么样的投入下，这个目标是可以实现的，实现的概率多大。如果是小概率事件，则认为目标是不可实现的。
7．度量数据的完备性
CMMI 的2级有MA过程域要求进行度量分析，但是此PA仅要求每个项目组按自己的需求定义、收集、分析、存储度量数据，并没有要求在组织级统一定义度量元。而在3级中则要求建立组织级度量库，组织级统一定义需要采集的度量元。在4级中要建立组织级的过程性能基线与过程性能模型。过程性能基线的建立需要对组织级统一定义的度量元进行数据分布的分析，以求得历史数据的位置与离散程度。过程性能模型的建立则要求建立过程的输出与过程输入、属性之间的关系，既要度量Y也要度量x，x即为过程的输入与属性，度量数据的采集范围要比原来广泛了。
8．度量的服务对象
CMMI 2 级采集哪些度量数据是由项目经理来确定的。3 级采集哪些度量数据是由组织级统一定义的。项目组可以裁剪。2级和3级采集的度量数据主要是为了监督项目过程的性能，而 4 级采集度量数据是为了建立过程性能基线与过程性能模型，不但要对过程的输出采集度量数据，也要对过程输入、过程的属性采集度量数据，采集的度量元相比2级和3级更多了。5级的度量数据是围绕改进组织级的商业目标来采集的。
9．管理技术的客观性
管理技术的客观性是指是是否采用了统计技术对项目实施了量化管理。
这里说的统计技术不仅仅是指度量了数据，对数据画了饼图或其他图形的分析。统计技术包含了 2个方面：统计描述技术与统计推断技术。对于一组数据计算了平均值、标准差等称为统计描述。统计推断技术是指根据样本的统计量可以推断出总体的统计量，发现统计的规律，比如根据3000个家庭父母的身高、孩子的身高得出一个计算孩子身高的回归方程。
基于统计的技术非基于经验识别过程的异常、识别管理中的问题，这正如中医与西医看病的区别。中医看病是凭经验，经验好的大夫看病比较准，经验差的大夫看病水平则比较低，同一种病，不同的中医大夫诊断，结论可能相差很大。西医看病是基于各种检测指标，如血压、血小板的含量等等，是客观的决策，同一种病，不同的西医的结论差别不大。
上述的区别是我在咨询中对这4个等级的体会，不代表CMMI 研究所的官方解释。每个人也许有每个人的感悟，各有道理吧。
在建立体系之前需要研究CMMI 模型的要求以建立理论基础。那么，究竟如何学习CMMI 呢？我的体会如下。
（1）通读模型
模型是众多专家总结的最佳实践，历时多年，讨论了许多遍才写成的。模型里包含的信息量很大，描述得很完备，需要全面地通读模型。比如，有朋友问我，开发工具是否要识别为配置项？其实这个问题在模型里有明确的答案，只要去读CM SP1.1 的描述就可以了，模型的原文如下（CMMI® for Development, Version 1.3, CMU/SEI-2010-TR-033，P140）。
Configuration identification is the selection and specification of the following：
● Products delivered to the customer
● Designated internal work products
● Acquired products
● Tools and other capital assets of the project,s work environment
● Other items used in creating and describing these work products
<参考译文>
配置识别是选择和刻画：
● 交付给客户的产品；
● 指定的内部工作产品；
● 采购的产品；
● 项目工作环境的工具和其他重要的资产；
● 用来创建和描述这些工作产品的其他物品。
再比如，对于CM SP1.2 建立配置管理系统，有的企业仅把实际应用的配置管理工具视为证据，其实仔细去读模型的原文（A configuration management system includes the storage media, the procedures, and the tools for accessing the configuration system）就会发现：存储的介质、规程与工具三者结合起来构成了配置管理系统，因此物理的配置项、配置管理工具及配置管理规程都是该实践的物证。
需要注意，应尽可能通读模型原文，尽管已有中文版的模型可以下载，但是翻译后的资料与原文还是有些差异，可能丢掉了原文里的很多含义。
（2） 咀嚼模型
模型不但描述得完备，而且简练，很多思想蕴含在平淡的叙述之中，因此需要仔细体会模型里的每一句话，要反复地阅读模型。比如对DAR SG1：评价候选方案。模型中该目标的原文如下（CMMI® for Development, Version 1.3, CMU/SEI-2010-TR-033-P151）：
Issues requiring a formal evaluation process may be identified at any time. The objective should be to identify issues as early as possible to maximize the time available to resolve them.
<参考译文：在任何时间都可以识别需要执行正式评价过程的问题。目的是尽早地识别出这些问题以预留出尽可能多的时间用以解决这些问题。>
仔细体会这段话，传达了以下这样几个含义。
● 在任何时候都可以采用 DAR，比如项目的初期、中期、后期。项目的初期会有哪些决策呢？开发方法的选择、技术路线的选择、开发工具的选择、需求的裁剪、供应商的选择等等。中期呢？深思之。
● 应该尽可能早地识别出需要执行DAR 的问题，以留出足够的时间解决问题。在项目进展的早期应该尽可能多地识别出需要执行DAR的问题，这样能够考虑得更加完备。
再比如，对于PP SP1.1 估计项目的范围。模型中该实践的正文为（CMMI® for Development, Version 1.3, CMU/SEI-2010-TR-033。P283）：Establish a top-level work breakdown structure（WBS ） to estimate the scope of the project.<参考译文：建立高层的任务分解结构以估计项目的范围>
top-level是第几层呢？仔细读该实践的第2条子实践：
Identify the work packages in sufficient detail to specify estimates of project tasks, responsibilities, and schedule。<参考译文：详细地识别任务包，以明确估计项目的任务、责任和进度>
据此可以推理出：这里所说的 top-level 的 WBS 就是分解到工作包级，基于工作包做估计、分配责任及安排进度。如果仅仅从字面的含义认为top-level就是第1层的WBS ，那就是笑话了。第1层只有1个节点，没有实质性的意义。
书读百遍，其义自现！
（3） 参考其他模型
CMMI 是融合SW-CMM、SE-CMM、IPD-CMM等几个模型而来，为了保证能够适合于多种学科，在术语上往往比较抽象，因此当对某些实践无法读懂时，就要相应地去参考其他模型。比如对PI SP1.1 确定集成顺序，对于软件系统的集成，当系统的规模不大时，其实开发顺序在很大程度上决定了集成顺序。为了加深理解该实践，在实际执行过程中很好地裁剪该实践，可以参考SE-CMM 的BP05.08等实践，在SE-CMM的BP05.08中有如下的描述。
The larger or more complex the system or the more delicate its elements, the more critical the proper sequence becomes, as small changes can cause large impacts on project results.
The optimal sequence of assembly is built from the bottom up as components become subelements, elements, and subsystems, each of which must be checked prior to fitting into the next higher assembly. The sequence will encompass any effort needed to establish and equip the assembly facilities (e.g., raised floor, hoists, jigs, test equipment, I/O, and power connections). Once established, the sequence must be periodically reviewed to ensure that variations in production and delivery schedules have not had an adverse impact on the sequence or compromised the factors on which earlier decisions were made.
<参考译文：
系统越大、越复杂或元素越易损的，正确的顺序就越关键，因为小的变动就可能对项目的结果带来很大的影响。
最佳的集成顺序是进行由底向上的集成：当部件集成为子元素、子元素集成为元素、元素集成为子系统时，每个层次在集成到更高的层次之前都要进行检查。集成顺序中也包含了所有建立和配备集成工具的活动（例如：活动地板、基座、起重机、夹具、测试设备、I/O、电力连接线等）。一旦建立了集成顺序，则必须周期性地评审以确保生产和交付工期的变化对集成顺序没有负面影响或者对早期的决策进行折中调整。>
在阅读 CMMI 时可以参考的资料包括：SW-CMM、SE-CMM、IPD-CMM、PMBOK、ISO15504、TSP、PSP等。
（4）映射到本企业的实际情况
CMMI 模型既适合于软件开发企业，也适合于硬件生产企业，既适合于软件产品的开发，也适合于外包类的软件企业，不同类型的企业对于模型的每条实践解释是不同的，需要结合企业自己的实际情况解释模型。
CMMI 模型是基于实践提出的，不是理论推导出来的。模型里的实践或多或少都可以在本企业的实践中找到映射。“做没做”、“做得好不好”，是在和企业的实践进行映射时必须考虑的问题，通过这种映射可以加深对模型的理解。
比如，对TS SP1.1 开发候选解决方案与选择准则，在企业里候选方案的开发与选择可能发生于投标阶段、立项阶段、设计阶段，企业的这些不同阶段的实践都可以映射过来，在投标或立项时可能是涉及对总体方案的选择，在设计阶段可能涉及对具体某个产品构件的解决方案的选择。通过与企业的实践进行映射就可以发现，这里提到的解决方案实际上是泛泛而言，并非仅仅针对总体技术路线的选择，某个具体的构件的解决方案的选择也适合。
判断“做没做”仅仅是最基本的映射，判断“做得好不好”才是更高层次的映射。在CMMI 模型里，因为模型里的实践是可以替换的，所以只要达成了模型里每个PA的目标的实践都被认可就可以了。
（5）与多个人讨论模型
一个人的视角是有局限的，通过与其他人的沟通，可以从不同的人员那里获得不同的信息，从而对实践理解得更加全面与深入。即使别人的观点未必是正确的，也可以在讨论中受到启发，也可能激发自己更多的想法。组织应该建立定期讨论的制度，通过一种制度化的沟通来确保大家关注过程改进工作，真正地投入时间去考虑如何改进。在我咨询的一个客户中，有一个项目组每周都定期抽出一定的时间大家一起研读模型，这种沟通与讨论对理解模型、识别组织的优势与劣势很有帮助。不要仅仅限于与组织内部的同事进行讨论，与其他组织的同行进行沟通帮助可能更大。
我建立了一个QQ群：133986886，我的很多客户都参与了该过程改进的讨论群，大家可以在这个群里进行模型相关的讨论。
EPG 是工程过程组（Engineering Process Group）的简写，EPG 是企业内的立法机构，负责制定与推广管理规范与过程财富。
选择什么样的EPG 成员才合适？基于我的所见所闻所思，总结了4个选人的要素。
（1）知识
知识是基础的要求，应该具有基本的软件工程知识，而不是白纸一张，这样才能容易沟通，知识可以通过学习来获得，有无知识是相对的；知识可以通过是否学习过哪些课程，接受过哪些培训、读过哪些书籍来衡量。
实践出真知。知识经过实践的锤炼才能真正成为自己的知识，对知识与经验进行了再加工、创造出新的理念才是对知识与经验的升华。
无知并不可怕，可怕的是不知道自己无知。很多自以为是的人都不认为自己无知。
（2）经验
软件工程是一门实践型的学科，缺乏足够的经验就很难理解模型里的各个实践，否则即使读了模型，也无法引起共鸣，文字都认识，但是文字的真正含义却无法透彻地理解。古人云：读万卷书，行万里路，讲的就是知识和经验的重要性。在实践中有很多事情是无法靠知识来解决的，而是要靠经验。
经验是要积累的，积累需要时间，悟性高的人可以更快地积累经验教训，有执行力的人可以积累真正实用的经验。
（3）悟性
悟性是举一反三的能力，是知微见著的能力，是自我学习、自我进步的能力。有悟性的人才能循序渐进地改进自己，也才能循序渐进地发现组织的缺陷，才能改进组织的标准过程。
悟性难以通过学习来获得，在很大程度上是天生的，悟性决定了一个人在某个领域可以达到的层次。
知识与经验是悟性的源泉，没有知识与经验，悟性就无法产生新的思想。
（4）执行力
所有的知识、经验、心得必须在实践中得到证实才能创造价值，否则只能是夸夸其谈，华而不实。知识、经验、心得要应用到实践就必须有一定的执行力，而不是停留在脑袋里无法落实。
在这4个要素中，执行力是必须具备的，如果不具备执行力，则一事无成。
要求每个EPG 的成员都具备上述的四个要素是不太现实的，要注意搭配。在上面的4个要素中，除执行力是必须具备的要素外，其他 3个要素的重要性应该是按悟性、经验、知识依次降低。
仔细想想，其实做任何事情可能都需要这4个要素。
很多企业的EPG 成员不知道应该如何开展过程改进的工作，不知道日常应该做什么，一旦脱离了咨询顾问的指导，过程改进就失去了章法。表1-6列出了EPG 每日、每周、每月、每年应做的事情，为EPG 提供工作的参考。
流程的改进，总是会涉及人的利益。有的人不愿意放权，有的人希望借助过程改进获得更多的利益，有的人不愿意暴露自己的问题，有的人不愿意改变工作习惯，有的人不愿意被束缚，有的人就是看EPG 不顺眼。有人的地方就有政治，如何应对呢？
（1）坚持正道
何谓正道？
公司的规章制度即为正道。公司的规章制度定义了做事的原则、方法，是公司的法律。循规蹈矩，别人就无法指责你的错误，这样才能立于不败之地。我不犯错，你奈我何？否则，你不遵纪守法，反对你的人就很容易否定你。
老板的指令即为正道。有法依法，无法则依老板。企业是法治与人治的结合体，不按老板的意思办，迟早要完蛋。按老板的意思办，即使错了，也有老板为你顶着，即使给老板当了替罪羊，也有翻身的机会。
做人的基本原则即为正道。与人为善，不损人利己，不做缺德的事情，做一个好人，这是做人的正道、做人的底线。即使周围的人都损人利己，你也要保持自己的风骨，淡然处之，不媚俗。这样可能失去一次机会，但是不会永远失去机会，即使当前不为企业所容，日久见人心，早晚大家都会敬重你的人品，即使是你的对手。
常言道，世上的事最怕认真二字：认真，即为坚持正道。
（2）以柔克刚
何谓柔？何谓刚？
柔即变化，刚指强大的反对力量。以柔克刚，意味着不与对方发生正面冲突，进行适宜的变通。只要能够达到目的，在不违背原则的情况下，进行灵活变通，使事情能够进展下去。有时，隐忍待机，也是一种柔。事情做成了，这是目的，这是根本，这是大义，做事的中间过程有所让步，有所付出，这是小节，不可因小失大。局部你吃亏了，最后你胜利了，这便是吃亏是福。着眼于未来，才能具有柔的精神，而执著于一点，针尖对麦芒，最终两败俱伤，难以成功。
何谓克？
克即让对方不得不顺从你的意愿做事情，无法抵触，无论对方是心甘情愿，还是心有怨言，即使有怨言，这个怨言也无法针对你而来。克，并非一定是对方要服从你，而是要服从你手中的武器。你的武器是什么呢？你的武器是理，是法，是上级领导，是群众的舆论，是人性的弱点。总之，借助于其他武器，使对方无法对你发力，不得不服从，这便是克。当然如果你自身在企业中已经具备了很高的威信，则就可以柔于外，刚于内，别人就更乐于服从了。
坚持正道，以柔克刚是刚柔并济应对企业政治之道，需要仔细体会，认真思量，逐步实践之。
（1）对模型研究不够深入
模型是多年软件工程经验的总结，模型中的每一句话、每个例子都不是随便写上去的，都有其内在的含义，需要仔细琢磨，仔细体会。作为EPG 的成员，在遇到问题时，首先要做的事情通就是通读模型，在模型原文中查找答案。注意不要去读那些粗制滥造的译本，以免以讹传讹。对读不懂的地方应该再去读SW-CMM与SE-CMM，从那里获取有关的参考描述。如果还读不懂，可以在网络上搜索资料或与朋友交流。
当然，不能“唯模型论”，模型不会解决所有的问题，模型也只是描述了做什么，在模型里并没有详细描述怎么做，要解决怎么做的问题需要与有实践经验的专家进行沟通。只有真正理解了模型才能不“唯模型论”，才能根据实际进行裁剪。
（2）不善于与项目组沟通
规范的管理是着眼于未来的，可以降低犯错的概率，其效益可能在当前并不明显。规范的管理会改变开发人员的工作习惯，在他们的眼中可能认为规范是一种累赘，因此对规范的抵制是一种很自然的反应。
EPG 是公司研发管理大法的制订组织者，是体系的推广者，项目组是体系的执行者。EPG 不是项目组的领导，在和项目组打交道时，不能以居高临下的姿态和项目组沟通，否则很容易引起项目组的反感，给体系的推广设置人为的障碍。
项目组里最有影响力的是项目经理，项目经理就是EPG 的重点沟通对象。质量管理体系是帮助项目经理进行管理的，是项目经理的助手，而非项目经理的敌人。应让项目经理意识到这一点才能够将体系推行下去。
（3）不善于利用企业高层管理人员
过程改进是一把手工程，尤其是在基础薄弱的组织中。如果缺少了企业高层的支持，体系的推广寸步难行。
EPG 不是项目组的直接领导，不可以直接对项目下达命令，因此在推广的过程要善于利用企业的领导，经常和领导沟通，和领导一起加深对研发管理的认识，从领导那里获得反馈，并借助领导的影响力促进体系在项目中的推广。
与领导的沟通是有技巧的，要根据领导的风格区别对待。有的领导喜欢直来直去，有的领导喜欢迂回曲折，有的领导喜欢独断专行，有的领导则比较民主。要将模型的思想转换为领导的思想，就要采取一定的技巧，对症下药。
案例：技术总监不关注的过程改进
我的一位老同事在A公司做技术总监。2006年底有一次朋友聚会，我知道A公司刚刚通过了CMMI 5 级的评估，于是便和这位老同事说起A公司已经通过了CMMI 5 级的评估，结果这位同事告诉我：“那是他们质量部门的事情，我不知道他们在做 CMMI ！”我很惊讶，也很怀疑这家公司是如何做地过程改进。
（4）不善于利用一切改进机会
为了推广体系，需要充分抓住一切在组织内教育员工、教育领导的机会。最典型的有 5个机会。
（a）客户要求
客户满意是所有企业经营都遵循的宗旨。利用客户对项目过程管理的要求识别改进点，更容易引起项目和领导对过程改进工作的重视。
（b）质量事故
一旦发生了质量事故就要追根溯源，进行根本原因的分析，以充分引起大家对质量的重视。
（c）成功案例
如果有个项目做得很成功，同样也要抓住机会，仔细深入地分析项目成功的原因，利用典型的成功案例教育大家。
（d）外部咨询
中国有句俗话：“外来的和尚会念经”。当有外部的咨询师或者评估师到企业时，也要充分利用这个机会，对员工和领导进行教育。
（e）内部调研
在企业里对管理现状进行调查，是一种自底向上反映大家对组织规范管理需求的有效手段。管理永远是需要改进的，改进的动力来自于商务需要，也来自于群众的呼声，群众的呼声可以转换为商务需要。
（5）EPG 本身作业不规范
EPG 要以身作则，自己也要按规范办事，不能表现得很随意。比如：
EPG 自己生产的文档不符合公司定义的各种规范；
EPG 自己的文档没有纳入配置管理；
体系文件的变更不遵守公司的变更流程；
EPG 的工作缺乏计划性；
对EPG 的工作没有执行PPQA等。
己身不正，何以正人？
（6）违背了循序渐进的思想
“以人为本，以过程为核心，以度量为基础，循序渐进”是当前各种管理模型的核心思想。管理的改进是文化的变革，要改良而非革命，不能拔苗助长，要冷水煮青蛙。一些软件开发中的基本实践看似简单，在企业里推行时却困难重重，例如需求文档化、设计文档化、计划文档化、同行评审、专职的测试人员等等。往往迫于商业目标的压力，在过程改进时，EPG 会定义不切实际的改进目标，试图短期内见效，这样就要求项目组一次改进的地方太多，而这么做，很可能事与愿违，导致项目组比较抵触，即使短期内能够通过评估，一旦拿到证书，反弹也会比较大。
过程改进是一种长期行为：
公司的高层对软件规范管理的认识有一个过程。
公司负责过程改进的人员对规范管理的理论理解也需要一个过程。
公司规范体系的推广需要一个实用化的过程。
公司开发人员认识规范管理也需要一个过程。
公司管理问题的解决从认识到制定措施、落实措施、优化措施也需要一个过程。
公司管理体系真正制度化也不是短期内能做到的。
任何事情都有其发展的必然规律，违反了客观规律是要摔跟头的，欠债总是要还的，拖得越久，利息越高。上述的所有过程都不是短期的行为，有很多思想意识当时明白，过后又忘了，需要在实践中不断验证才能成为习惯，需要在实践中不断地强化和加深。
（7）忽略了裁剪指南
裁剪指南比体系本身更重要。僵化的体系是不可能真正在组织里推行下去的，要保持体系的灵活与敏捷，就必须定义详细且实际的裁剪指南，并在实践中逐步完善。EPG 的成员往往试图包罗万象，将体系定义得相当完备，在过程定义、模板定义上花费了大量的时间，而忽略了裁剪指南是体系更重要的部分。这样导致在实际推广中，体系可以裁剪的选择余地很少，针对具体的项目组，往往会让项目组多做一些无法产生价值的活动，这样项目组就会产生一些抵触情绪。
（8）忽略了持续培训
在过程改进的初期会做CMMI 的Introduction培训、过程域培训、管理技术的专题培训，在体系定义完成后，会做体系的培训。这些培训要么集中在一段时间内完成，培训的密度比较高，效果并不好；要么间隔的时间比较长，培训后面的内容时已经忘记了前面的内容。因此，需要在体系的推进过程中再将已经做过的培训的要点换个角度进行强化，使一些观念、一些做法深深地刻在每个人的脑子里，才能让执行者知其然，知其所以然，这样才能成为习惯，持之以恒地坚持下去。
（9）缺乏足够的软件工程经验
这一条实际上是在选择EPG 成员时容易犯的错误。以CMMI 模型的博大（这也是其缺点，不够通俗与平民化），要想充分理解其内涵，理解其精神，没有足够的软件工程背景是比较困难的。而很多企业的EPG 成员恰恰就缺乏足够的软件工程经验，有经验的员工都去生产一线做项目经理或部门经理，去直接创造商业价值了，间接创造商业价值或者会带来长期效益的管理活动便让一些缺少经验的人来做，这实际上是一种“脑体倒挂”的现象。缺少经验的人需要到一线去工作，去锻炼，去提高，那些有经验的员工则需要充分贡献出其经验，充分发挥他们在企业里的正面影响力，而不是成为过程改进的阻力，这才是他们的价值的体现。
（10）过分依赖咨询公司
EPG 成员在建立公司内部过程体系的初期，往往会过分依赖外部咨询公司，要求咨询公司提供已成型的过程体系文档。每个组织都有其自身的特点，产品方向可能不同。组织结构可能不同，企业文化可能不同，人员结构可能不同，外部的商务环境也可能不同，因此企业的作业流程、文档格式等都可能不同。如果机械地照搬，那么势必造成EPG 建立的标准过程并不适合本组织，从而使过程改进见效缓慢，甚至夭折。
望闻问切，弄清病症、病因，才可开药方，过程改进与此同理。那么，过程改进如何识别改进点，发现病症呢？
1．过程评估
过程评估是指由内部或外部的评估员参照某种或某几种模型通过文档审查或访谈等手段评价组织的过程执行情况，以发现体系、实践与模型的差距，识别改进点。参照的标准与模型是可以随时间的推移而变化，可以不断地从新的标准与模型中汲取营养。
2．过程裁剪记录分析
组织级定义了标准的体系规范后，项目组可以裁剪组织的标准体系，通过分析裁剪记录可以识别频繁裁剪的过程、活动、文档等，这些频繁被裁剪的元素就可能是不适合企业实际情况、需要改进之处。
3．不符合问题分析
PPQA人员对项目组的过程与工作产品进行检查可以发现不符合体系的问题（NC），通过对 NC 项的共性分析，可以发现项目组通常都会在哪些地方犯错误，犯错的原因是体系本身定义得不合理，还是由于培训与指导不够，或者其他原因。
4．问题或缺陷分析
客户的投诉、客户反馈的问题、测试发现的问题、过程性能的异常等都是财富，需要分析这些问题或缺陷的根本原因，识别为什么会发生这些问题？为什么没有尽早地发现这些问题？
案例：对问题的原因分析
下图是我2011年3月在深圳给某个客户咨询时，针对项目组反馈的用户优先级划分不合理的问题进行原因分析的记录。通过这种原因分析，可以发现企业中的改进点。
5．经验教训分析
向经验学习，向教训学习，推广经验，规避教训。组织级可以定期汇总、分析、评价这些经验教训，选取有价值的经验教训吸收到组织体系中。
案例：通过分析经验教训持续改进
2007年7月，有位朋友推荐我拜访济南的一家软件公司，这家公司大概100人，我在济南生活了10多年，对济南的软件公司比较熟悉了，但是我从来没有听说过这家软件公司。我刚进入这家公司时，印象并不好，因为是夏天，气温比较高，这家公司并没有开空调。随着和公司老板的沟通，我发现这家公司管理得很好，比一些通过CMMI 3级评估的企业管理的实效都好。他们成功的经验是什么？每月项目经理都会给老板汇报本月的经验教训，老板每月都从这些经验教训中提取出来可以推广的最佳实践，定义到公司的质量体系中，在公司中推广之。久而久之，公司的体系逐步完善发展起来，而且很有实效，没有多余的活动。
6．度量数据分析
组织级定义了共性的度量元要求各项目组进行采集，通过分析这些共性度量元的实际数据可以发现好的或差的异常，通过分析这些异常的根本原因可以发现改进点。
7．过程改进建议分析
过程体系的执行者、监督者都可以基于自己的理解对过程体系提出改进建议，这些改进建议应该由专人进行讨论、分析，确定共性的、有意义的建议并吸纳改进之。
8．标杆数据对比分析
国际、国内都有一些组织定期发布度量数据，可以将组织内的基线数据与这些标杆数据进行对比分析，寻找差距，鉴别差距的真实性，寻找差距的原因并改进之。
9．高层经理的改进需求
公司的中高层经理接触客户、接触市场、接触其他的合作伙伴或竞争对手比较多，他们会基于企业发展的需求、基于外部商务的需求，对企业内部的过程改进提出期望与目标，这些也是改进点的来源。
企业的EPG 成员必须熟练运用上述最常用的九种识别病症的方法，及时发现改进点，实现持续改进。
在基于CMMI 实施软件过程改进时，有些根本的思想认识问题解决不了，往往会导致实施过程改进的周期变长，效果不佳，甚至终止或失败。软件企业的高层领导、企业的过程改进主管、销售人员、项目经理及一般的开发人员都需要对这些问题统一认识，在此基础上才能消除各方面的阻力，把握好过程改进的方向，控制好过程改进的进度。在实施CMMI 时必须解决如下几个思想认识问题。
（1） CMMI 不是万能的，需要技术、人员、过程三个要素一起改善
在软件工程发展的历史进程中，人们为了解决软件危机，尝试采用了诸如形式化描述语言、结构化开发方法、CASE 工具、构件化开发方法等等各种解决方案，但是效果并不那么显著。美国卡内基梅隆大学软件工程研究所提出的软件过程能力成熟度模型是基于过程的角度来应对软件危机。那么是否实施了 CMMI ，软件企业的开发能力就一定能提高，一定能带来经济效益呢？答案是否定的。企业要带来经济效益必须要结合软件过程、工具、开发方法、人员等多种因素一起提高，因为人员、技术和过程是支撑软件开发的三条腿，少了哪一条都不行，如图1-8所示。在管理学中，有所谓的“木桶原理”，即一个木桶可存水的最大容量是由最短的那根木头决定的。在企业的开发能力中，过程，技术（含工具、方法），人员都是主要的因子，都需要全面提高，只关注一个方面，而忽略了其他方面，很可能事倍功半。
在开始实施CMMI 时，最容易犯的一个错误就是“唯管理论”或孤立地只抓过程改进，忽略了开发技术与人员的提高，实施了半年或一年后，发现企业的生产能力并没有得到明显的改善，这时反对的声音就会成为主流，过程改进就难以继续进行了。有的企业采用面向对象的开发方法进行软件开发，但是企业内并没有对面向对象技术真正了解的专家，虽然也采用RUP过程、ROSE等开发工具，但是仅仅是形似，没有做到真正的面向对象方法，没有得到面向对象方法的精髓，这种问题仅仅依靠过程改进是无法解决的。还有的企业开发人员的积极性很差，工作热情很低，企业的激励机制没有起到很好的作用，这种问题也是依靠CMMI 无法解决的。
案例：人员培养的瓶颈问题
2007年，我曾经为江苏一家软件外包企业做咨询。该公司2003年时就通过了CMM 3级的评估，经过多年的持续改进，企业的过程体系简洁而高效。但是该公司的开发人员基本上没有超过 3 年工作经验，尽管过程定义得简洁高效，项目组成员也能按标准与规范执行，但是项目组成员编写的需求文档、设计文档、代码与测试用例的质量比较差。我每次去运行检查都要首先作为同行专家去发现这些文档的bug，帮助项目组成员去发现工作产品中的内在的质量问题。在这家公司，过程就并非最突出的问题，而人员问题才是瓶颈，迫切需要解决的是人员培养问题。
案例：技术复用的威力
2007年底，我曾经到深圳一家软件公司做售前。该公司有3个做类似软件的开发部门，其中一个部门花了 4 年的时间积累了一套可复用的框架，当有新的员工加入该部门时，只要花 1 周的时间学习该框架，就可以开发出可以交付最终用户使用的应用系统，具有很高的开发效率，但是，其他两个部门却没有复用该框架。当完成一天的初步差距分析后，我告诉该公司老板：“只要将该框架推广到其他两个部门，获得的效益要超过实施CMMI 的投入产出比！对这家公司而言，目前迫切需要解决的是打破3个部门之间的“墙”，复用其中一个部门的框架，将该框架演变为组织级的框架，就可以在短期内提高整个公司的生产效率。
（2） 过程改进的效果不是立竿见影的
在实施CMMI 时，企业的管理层在开始时往往会对过程改进的期望值太高，希望在短时间内达到显著效果，但管理的改善是符合J曲线的。如图1-9所示，即在改善的初期企业的运行效率可能会下降，甚至可能会出现一些混乱的局面，但是度过了这段时间就会看到过程改进的效果。所以在改善的初期大家要有这个思想准备，要有耐心。
案例：建立老板对过程改进的承诺
2005年，我为北京一家公司咨询CMMI 3级，在差距分析的报告会上，针对企业的突出问题（比如研发人员的考核办法、配置管理等）老板做出了如下承诺。
在平均提高开发人员10%工资的前提下建立研发人员的考核办法；
可以购买不超过40万元的设备与软件工具用以提高管理水平；
在过程改进启动3个月之内，所有的反对意见暂时搁置；
……
上述的承诺写入会议纪要，并由公司老板亲自修改了会议纪要作为其对过程改进的承诺。在上述承诺中的第3条，其实就是对J曲线的认可。
（3） 坚持活学活用，以我为主
很多国内的软件企业都是从作坊式的软件组织逐步发展过来的，没有标准、规范，企业里真正超过10年软件工程经验的人员比较少，有经验的人员又不愿意从事质量管理与过程管理。因此很多企业的EPG 成员欠缺工程经验，又没有真正的有实践经验的专家进行指导，所以对CMMI 的理解就不可能深刻，于是就不敢裁剪CMMI ，容易机械照搬CMMI条文。其实这恰恰违背了CMMI 的精神，CMMI 是软件工程经验的集大成，是从实践中总结出来的，CMMI 本身也在更新版本，不断完善。
每个企业都有自己的特点，也都有自己的经验教训总结，就像微软的MSF，那是微软自己内部的管理过程标准，是微软的产品开发经验总结。有些内容是 CMMI 中没有的，完全可以借鉴过来使用，所以只要可以提高企业自己的软件管理水平，就应该大胆地尝试。
在推行CMMI 时，所遇到的阻力，很大程度上是由于照搬CMMI 的条文，不切合项目组的实际，没有具体情况具体分析。实际上，一线的管理人员、开发人员最了解实际。谁了解实际，谁就有发言权。所以在制定质量体系时，尤其是在制定大家都要执行的操作规程、模板时，一定要得到执行者的认同，否则就容易成为执行和沟通的障碍。凭借公司的行政制度硬性推行质量体系，表面上看来似乎大伙也照规程做了，其实是表面文章，对改善没有实际帮助，导致过程改进工作受阻。
案例：EPG 与开发人员建流程的对比
2011年我咨询了一家软件公司，在这家公司内建立体系时，项目管理类的体系是由一个EPG 成员参考其他公司的流程建立的，工程类的体系是由开发部门的资深人员建立的。2013年当我回访此公司时，质量人员反馈工程类的体系这2年执行的很好，而管理类的流程执行的不好，项目组成员总是找借口不执行或事后补文档。
（4）要改良不要革命
以革命的方式来实施 CMMI ，期望通过一场运动来解决过程能力的问题，一种可能是不懂 CMMI ，不晓得管理的改进是循序渐进的，另一种可能是明知故犯，期望在短期内通过CMMI 评估，单纯追求市场上的轰动效应。有的企业在短时间内虽然通过了CMMI 评估，但是由于没有实效而得不到大家的认同，所以难以将这种“水平”持续下去。过程改进就像减肥，你是可以依靠减肥药在短时间内减轻体重，但如果不从根本上改善饮食、生活、运动的习惯，那么体重将会在短时间内恢复。
我曾经尝试以革命的方式与改良的方式进行过程改进，效果差异很大，改良的效果比较扎实，所以应该让大家在“小步快跑”中接受变革，这样风险最小，效果最好。
案例：Genersoft公司的过程改进
Genersoft是我工作了8年的软件公司。1998年10月Genersoft开始启动了基于CMM的过程改进，2001年10月通过CMM 2 级的正式评估，历时3年。在这3年里，Genersoft成立了独立的测试部门，购买了测试工具、配置管理工具，对开发人员实现了量化考核，在考核中纳入了工作量、质量、过程符合性等指标。所有的上述改进都不是一朝一夕完成的，要建立企业的质量文化就必须扎扎实实地做。
（5）CMMI 与企业的创新文化是不矛盾的
软件企业必须形成创新的文化。管理与创新是软件企业发展的两个轮子，管理确保企业能够平稳地发展，创新能够实现企业的跳跃式发展，只抓管理不抓创新，可能导致企业的发展速度太慢，最终形成“快鱼吃慢鱼”的现象，只抓创新不抓管理，则可能导致创新无法转化为生产力。当然有的企业是以出售企业为目的，将整个公司作为一个产品销售出去，此时又另当别论。一个成功的企业，应该同时具备两个基本的条件，一是规模大，二是百年老店。中国有很多老字号，比如“**剪刀”之类的，虽然这个品牌存活了上百年，但是一直手工作坊，没有规模，也就没有太大的影响力。而当年的巨人集团虽然企业的规模可以快速膨胀起来，但是垮得也很快。这两类企业都不是成功的企业。
软件企业的有些管理人员，也包括一些开发人员，往往认为严格的管理会束缚他们的创新，他们认为 CMMI 提倡的是一种按部就班的文化，什么活动都要做计划、按规程标准来做，对企业的创新文化会起到负面作用。在我遇到的开发人员中，技术钻研越深的人持这种观点的越多。形成这种观点主要有两个原因：一是企业在推行CMMI 时，过分机械，没有从实际出发，不能与实践紧密结合，挫伤了开发人员的积极性。比如在分析与设计阶段，需要开发人员能够发挥创意的成分更大一些，如果要求他们一定按统一的文档标准来写文档，甚至字号大小、缩进格式一点也不能差，这的确很难做到，可能需要项目组配备文档支持人员来做这些完善工作，降低分析与设计人员的工作量。二是这类人员缺少真正的软件工程经验，做大项目的经验太少，经历的失败太少。CMMI 是工程经验与教训的大集合，我们无需再去重复那些失败。
技术创新必须通过管理才能使其有效地转化为生产力，转化为企业的实际效益，达到效益最大化，这是最根本的。管理的改进优化到一定程度就会遭遇“天花板”现象，此时就必须借助技术的创新或管理的创新才能突破屋顶，达到另外一个境界。
（6）要勇于实践，也要允许犯错误
CMMI 就是软件工程经验与教训的总结。在实施CMMI 的过程中，肯定会走弯路，甚至犯错误，因此许多人会议论纷纷，一直会反应到高层经理。这时不要犹豫，要敢于尝试，更不能因为有困难就打退堂鼓，要“摸着石头过河”，不下水，是没有办法过河的，临渊羡鱼不如退而结网。要少说不，少说难，多实践，有错就改。对于软件企业的领导尤其要注意这一点，不要因为在过程中的一些实践失败，就对项目经理、EPG 等人员有偏见，要以积极的心态面对改进。
（7）管理过程改进是组织内所有人的事情，而并非仅仅是EPG 的事情
按照CMMI 专家的建议，在一个组织内专职从事软件过程改进的人数应为组织总人数的29～39%，这些人称为工程过程组（EPG ），EPG 成员专职负责企业的软件过程改进工作。另外企业根据需要还会配备一些兼职的技术任务组（TWG），他们会兼职参与质量体系的制定、试点和修改完善工作。在这种情况，可能会出现如下的问题。
● EPG 成了最忙的人，TWG 的任务往往会由于那些兼职的人员以工作忙为理由一拖再拖，最后还是由EPG 成员替代TWG做工作。
● 企业的非开发人员没有明确地感受到过程改进的效果，有的甚至认为由于加了这些新的活动可能使项目拖期会更严重，于是他们可能就会将这些抱怨反馈给企业的高层经理。在推行过程中我经常会听到：这个项目时间太紧，当前不适合使用CMMI 。
● 高层经理迫于市场的压力，甚至可能会提出不合实际的项目工期等。
推行CMMI 不仅仅是管理人员的事情，每个人都要积极参与。要改变原来的一些做法： EPG 在使劲地推进CMMI 的工作，而不是大家自觉自愿地来实施CMMI 。从EPG 的角度来看，要做好培训的工作，首先要解决大家的思想认识问题，这还是比较难的，有些人的思想比较顽固。
过程改进首先要解决的就是思想认识问题，然后才是实施方法问题。不但在主观上要建立整体的思想认识，在客观上也要有切实可行的改进措施。光说不练是不行的，光练不说也是要否定的。任何变革都会涉及企业内部权力的再分配，不要忽视企业政治，这是客观存在的，所以一定要预防那些光说不练者。
案例：动口不动手的改进者
2008年，有一家软件公司启动了过程改进，从上到下都表示要积极参与，但是雷声大，雨点小，所有兼职的EPG 成员都以项目的工期紧、人手少为理由，并没有真正地投入时间编写质量体系，而是直接借鉴咨询顾问提供的样例或拷贝国家、国际标准。没有真正理解CMMI 模型，没有结合本公司的实践，体系的起草者们自己都无法解释清楚体系中定义的活动及文档模板的含义，这样建立的体系怎么可能推广起来呢？
基于 CMMI 的软件过程改进已经被越来越多的软件企业所接受，据不完全统计，2012年在中国有 400 多家软件公司通过了 CMMI 评估。但是，通过评估不是企业的最终目的，提高企业的管理水平才是实施过程改进的根本目标。CMMI 是一个过程改进的框架，并没有给出实施过程改进的具体策略，基于我自身过程改进及咨询的经验，概括出如下的11条策略供参考。
策略一：由底向上，主动改进
在进行软件过程改进的时候，通常有两种做法，称为自顶向下与由底向上。在自顶向下的做法中，企业成立一个推进小组，一般称为EPG （工程过程组），他们是企业里“开发大法”制定的组织者。EPG 组织一些专家成立各种任务小组，由这些任务小组参照过程改进的标准编写各种各样的企业标准与规范，经过一系列的评审、培训，然后发布、执行。在执行过程中最常见的阻力是来自于开发人员，他们往往会抱怨制定的企业开发规范不符合企业的实际情况，不实用，无法达到。这种做法，费时费力不讨好，大家的意见都比较大，标准可能定得比较完美，但执行时难以贯彻下去。在1998年、1999年我在企业里做过程改进时采用过这种方式，收效甚微。后来我切换为由底向上的办法，即由EPG 访谈开发人员、项目经理，让他们自我发现问题：你有什么缺点？你将如何改进？在开发人员、项目管理人员确定好自己的改进措施后，EPG 将其文档化，QA监督这些措施的执行。在这种办法中，不需要管理人员花费太多的精力进行标准的制定、改进的推动，这些工作都是由开发人员去做，管理人员仅仅起到监督的作用，只要开发人员自己说到做到就可以了。再做下一个项目时，管理人员同样会问这2个问题：你有什么缺点？你将如何改进？然后管理人员监督开发人员说到做到。如此循环提升、逐步完善，形成标准与规范。
可以从几个方面对上述两种策略进行比较，参见表1-7。
融合上述的两种策略也是一种解决方案。
策略二：循序渐进，由易到难，由粗到细，由松到严
CMMI 的一个核心思想是分级改进，采用渐变的方式而不是突变的方式进行过程改进。比如对于 2 级的每个过程域，可能你先启动一部分活动，支持部分目标，待制度化了，再实施另外一部分活动，直至支持全部目标。在实施CMMI 的过程中一定要根据企业的实际情况量力而行，千万不要把期望值定得太高，要一步一步来，先定出最基本的改进方案，要把握分级改进的思想然后逐步提高。
做到循序渐进，首先要对企业现状有一个明确清醒的认识。在按照CMMI 的评估标准分析现状时，下面的四个问题必须要解答。
● 当前我们存在哪些问题和弱项？
● 哪些问题和弱项是我们迫切需要解决的？
● 哪些问题和弱项是我们目前能够解决的？
● 哪些问题和弱项是我们当前无法解决，需要打好基础后才可以解决的？
接下来要对照标准，提出解决方案。按照“既要突出重点，又要力所能及，有所提高”的原则对问题排出优先级。
以PP、PMC这2个过程域为例，以下就是一种循序渐进的方案：
第一次循环：
（1）要求每个项目组都要用MS Project做项目计划，该项目计划要满足一定的条件，如：任务的颗粒度不能太大；任务负载要均衡；任务尽可能并行等。
（2）对每个项目组，按计划进度进行跟踪，在计划执行过程中及时发现问题，解决问题。
（3）总结本次循环执行过程中存在的问题。如，项目计划中任务识别不全；计划的任务工作量估算不准；在项目进行过程中，发现问题后采取措施不及时等。
第二次循环：增加完整的生命周期模型定义。
生命周期模型是项目管理的主线，定义一个好的生命周期模型是推行CMMI 2 级的一个最关键的基础工作。
（1）要求每个项目组首先要定义自己的生命周期模型，做出项目计划模板。
（2）要求每个项目组按照项目计划模板做项目计划。
（3）进行项目计划跟踪。
第三次循环：增加规模、工作量等的估算，进行更深入的计划管理，确保计划的合理性。
（1）要对项目的规模、工作量进行正式估计。
（2）按计划模板做项目计划。
（3）进行项目计划跟踪。
第四次循环：增加风险分析。
项目的风险管理是一个难点，所以建议将风险管理放在较后的循环中进行改进。
第五次循环：体系化，制度化。
每个企业应该根据企业的实际现状确定改进的图线，逐步提高管理水平。
策略三：先敏捷再规范
先敏捷再规范这个策略源于实践。其本意是先做到再写到，先短期利益再长远利益，先实效再完备。因为一步到位直接采用规范的方法，阻力比较大，效果难以持久，很可能事倍功半。敏捷方法以其短期内可以见效、对已有的开发过程调整幅度小等特点易被开发人员接受，所以可以先敏捷再规范，将敏捷作为通向规范的一个阶段。
芸芸众生，大都是凡人，凡人都是注重短期利益的。只有那些领袖、那些思想家才是目光如炬，站得高看得远。过程改进要从凡人做起，凡人是体系的执行者，所以首先要满足凡人的需求，让凡人看到好处。否则，群众的力量是无穷的，这力量可以是建设的力量也可以是破坏的力量。
敏捷方法是适应变化的一种方法。因时、因势、因事调整计划，它可以处理近期内即将发生或已经发生的变化，它不赞成为未来的不确定的变化花费太多的时间，变化会导致近期计划的调整，也使长期的计划难以预期。
采用敏捷的方法并不意味着没有规矩，没有文档、没有计划、没有跟踪与控制并不意味着就是敏捷。敏捷方法在落实其规矩时与重量级的方法有所不同。
（1） 敏捷方法减少了中间结果的记录，减少了管理与支持类的文档
敏捷方法减少了管理与支持文档的工作量，但并不意味着没有做管理，只是做得少、文档也少。比如敏捷方法也要做计划，也要估算项目的工作量，也要和项目组的成员沟通计划的可行性，也要获得项目组成员的承诺，只是这些管理活动可能只有最终的计划书，而没有中间结果的记录。在敏捷方法中很少看到关于质量保证活动、度量分析活动的系统要求。
（2）敏捷方法强调通过面对面的口头交流，减少书面的文字交流
文档是沟通的一种方式，口头交流也是一种沟通的方式。在重量级的管理方法中强调了文档的重要性，而敏捷方法并非没有文档，只是它认为口头交流更重要，口头交流效率更高，因此可以编写简单的设计文档，设计思想可以通过口头交流进行评审，用口头交流弥补文档简化的不足。因为文档简单，将来的变化也就少，维护的工作量也相应减少。但是口头交流在传递的过程中，很容易由于传递者个人的观点而对信息进行增删改，比如一些神话故事，各有各的版本。
（3）敏捷方法强调最终的交付物而忽略了中间产物
关注最终交付物的质量而不是中间结果的质量，采用诸如单元测试、结对编程、代码重构、持续集成、代码规范等手段确保源程序的质量。采用迭代的方法尽早进入编程，在过程中通过沟通进行设计的实时评审、代码的实时评审，以便于尽早发现交付代码的缺陷，尽早修复缺陷。作为开发过程的中间产物，需求与设计等文档则进行了简化。代码是必须交付的，所以要采用一切手段规范之，既然要交付，就要保证其质量。而需求与设计文档并非是必须交付的，需求和设计也是经常变化的，既然不交付，既然始终变化，干脆就不花时间去写。
（4）敏捷方法认为高效的人比规范的过程更重要
敏捷方法中最常见的是 3种角色：教练、客户、开发人员。教练起到了项目经理和过程指导者的作用，客户实时执行确认与验证的动作，开发人员去实现产品。一群精英如果能默契地合作，则不需要去监督他们是否按照标准规范去执行了，这个团队是自我管理的，大家有着共同的价值观，彼此能快速协同，互补合作，最终走向成功。是英雄创造了历史，还是人民群众创造了历史？结论不言而喻，但是如果没有英雄呢？如果各位都是英雄呢？
以上种种思想，反映了敏捷方法的实用主义哲学。如果一家企业的项目大都在10人以下，开发团队完全可以从敏捷方法开始着手进行过程改进。但是，软件开发存在非规模经济的现象，随着团队规模的增加，上述的手段可能很快就失效，还要回到重量级方法上来。
策略四：先下游再上游
先改进生命周期下游的流程，再改进生命周期上游的流程。
系统的维护阶段是用户方与开发方交流沟通最多最直接的一个阶段，开发方在此阶段的错误可以被用户方直接捕获，用户对开发方的管理水平、服务水平、开发水平的体会最直接最深刻。开发方应该首先改进与客户直接交互的流程，确保高质量的产品能得到有效的部署与维护。在维护阶段发现的问题，应该进行根本原因的分析，分析这些问题的产生根源，以提供客观的证据证明在生命周期上游存在的问题，便于从生命周期的上游开始改进。
采用此策略易于解决目前客户反应最强烈的问题，易于发现目前的瓶颈问题进行改进，能够在短期内取得良好的改进效果，制定的改进点易于为开发人员所接受，是一种典型的由表及里的改进路线。
策略五：测试先行
在管理基础薄弱的软件企业里，通过加强软件测试，可以直观地发现很多问题，事实胜于雄辩，从而使大家认识到质量的重要性，认识到进行过程改进的重要性；另一方面也减少了用户发现错误的概率。
设立专职的测试，让他们在开发过程中参与测试，可以发现项目开发过程中的很多问题。
● 项目组提交给测试人员的文档太简单，测试人员无法看懂；
● 项目组提交的文档与实际做出来的软件不一致，测试人员无法测试；
● 项目修改了需求与设计，没有及时通知相关人员，测试人员按旧的设计测试，有的开发人员按新设计开发，有的开发人员按旧的设计开发；
● 不同的模块界面风格差别很大，没有统一的界面标准；
● 测试人员测试的版本与开发人员开发的版本不统一；
● 项目组成员的分工不合理，有的开发人员任务重，他开发的软件缺陷就特别多；有的模块缺陷特别多，可能设计人员的能力比较弱；
● 项目组没有按计划提交测试，项目拖期；
● 软件运行速度很慢，怀疑系统的设计有问题。
通过对错误原因的分析，可以发现大量的管理问题、需求的问题与设计的问题，这些实际的问题对我们找出最关键的改进点，说服反对派，教育软件工程师，加快推进过程改进是一个有力的武器。
策略六：从经验教训中学习
每次去客户现场进行差距分析或者运行检查，我总是习惯于找他们的缺点，但是每次也总能发现他们的优点，时间久了。慢慢地对缺陷麻木了，审丑疲劳了，只有发现他们的优点时，我才会精神一振，心情愉快。
我始终坚信，通过每个开发人员、每个项目组、每个角色自我总结自己的经验教训，吸取这些经验教训，可以扎实地提高组织的过程能力，如果再加上参考某个模型，效果可能更好。而现实是，很多企业把眼睛盯在外部的参考模型上，而忽略了自身的经验教训，没有挖掘自身的价值，实在是让我痛惜。
曾子曰：“吾日三省其身！”，圣贤的话是很有道理的。
向自己的历史学习，针对性强、见效快、效果好！
灯，需要有人去点燃！点燃的灯，往往灯下黑！
案例：看看你的表，告诉你几点了
2007年1～2月份期间我去给一个客户做运行检查，整理完发现报告后，我查阅了6个项目组的阶段总结报告与项目总结报告中的经验教训部分，我发现的 60%的缺陷他们自己也感觉到了，只是没有人去提取，去系统地归纳整理、去落实。他们老板的一句话马上浮现在我的脑海里：“咨询顾问就是当你问他时间时，他拿过你的手腕，看看你的表，然后告诉你几点了，再向你收费！”。他们没有想到看自己的手表，我就充当了那个看手表的顾问，我比他们更知道手表的价值。
策略七：因材施教，各个击破
在一个企业内可能有多个开发项目组或者开发部门，不同的组与部门有不同的管理水平，在我们推行CMMI 时，不要一刀切，不要希望每个队伍同时达到CMMI 2 级或更高的级别，应该区别对待。比如说产品研发的部门，经常进行大大小小的各种各样的升级，产品的版本比较多，他们对版本管理认识得很深刻，在工作中积累了一套行之有效的版本管理方法，对于这样的部门可以实施配置管理PA的要求，进一步提高管理水平，而对于其他做系统集成的部门这方面的工作可能就差一些，没有很好的版本管理的基础。因此，如果一刀切，要求大家都在3个月内都达到CMMI 2 级的要求，这个目标对系统集成的部门就定得太高了。所以在进行改进时应针对不同的项目组、不同的部门定出不同的改进计划，如可以采用表 1-8 的方式来定义不同项目组、不同PA的阶段计划。
策略八：教育与培训并重
教育主要是改变思想观念，培训主要是传授具体的方法，二者互补，以使员工能够知其然，知其所以然，能够在主观上认可，客观上执行。
进行教育与培训有各种方式，需要配合起来使用。
（1）观摩学习。看看其他的标杆企业是如何做的？和其他企业的管理人员多沟通交流。这种方式是企业的高层管理人员经常采用的。
（2）请外面的专家来讲。俗语讲得好“外来的和尚好念经”，这句话屡试不爽。企业内的人说多遍可能效果甚微，外面的专家讲一句，一下就点透了，对方就接受了。
（3）自我反省。开发人员进行自我分析找出自己的不足，并提出改进意见，大家互相沟通交流这些经验教训，自己教育自己。
（4）培训。培训可以分成多种：技术型培训与管理型培训，这是最基本的工作，思想工作做通了，培训起来效果就会比较好。
过程改进不能仅仅定义为开发部门的工作，需要整个企业的所有人员的参与和重视，因此教育与培训的对象比较多，不要有遗漏，如：
a）高层管理人员：为什么要进行过程改进？所支持的经营目标是什么？企业能提供哪些支持？在过程中会出现什么问题？对公司有哪些正面与负面的影响？需要领导配合做哪些工作？要认识到工作的艰巨性。
b）开发管理人员：技术与管理知识，CMMI 的理念、作用。
c）开发人员：技术与管理知识，CMMI 的理念，企业的政策、规程。
d）市场人员：要认识到SPI过程改进的重要性、SPI对市场的影响，在此过程中如何配合？
e）客户：对于一个项目而言，需要提出合理的进度、质量与投入的要求，并把握需求的范围。
案例：富士康科技集团的教育训练
自2006年6月起，我便为FOXCONN集团提供CMMI 的咨询服务，接触了多个事业群。在我接触到的所有企业中，FOXCONN 集团是教育训练做得最优秀的。平均每位员工接受训练要达到288工时/年，师四及以上级别的工程师每年对内部员工必须做两次教育训练，如果无法达到这个考核指标，则影响员工的晋级。
在给FOXCONN SIDC 部门咨询时，楼道的墙壁上贴满了本月的培训课程，内容很丰富。这些课程有些是FOXCONN集团评定的内部教员讲授，有些是外部讲师的讲授，有些是以前历史培训的录像。
有一位事业群的老总讲过一句话让我记忆深刻：“我要让我的员工一半时间挣钱，一半时间提高！”
策略九：充分利用管理工具
管理工具可以作为思想、方法的载体，它可以将管理可视化、客观化，降低劳动强度，解决手工无法解决的问题，易于为开发人员、管理人员所接受。充分利用管理工具来推行过程改进是一个很好的策略。
1998 年我在做过程改进时引进了MKS SI 配置管理工具、Project 98 计划工具、SQA 测试工具、以及QA monitor等其他的一些管理工具。开始引入的时候是有些难度，毕竟是对工作方法产生了改变，一旦熟练了，就习惯了。
对工具的选择与购买需要把握好“够用即可”的原则。软件开发管理工具一般比较昂贵，如果一次性投资购买了比较昂贵的软件，可能软件的80%的功能用不上，待企业的管理提高到工具软件可以支持的较高的管理水平时，已经是2年以后的事情了，而2年以后的版本也需要升级更新。所以，没有必要为用不到的80%的功能提前投资。而现在各种各样的开源工具比较多，功能可以满足需求，又便于进行客户化，因此，充分利用开源工具是一个不错的选择。
策略十：内外结合，以内为主
目前很多软件公司，为达到在较短的时间内通过CMMI 的评估，签订咨询合同，寻求咨询公司的帮助，我认为这也是一个可行的方式。原因有以下几个方面。
（1）咨询公司熟悉CMMI 框架，并提供相应的培训，可使公司的EPG 抓住重点，少走弯路，与完全依靠组织自身的EPG 相比，可缩短实施的周期。
（2）咨询公司的培训往往比公司内部的培训效果要好，正是所谓外来的和尚好念经，公司内的认可程度较高。
（3）咨询公司对组织资源的建议，比较易于获得企业高层的采纳，引起组织的重视。
但同时也需要注意，不要过分依赖咨询公司，尤其不值得提倡的是，有些公司直接从咨询公司处得到标准、规程，囫囵吞枣，直接照搬照抄，真正是为了评估而评估。企业的标准规范必须与本企业紧密结合，这些标准规范在CMMI 中被称之为企业财富，只有符合企业实际情况的标准规范才是最有价值的。
咨询公司虽然可以提供帮助通过评估，但企业的过程改进还是要以内部为主。软件的过程改进实际上是企业文化的转变，而企业文化的转变归根结底是人的观念、思想、认识、做事方式的转变，是个人能力的提高，这种提高是通过组织中的EPG 、项目经理、工程技术人员、管理人员整体素质的提高得以实现的，这种实现的途径是通过学习、实践获得的。因此，软件企业要真正注重实效的改进，就要尽可能多的与咨询公司进行交流，不仅要知其然还要知其所以然，打破沙锅问到底，才能真正促进企业过程的改进，同时也能丰富咨询公司的工程实践经验，获得双赢的效果。
策略十一：由外而内的过程改进策略
何谓“外”？外，是相对而言的。
对于一个公司而言，供应商、客户为“外”。
对于一个开发部门而言，供应商，客户，其他部门（比如市场部门、运维部门等）为“外”。
对于一个项目组而言，供应商、客户、其他部门、其他项目组、其他支持组为“外”。
对于一个项目组内的小组而言，其他小组、其他项目组为“外”。
对于一个项目阶段而言，其上游阶段、下游阶段为“外”。
对于一个人而言，其他人为“外”。
在定义过程体系时，采用由外而内的策略，则意味着，可以采用如下的优先级定义和规范公司的管理。
1．先定义和客户、供应商的沟通协同规范，再定义公司内部的规范，如：
需求获取、用户确认、验收测试、试运行、用户验收、运行维护的流程。
……
2．定义公司内部各部门之间的接口标准、沟通协同规范，如：
市场转开发、开发转测试、测试转运行维护的接口标准、规范。
……
3．定义项目组和其他组之间的接口标准、沟通协同规范，如：
领导下达、验收任务的流程、标准；
项目组之间互相支持的流程、标准；
质量保证组、测试组以及其他支持组和项目协同的流程和标准。
……
4．定义各个项目小组之间的接口标准、沟通协同规范，如：
问题处理的流程、标准；
承诺、确认的流程、标准；
……
5．定义阶段之间的接口标准，如：
从需求阶段进入设计阶段的标准是什么？
从设计阶段进入编码阶段的标准是什么？
从编码转测试的标准是什么？
测试结束的准则是什么？
……
6．定义每个人的行为准则，如：
如何对项目经理承诺，如何给项目经理报告工作？
如何配合其他人完成开发任务？
……
说白了，此策略就是优先进行管理接口的设计，只不过接口有大有小，是“攘外必先安内”的反其道而行之！
很多公司在做CMMI 时在重复这种错误：“证书优先，机械照搬，文档泛滥，宁严勿宽”！
（1）“证书优先”
CMMI 的证书成了一个敲门砖，没有这个证书是无法承担国外的项目，没有CMMI 的证书就无法在国内一些项目的竞标中获胜，也无法获得政府的补助，于是很多公司都选择了要在短时间内获得CMMI 证书。证书只是过程改进的附属物，而过程改进的实效才是其真正的价值。为了尽快拿到证书，企业往往忽略了实效，从形式上满足了模型的要求，但是从实质上却差的很远。
根据SEI的报告，自1992年以来，从CMMI 等级1到等级2的达到时间的中间值为19个月，从2级到3级的中间值为19个月，从3级到4级的中间值为24个月，从4级到5级的中间值为13个月。在中国根据调查，从1级到2级的平均时间为14个月，从1级到3级的平均时间为18个月，到4级的平均时间为32.6个月，到5级的平均时间为34个月。
CMMI 的基本精神是循序渐进，循序渐进就是要逐步改进，逐步改进就要立足实际，就需要时间，而非一蹴而就。
（2）“机械照搬”
企业在实施CMMI 的时候，为了满足模型的要求，在描述自己的过程时，习惯于照搬模型的描述。最典型的例子是PMC过程域，该PA中包含了10条实践。
SP1.1 监督项目的计划参数
SP1.2 监督承诺
SP1.3 监督风险
SP1.4 监督数据管理
SP1.5 监督项目相关人员的参与
SP1.6 执行进展评审
SP1.7 执行里程碑评审
SP2.1 分析问题
SP2.2 采取纠正行动
SP2.3 管理纠正行动
于是有的企业就照搬上面的10个活动定义了自己的项目监督与控制过程，其实项目的监督与控制活动主要是：
（1）每天检查项目组成员的工作情况：进度，质量等。
（2）周例会。
（3）阶段审查与里程碑评审。
（4）事件触发的跟踪与管理。
这4个活动已经包含了模型中要求的10条实践，按照企业的实践来描述这个过程是最自然的，是项目经理最容易理解的，而不需要机械地按照模型的实践去描述。
机械照搬的根源在于缺乏软件工程的经验，不能真正理解模型的要求。在模型的构件中，只有目标是必需的，实践是期望的，子实践是解释说明的。所以首先要满足模型里每个目标的要求，目标的达成是根据实践的执行情况来判断的，模型里给出的实践是可以替换的。只要能达成目标，采用什么实践都是可以的。CMMI 采用SCAMPI评估方法，评估组的成员根据专家判断给出是否达成目标的判断，是依赖于专家经验的，所以在评估方法中对评估组成员的工程经验有明确要求。对于企业来讲，只要能达成目标，就没有必要一定照搬模型。
CMMI 最初的实践来源基于为美国国防部供货的软件厂商，这些软件厂商的企业规模比较大，软件项目组的人数也比较多。对于规模比较小、管理基础比较差的公司，有些实践并非一次改进就可以达成的，可能需要循序渐进地完成。
ISO组织在借鉴CMM模型起草ISO15504标准时，将软件企业的成熟度划分为了6个等级而非5个等级，实际上就是规避了CMM门槛太高的问题。CMMI 本身也在逐渐更新，从CMM 1.0、CMM 1.1、CMMI 1.1、CMMI 1.2 到CMMI 1.3。新的成功的软件工程实践也在不断地总结出来，比如每日构建等实践，这些实践都可以充分地吸收到企业的实践里面来。
其实判断哪些实践是否适合本企业，关键在于从事过程改进工作的人，他们是否有足够的软件工程实践，能够对比较好的实践很敏感。
（3）“文档泛滥”
文档与口头交流是两种沟通的方式，文档可以减少二义性，可以永久存储，可以方便检索，可以经济地存档，可以多人共享。而口头交流具有时效性，这个时刻说的话，如果不录音，第二天就无法重现了，而且往往讲话时所处的场景信息、讲话者的语气、神态等都是对语言的含义起到了辅助作用，这些都是不可重现的。因此文档作为一种沟通的工具远比口头交流更加有效。但是任何文档都不能将所有的信息包含在里面，文档不能解决所有的沟通问题，需要辅助以口头交流，二者是互补的，文字不能替代语言，语言也不能替代文字，在软件开发的过程中尤其是这样。
SCAMPI评估方法需要企业提供两种证据：物证和人证。每条实践必须要有物证来覆盖，物证包括了产出的文档、使用的工具等；人证是在评估时通过访谈来获得的。由于物证是必需的，于是为了满足评估的需要，很多企业做了上百个文档来满足模型的要求，其实这是不对的。模型是强调证据，但是并非文档越多越好，文档只是用来证明某个实践你做到了，只要达到了这个目的就可以了，而且一个文档可以满足多条实践的要求，可以作为多条实践的证据，其实这是最经济的做法。只要内容有了，也并不一定在乎文档的多少与格式。
需要注意的是，企业的成熟度不同、软件类型不同、客户群不同，同样是CMMI 2 级的企业或者同样是CMMI 3 级的企业，管理的严格与细致程度差别还是很大的。CMMI 的等级只是一个基本台阶，是基本要求。CMMI 对证据中包括哪些内容有基本的要求，但是并没有对文档的多少进行要求，文档的多少实际上与企业管理的细致程度紧密相关。
（4）“宁严勿宽”
把握好尺度，既能满足模型的要求，又能符合企业的实践是相当有难度的。放宽底线，是一种错误；同样超出模型要求并脱离了企业实践的要求，也是错误的，都忽略了 CMMI 的真正的精神。究竟什么该宽，什么该严呢？其实该严的是过程改进的实际效果，而非形式效果！首先就应该从企业做过程改进的时间上严格，不能鼓励那种短期行为！SEI建议的过程改进的模型是IDEAL模型，螺旋上升式地逐步改进企业的过程。有的企业一个循环没有做完，企业的过程体系没有经过多个项目的检验就通过 CMMI 3 级的评估，这显然违背了客观规律，这些都应该从严处理！严，应该是内容上的严，实践上的严，而不是形式上的严。为了达到模型的要求，让企业去补一些文档，表面上是严了，实际上却违背了CMMI 的精神，浪费了人力与时间！
曾经和一位朋友沟通关于在公司内实施过程改进的心得，我介绍了几个成功案例后，她突然问了一句话：“他们成功的最重要的原因什么呢？”，我第一反应是：原因很多啊！随即，在林林总总的原因中，我找到了自认为最重要的原因：“企业文化”！随着讨论的深入，越来越意识到这个结论的正确性。
企业文化也许是一种说不清道不明的东西，但是你却能切实地感受到。有的企业从员工到领导重视质量：系统没有经过严格测试不可以发布，文档没有经过评审不能正式发布；无论是小BUG还是大BUG，在公司内都会记录并跟踪至问题的关闭；测试与评审的任务都会在计划中明确识别出来等等。而有的企业对于质量的投入能省则省，领导不会过问质量问题，即使出了质量事故也只是就事论事地批评责任人，没有从根本上找原因，企业的管理体系无法落实下去。有的企业员工勇于承担责任，勇于实践，勇于吸收，采取有价值的管理改进与技术改进。有的企业员工则推诿责任，所有的好想法都停留于口头上，领导不推，自己不动。凡此种种，这些都是企业文化的体现。
仔细回顾我的成功案例，真的是：整个企业建立了重视质量的文化，企业具有强有力的执行力，这样的企业才真的将过程改进落实到实处。
企业文化是由人建立的，企业文化是由老板建立的，老板的文化代表了企业的文化，在我看到的软件企业中大都如此。
案例：富士康科技集团的文化
富士康集团自20世纪90年代初进入大陆设厂以来，已经发展成为了全球最大的代工厂。我在给富士康集团SIDC部门咨询时，每次讲课，培训教室座无虚席，因为座位有限， EPG 给每个部门分配听课的名额，每个部门的部门经理都会努力争取多要名额，有时每个部门都会多派人员参与培训，即使是站在教室的后边听课。每次做运行检查，当访谈一位员工时，部门的其他同仁如果没有紧急的事情需要处理，都会旁听，以期能够从别人的经验教训那里汲取营养。有一次有位部门主管返台度假，我无法进行当面访谈，结果该主管要求一定电话访谈，为什么呢？他希望能够帮他找到工作中的不足，能够帮他提高。从普通员工到高层主管，都用他们的言行给我传达了一个强烈的信号：“我要提高，我要改进”！我想这可能也是富士康能够快速发展的原因之一吧。
而其他一些客户表现出来的改进的热情却远远没有那么高。我曾经到深圳的一家私营企业做培训，只有寥寥数人听课，还都带了笔记本电脑不知在忙什么，现场的提问与沟通效果也很差，让我很是痛心。因为对方毕竟是花了高价请我来讲课，公司提供了帮助大家提高的机会，为什么不珍惜呢？
这便是文化的差异，文化的差异决定了企业未来的竞争实力。一个没有建立良好文化的企业不可能长久。
Infosys 公司是印度最大的软件外包企业之一，是CMMI 5级的软件企业，其质量管理水平全球闻名。Pankaj Jalote是印度理工大学计算机科学与工程系的教授和系主任。曾经是马里兰大学计算机科学系的副教授，担任过印度班加罗尔的Infosys技术有限公司质量部门的副总裁，在Infosys公司任职期间，他是推动Infosys向CMM高成熟度等级发展的主要设计师之一。他写了2本书介绍Infosys的过程改进与项目管理的经验：《CMM实践应用（Infosys公司的软件项目执行过程）》与《软件项目管理实践》。
我基于这两本书，提取了Infosys公司进行过程改进的18条经验。
（1）设定明确的过程改进目标，每次改进的周期不宜太长。
（2）保持过程定义的简单性，使过程定义易于为项目经理、开发人员所接受。
（3）尽可能减少过程定义的变更次数。
（4）基于企业的实践定义过程，使过程易于接受，并减少培训、部署的工作量。
（5）过程改进视同为一个项目，有明确的项目计划。
（6）为每个项目组配备质量顾问，质量顾问为EPG 成员，负责手把手指导项目组按体系执行。
（7）每次改进在3个月内完成体系修改与试点工作。
（8）在新项目中部署新的体系变更，正在进行中的项目采用旧的体系。
（9）对项目经理和开发人员培训公司定义的过程体系而不是CMM模型。
（10）建立EPG 与项目组成员沟通的WEB网站。
（11）进行质量和CMM的周测验，给获胜者以奖励。
（12）成立管理指导组（MSG），MSG由CEO领导，高层管理人员参与，MSG每月定期开会，检查过程改进的进展情况。
（13）CEO对从事过程改进的优秀者加薪、提升和股票奖励。
（14）对高层管理者进行关于CMM的高级培训。
（15）在MSG的例会上讨论过程改进项目的风险。
（16）聘用有经验的CMM咨询顾问判断公司的实践是否符合CMM的要求。
（17）EPG 负责组织定义过程，但很少由EPG 本身去制定过程定义。
（18）EPG 每月向其上级汇报过程改进的进展情况，每季度向公司管理委员会提交度量分析报告。
其实这个问题本没有答案，因为不同的企业难点是不同的。对于某些企业来讲，可能没有什么难点。譬如，某企业只想拿到一个评估证书，而不考虑改进效果。我是基于企业里最常见的难点泛泛谈之。尽管CMMI 2 级是最基本的等级，如果真想将CMMI 2 级做好，其实还是不容易的，通常情况下的难点如下。
（1） 做一个切实可行的计划
任务要识别得比较全面，估算的工作量比较合理，人员的安排不能超负荷、不能窝工、进度安排紧凑而不失弹性。
（2） 实时掌握项目动态，发现问题，解决问题
● 如果项目经理是技术人员出身，往往不喜欢实时管理项目中每个任务的进展，总是阶段性地去检查，发现问题比较滞后。
● 如果项目经理缺乏技术背景，监督进展时往往浮于表面，没有深入实际判断是否任务真的进展顺利。
（3）需求变更的影响分析要全面而完备
需求变更时要：
● 分析对设计、编码、测试用例的影响。
● 分析对规模、工作量、进度、成本的影响。
● 分析对客户、开发人员、测试人员、管理人员等的影响。
● 分析需求变更的相关风险。
（4）需求文档化
需求文档化是需求变更的基础，如果需求不全面、不正确、不详细则在后续的过程中变更的次数会比较频繁。如果需求没有文档，沟通时我们会这样讲：“传说，需求是这样的……”。基于传说中的需求时是不可能让客户顺利验收的。而要做到前面说到的全面、正确、详细，则可能需要加强需求获取、需求描述、需求评审的工作。
（5）收集真实的、有用的度量数据，并得出管理结论
度量数据不在于多，而在于“精”。所谓“精”的含义是指：数据要准，数据要有用，数据要反馈在管理实践中。
● 用数据说话，用数据说真话。首先要保证数据的正确性与及时性，其次要能够通过这些数据分析出结论，并体现在后续的管理措施中。数据的真实性是很多企业面临的难题，数据不真实，数据的实用性也就无从谈起了。
● 度量数据的需求来源是管理的需要。从客户、高层经理、项目经理一直到具体的开发人员，各个层次、各个角度的人员都有自己感兴趣的数据，要基于这些人的实际数据需求去度量数据，要自顶而下地基于目标建立度量数据，不要度量无需求的数据。
● 有的数据要对其进行分析，得出管理结论并定义相关的管理措施，以充分发挥数据的作用。否则，该数据就失去了存在的价值。
（6）建立开发人员实施配置管理的工作习惯
● 工作产品要及时入库。
● 工作产品的变更要符合流程，要保留历史痕迹，可回溯。
（7） QA 要严格、细致地对项目的活动与工作产品进行检查
在QA方面最常见的问题如下。
● 检查不全面，有的工作产品或活动没有检查。
● 检查不细致，不能及时发现产品与流程的不符合问题。
CMMI 2 级难点及对策参见表1-9。
CMMI 2 级是成功实施CMMI 的基础，真正将2 级做好了，对企业的帮助也是很显著的。而很多企业恰恰忽略了2级PA的实施，从而导致CMMI 的实施难以见到实效。2级需要抓住哪些实效点一定要落实呢？我做了如下的归纳。
1．建立WBS 分解的方法指南，训练项目经理如何进行任务分解，充分识别项目范围。
很多项目经理即使接受了PMP的专业培训，仍然没有掌握WBS 分解的方法，正如很多人拿到了驾照不会开车一样，缺乏实际训练。在实施CMMI 2 级时，组织级应该定义出WBS 分解的方法指南、模板，供项目经理参考，并对项目经理建立的WBS 进行多次评审，训练其分解的技能。
2．建立组织级的估算方法指南，教会项目经理如何做估算，为项目的工作量、工期、质量的平衡提供依据。
估算是帮助项目经理进行能力平衡的手段。通过估算工作量、工期、成本等可以平衡能力需求与实际可提供的能力之间的差别，即使不能满足也要知道差别有多大，这种差别是否可以通过加班、加人、裁剪需求等来弥补，不能糊里糊涂地做项目，即使死，也要死地明白。在项目组需要进行估算的时机主要有3个时间点。
（1）需求不明确，需要给客户报价或项目立项时。
（2）需求明确，需要制定项目的开发计划时。
（3）在开发或维护过程中，需求发生变更，需要变更项目计划或给客户承诺变更的完成时间时。
在不同的时机，不同的输入条件下，对于不同类型的任务采用的估算方法不同，不能一概而论。因此项目经理要灵活掌握，组织级要给出明确的指南。
3．教会项目经理使用Project排进度表，合理安排进度，优化资源投入。
排进度表时要定义出任务之间的先后顺序关系，然后识别关键路径，想办法减少关键路径的长度，然后安排资源，再识别出关键链，减少关键链的长度，合理安排缓冲的时间，这样才能保证项目在比较短的时间内完成。如果进度安排不合理，会造成人为地拉长，有人忙工期，有人闲。借助于项目管理的工具可以帮助项目经理识别关键路径，减少安排计划的工作量。万事预则立，不预则废。
建立WBS 、项目估算、排进度表是项目经理制定计划的三项基本技能。
4．建立组织级风险库，教会项目经理如何识别风险、管理风险，培养风险意识。
很多项目经理不重视风险的管理，缺少风险管理的意识，这就导致了在项目初期一些可能发生的负面影响没有被识别出来，没有采取预防措施，坏消息没有尽早暴露出来，最终导致项目的延期、质量不过关等。风险列表、风险分类识别、头脑风暴法、阶段驱动法、任务驱动法等是常见的识别风险的方法，简单易行。识别出了风险，无论是否可以解决，都能够帮助项目组成员、项目组的上级领导、客户等清楚地了解项目的状态，即使发生了最坏的结果，相关人员也能够谅解。
5．建立计划评审检查单，计划评审流程，保证计划的合理性与一致性。
计划的好坏可以通过计划评审活动进行检验，通过计划评审可以在各利益相关者之间沟通计划的内容，识别出计划中的缺陷，同时也起到了培训和教育的目的，帮助项目经理提升项目策划的能力，尤其是对于管理刚刚起步的公司，尤其需要注重项目计划评审。
6．建立组织级每日站立会议制度，实时跟踪项目进展。
在CMMI 中并没有要求一定要做每日站立会议，这是在敏捷方法中的一条实践，但是该实践简单易行，而且卓有成效，值得推广。通过每日站立会议可以及时了解每位项目组成员的工作进展，沟通项目的状态，同时也起到了建立团队文化的作用。
7．建立周例会的制度，定期评价项目状态。
如果导入了每日站立会议，未必需要开项目组内的周例会。
应该同客户每周至少沟通一次，应该同项目组的主管每周至少沟通一次。
通过周例会的形式建立一种正式的沟通渠道，使利益相关者全面了解项目的状态，发现问题，沟通问题的解决方法。
8．建立经验教训总结制度，固化管理经验教训。
在里程碑达到时、项目结束时，项目组要总结经验教训，组织级EPG 固化经验教训。一般每个月或每2个月就应该总结一次经验教训，最长周期不能超过每3个月。固化经验教训是稳步提升管理水平的一个有效措施，是减少推广阻力的有效措施。
9．建立跟踪项目进展、生产率的度量体系，量化了解项目状态。
通过项目进展的度量可以标识项目完成的百分比，能够对项目的进度有一个总体的、量化的了解，以跟踪项目的进展，帮助项目经理管理进度风险。生产率的度量可以为项目的工作量估算、进度估算提供一个参考。这2个度量数据是最基本的项目管理的度量数据。
10．建立瀑布与迭代生命周期模型，根据不同项目的类型分而治之。
在企业内一般都会含有瀑布与迭代两种生命周期模型。瀑布模型适合于需求稳定的小项目，迭代模型适合于需求不稳定的项目。瀑布模型管理比较简单，相对而言迭代模型管理稍微复杂一些。通过定义生命周期模型可以帮助项目经理设计总体的项目管理思路，将大的复杂的项目划分为小的易于管理的阶段或迭代，以降低管理的复杂度。
11．实施Scrum 敏捷的项目管理方法。
在实施CMMI 2 级时可以导入Scrum 方法，Scrum 方法是敏捷项目管理方法，在该方法中定义了4个活动、3个角色、3个工作产品、2个度量元，这个方法简单易行，作为一种项目管理的解决方案，适合于CMMI 2 级的企业导入。在实施Scrum 时，需要将Scrum 的方法在组织内流程化、制度化。
12．培养QA人员，使其成为项目组的过程管理导师。
实施CMMI 2 级的企业，首先要有QA 人员，通过QA 人员监督过程标准的实施，维护公司的质量文化。QA人员首先应该是进行指导，而不仅仅是监督。在项目初期，QA对项目组的管理策略、管理过程、项目计划提供指导，帮助项目组进行合理的管理设计，在项目执行过程中进行纠偏。
13．导入版本管理工具，建立配置管理的机制，控制变更、保持完整性和、一致性。
通过导入 SVN、Git、VSS、CC 等配置工具将公司的文档、代码等管理起来，能够回溯到任何一个历史的版本，能够确保资料的完整性，这是最基本的管理要求。通过变更控制过程确保文档之间的一致性。
14．需求文档化，建立需求变更的控制机制，减少“根源性”错误，控制渐变的需求。
管理需求变更的前提是需求文档化。需求文档化看似简单，却是很多公司难以做到的。
无论需求是如何获取的，无论需求是如何描述的，需求的变更都要经过客户和开发人员的沟通，都要评估需求变更的影响范围，经过利益相关者的评审，而不是随意变更，所有的变更都应该文档化。
上述的14条实践要求项目组在项目管理中投入基本的工作量，以建立基本的项目管理方法。
（1） 需求、设计、代码、测试用例的质量比较差
● 需求描述不全面、不详细。
● 设计中错误比较多，遗漏比较多。
● 设计与实现脱节，实现人员不看设计文档。
● 代码中隐藏的缺陷比较多，代码的可维护性比较差，其他开发人员难以读懂代码。
● 测试用例数量太少，对需求、设计的覆盖率比较低。
（2） 同行评审无法快速发现问题
● 缺少同行专家参与评审。
● 同行专家没有足够的时间准备评审。
（3） 单元测试与代码走查推行不下去
● 开发人员不愿意改变工作习惯，没有意识到单元测试与代码走查的作用，不愿意做单元测试与代码走查。
● 项目的工期太紧，无法在单元测试与代码走查投入足够的工作量。
（4） 没有足够多的时间做系统测试
● 项目组留给系统测试的时间很短，系统没有经过充分的测试就交付给客户。
● 系统测试不充分，正常、异常、边界情况没有完全测试到。
（5）对组织级的体系裁剪不当
● 项目组不知道如何根据自己的实际情况裁剪体系，机械执行体系，EPG 也没有提供实际的指导。
（6）组织没有建立持续改进的体系
● 虽然有专人负责过程改进工作，但是经验教训的收集与整理、典型案例的整理、组织级度量数据的分析、新体系的部署、过程改进点的识别没有制度化、经常化，没有在组织级建立持续改进的文化。
（1）目标驱动建立过程性能基线与过程性能模型
为什么要建立过程性能模型呢？要通过过程性能模型预测目标的达成，因此应建立过程性能模型与目标之间的映射关系。为什么要建立过程过程性能基线呢？过程性能基线刻画了历史的过程性能的变动范围，目标是基于历史的过程性能确定的。我们需要基于组织的商务目标确定组织的和项目的质量与过程性能目标。基于目标确定应该建立哪些过程性能模型，应该建立哪些过程性能基线，应该收集哪些度量数据。很多组织没有建立符合 SMART 原则的目标，过程性能基线和过程性能目标也没有和目标紧密相关。
（2）过程性能模型的建立与应用
过程性能模型建立上游过程与下游过程之间的量化关系，或者建立了过程的输入与输出之间的量化关系。过程性能模型表达的不是确定型的函数关系，而是统计关系或概率关系。应该根据目标确定建立哪些过程性能模型。在现实中关于过程性能模型常见的问题如下。
● 已建立的过程性能模型缺少历史数据。
● 已有的历史数据无法确定过程性能模型的成立。
● 过程性能模型的预测效果太差，预测结果对项目组的实际活动缺少指导意义。
● 项目经理不知道如何使用过程性能模型。
（3）统计过程控制技术的使用
统计过程控制技术应用于软件领域是有争议的。有的专家认为，在软件公司中对于某一个项目而言，可以重复的活动或过程很少，可以采集的数据点很少，难以证明过程的稳定性。因此，对于统计过程控制技术在软件项目中如何应用，采用哪种具体的技术需要仔细甄别，并注意应用正确的SPC技术。
（4）预防措施的选择与制定
从哪些现象入手进行分析？如何通过现象发现本质？如何通过量化的数据证明分析结论的正确性？如何通过量化的数据证明措施的有效性？这些问题的回答需要分析问题制定预防措施的人员具备应用统计学的基本知识，熟悉方差分析、假设检验、回归分析等手段。
（5）度量数据的支持
软件企业的管理达到CMMI 4 级是管理水平的一个质变。依赖于度量数据可以实现开发过程的 SPC，可以预测过程的性能，可以控制过程目标的达成。此时的管理水平和传统硬件生产企业的管理水平近似相同，适合于重复生产型制造流程的各种手段都可以在这种创新型开发流程中得到使用。真正做到了数字说话的程度，而数字的准确性、结果的可预测性取决于管理流程的可重复性、稳定性。但是大部分企业在度量体系的构造、度量体系的执行、度量数据的分析上存在大量的问题，并导致数据没有用途、数据不准、数据无法分析出结论等现象。
很多朋友认为CMMI 4～5级难做的原因是度量做得不好，我认为那只是表象，最根本的原因还是过程不稳定，2～3级的过程就没有做好。过程不稳定，反映在数据上就不稳定， MA可以做得很好，但是MA的结果可能没有管理的参考价值，建立的模型就没有意义。比如：
我们可以很准确地度量身高、体重、年龄、每天的饭量、每天饭食里葡萄糖的含量、智商。我们希望建一个模型来预测智商，假如根据上述信息建立了一个模型：
智商=f（身高，体重，饭量，年龄，葡萄糖摄入量）。
假如这个模型有统计意义，各x和y之间有因果关系，但是将你的信息输入到这个模型中，预测出来你的智商在 60～140 之间，你认为这个模型有实际的作用吗？不用量化预测我们凭经验都能认为你的智商基本上是在这个区间内，所以这样的量化预测有啥意义？假如模型能够预测你的智商在91到103之间，那我们认为这个模型还是很有意义的。为什么呢？因为预测得比较准确，变动的范围很窄，凭经验不能预测得那么准。可惜的是，现实中很多公司的过程性能模型预测出来都是在 60～140 之间，所以模型没有实际意义。根本原因在哪里呢？不是数据不准确，不是建模的方法不对，而是过程本身就不稳定，基于不稳定过程的输出数据进行建模，进行预测，预测的结果也不稳定。
正如你是一个业余射击选手，我们建一个模型预测本次打靶你能打几环，预测的结果就难有意义，业余选手的过程不稳定，难以预测。如果你是一个职业选手，我们建一个模型预测本次打靶你能打几环，就会比较准确，职业选手的过程稳定，就好预测。
这便是高成熟度级难做的本质原因！2、3级过程稳定了，高成熟度自然好做！
20世纪90年代末产生了以Scrum 与XP为代表的敏捷方法。敏捷方法吸收了历史上各种软件开发方法中的最佳实践，如迭代、原型、用户驱动、时间箱管理等，并提出了轻量化过程的思想，以简化开发过程中的管理负担，达到简洁高效的目的。
敏捷方法与以CMMI 为代表的规范方法都是为了按时、保质地实现需求，殊途同归，目的相同，实现的方法不同。
两种方法都认为每个人都会犯错。
规范方法的管理假设是：通过遵循规范的过程可以降低犯错的概率。如何确保按过程执行了呢？需要QA进行检查。QA怎么检查呢？通过检查执行时留下的证据来验证是否遵循了过程。这些证据是否是最终用户所关注的呢？是否对最终用户有直接作用呢？未必！遵循过程的人员可能做了一些无用功，这些投入不是客户所关注的。
敏捷方法的管理假设是：开发人员是有经验、有智商的，不需要详细地告诉项目成员如何做一件事情，只要告诉项目成员做事的原则与目标，他们就可以自己根据经验判断应该如何做，应该如何实现目标，即使在过程中发生了错误，也能够及时地发现并纠正。在这种场景下，不需要保留做事的中间证据，只要检查半成品或成品的质量即可。胜任工作与互相协同的人是敏捷方法的核心基础。敏捷方法强调好的结果胜过好的过程，因而敏捷方法更注重过程的速效性。敏捷方法强调在产品本身投入更大的质量成本，而非在过程的监督与执行上。敏捷方法期望客户实时参与、开发人员实时面对面的沟通，以便于进行验证与确认。规范的方法强调文字沟通、强调记录。敏捷的方法强调口头的、面对面沟通。流行的敏捷方法大都回避了对于质量保证活动的描述，而是强调了测试，强调了实时地对文档进行评审。
如果说规范方法的管理假设是“人之初，性本恶”，敏捷方法的管理假设则是“人之初，性本善”。如果说规范方法是“中药”，敏捷方法则是“西药”。中药长于治本，重在预防，见效慢，效果持久。西药长于治标，见效快，立竿见影。
很多软件项目的管理者、开发者倾向于采用敏捷开发方法，但是不能误解敏捷方法。敏捷方法不意味着没有管理，也不意味着不写文档，不要打着敏捷的旗号行“不作为”之实，从而玷污了敏捷的名声，正如以机械的行为玷污CMMI 的名声一样。
CMMI 在实施初期往往编写了大量的文档，随着对CMMI 的理解越来越深刻，与实际的结合越来越紧密，文档会越来越精简。
敏捷方法在初期时，往往感觉很简单，但是越做就会感觉越复杂，一个很简单的活动如果想做到位，有很多注意事项。
CMMI 的实践如同白开水，没滋没味。敏捷的实践如同陈年老酒，需要慢慢品，越品越有味。
中药与西药都能治病，关键是看你得的什么病！只要对症下药，中西医结合可能更好！
Scrum 是一种敏捷的项目管理方法，该方法的名字源自于英式橄榄球争球的队形，该方法借鉴了橄榄球队成功的原则发展而来。Scrum 将软件开发团队比拟成橄榄球队：
● 有明确的最高目标；
● 熟悉开发流程中所需具备的最佳典范与技术；
● 团队具有高度自主权；
● 成员紧密地沟通合作；
● 以高度弹性解决各种挑战；
● 确保每天、每个阶段都朝向目标有明确的推进。
Scrum 将开发过程分为多个迭代，如图 2-1 所示每次迭代称为一次冲刺（Sprint），每个Sprint具有固定的时间长度，一般为2～4周。
首先，产品需求被分解成产品需求待办事项（Product Backlogs）。然后，在Sprint 计划会议（Sprint Planning Meeting）上，最重要或者是最具价值的产品需求待办事项被优先安排到下一个 Sprint 周期中。同时，在 Sprint 计划会上，将会预先估计所有已经分配到 Sprint周期中的产品需求待办事项的工作量，并对每个条目进行设计和任务分配。在Sprint开发过程中，开发团队每天都会进行一次简短的Scrum 会议（Daily Scrum Meeting）。会议上，每个团队成员需要汇报各自的进展情况，同时提出目前遇到的各种障碍。每个Sprint周期结束后，都会有一个可以被使用的系统交付给客户，并进行 Sprint 评审会议（Sprint Review Meeting）。评审会上，开发团队将会向客户或最终用户演示新的系统功能。同时，客户会提出意见以及一些需求变化。这些可以以新的产品需求待办事项的形式保留下来，划分优先级，并在随后的Sprint周期中得以实现。Sprint回顾会随后会总结上次Sprint周期中有哪些不足需要改进，有哪些方面值得肯定。最后整个过程将从头开始，开始一个新的Sprint计划会议。
在Scrum 方法中将项目的利益相关者分成两大类：Pigs角色与Chickens角色。Pigs即为项目组的实际参与人员，Chickens为项目组的外部人员，包括经理、最终用户等。这种分类的方法源自于一个关于猪和鸡合伙开餐馆的管理寓言（如图2-2所示）：一天，一头猪和一只鸡相遇了，鸡对猪说：“嗨，我们合伙开一家餐馆怎么样？”猪说：“好主意啊，那你准备给餐馆起什么名字呢？”鸡想了想说：“叫‘火腿和鸡蛋’怎么样？”“那可不行”，猪说：“我把自己全搭进去了，而你只是参与而已。”Pigs在Scrum 中细分为三个角色：Scrum Master、Product Owner、Team，这三个对等地位的角色构成一个平衡的铁三角，推动整个项目的进展。
1．Scrum Master
Scrum Master 不是项目经理，他没有分配任务的权力，没有考核的权力，没有下命令的权力，他在项目组承担了如下细分角色。
（1） 会议主持人
他负责主持四个主要的会议：策划会议、每日站立会议、迭代评审会议、迭代回顾会议。
（2）牧羊犬
他负责屏蔽项目组外部的干扰。
（3）雷锋
他给Product Owner、Team提供帮助，帮助Product Owner确定需求、排定优先级，帮助Team做估算、分解任务、完成任务。
（4）外交官
当项目组外部有人不理解项目组的工作时，他负责去解释说明，负责对外发布项目组的信息。
（5）教练
他指导项目成员按照Scrum 的原则、方法做事情，当出现偏差时，他去纠正，可以说他既是精神教父，也是警察（QA）。如果有项目成员不熟悉Scrum 的方法，他要去提供相关的培训。
（6）清道夫
他负责排除在项目进展中遇到的各种障碍，如果他没有能力或没有资源他可以协调项目组的其他成员一起来排除障碍。
Scrum Master 并非固定地由一个人承担，在一个团队中，有能力的、熟悉Scrum 的成员都可以担当Scrum Master。
敏捷方法看上去简单，实施起来比较难。敏捷方法的实践少，但是要求每条实践必须做到位，做扎实。真要做到位就要求Scrum Master必须很熟悉Scrum 的基本原则与基本思想。简单的站立会议，有些Scrum Master就不能控制局面，一提到问题就讨论如何解决问题。可以写一个站立会议的检查单，在开站立会议前的 1 分钟，把站立会议的要点重复一遍，慢慢地把这些思想渗透到每个人的骨髓中。
所以，对于Scrum Master而言要培养其基本的技能：如何主持会议？不仅仅要理解Scrum 的要求，而且要具备这些技能。公司里熟悉Scrum 方法的人可以作为Scrum Master 的导师，旁观Scrum Master的活动，然后指出其缺点，在实践中指导提升其基本技能。项目成员也要重视每次迭代结束时的回顾活动，通过自我总结提高团队的整体能力。Scrum Master并非固定的，是可以变化的，通过这种方式也可以发现团队中适合做Scrum Master的人。有的团队每天站立会议的主持人是变化的，大家轮流主持，这也是一种很好的尝试，通过这种方法可以发现人才。
挑选什么样的人做 Scrum Master？要选组织能力强的人，而不一定是选择技术能力强的人，Scrum Master 的作用是要发挥整个团队的能力，激发大家的能力。不是Scrum Master 有多强，而是整个团队有多强！
2．Product Owner
Product Owner是产品的负责人，或者是需求的负责人， 他在项目组承担了如下细分角色。
（1）领域专家
他是需求方面的专家，熟悉需求。他知道客户、最终用户以及其他利益相关者对项目的真正需求是什么。他负责编写用户需求，维护用户需求。
（2）需求决策人
哪个需求重要，哪个需求不重要，需求的优先级如何排列，在某次发布中要发布哪些需求都由他来拍板。他负责平衡需求、进度与资源的关系。
（3）需求讲师
他负责在项目进展过程中给项目组的其他成员讲解需求的含义，对需求进行答疑。
（4）测试员
他负责编写每个需求的验收标准、功能测试用例。
（5）验收人
当项目成员完成某个需求后，是Product Owner进行功能测试和验收，他认可后才能认为某个需求完成了。
Product Owner可以来自于用户、客户、销售部、产品策划部门，或者来自于开发部门的需求分析人员。无论是来自哪里，都需要满足如下的要求。
Collaborative：易于协作、易于沟通。
Representative：有代表性的，能代表用户、客户、市场的利益。
Authorized：有授权，得到了用户、客户、市场等的授权，有对需求的决策权。
Committed：尽责，能够认真地、尽职尽责地工作。
Knowledgeable：在行，明白，熟悉需求。
以上的5 项要求可以简写为CRACK，这是我们的理想，在现实中找这样的Product Owner有一定的难度。
Product Owner是一个角色，并非指是一个人，可以是多个人。但是如果是多个人，这多个人要协调一致，对需求的理解与解释是一致的。
根据我观察在多家软件公司中实施Scrum 方法的成功与失败经验，PO这个角色是最容易失败的角色。熟悉需求而又有决策权的人往往很忙，不能全程参与开发，因而无法保证与项目组的沟通时间，无法落实其测试与验收的职责。如果请多个人分担此角色，则又存在与真正的PO之间保持沟通一致的问题。
3．团队成员
Team Member是技术的责任人，他们负责实现这个系统，他们是自我管理的，不需要外部的管理者来管理他们。在一个Scrum 团队中，一般是整个团队（包含Product Owner、Scrum Master）不超过10人，Team应该是一专多能的全才型选手，而不是那种专业化分工的团队，这样才能保证团队的效率比较高，也易于沟通。团队成员都应该是专职人员，不能同时兼职做多个项目。Team承担了如下的细分角色。
（1）设计人员
对系统进行简单设计，并进行设计的讨论。
（2）实现人员
负责实现整个系统，并对系统执行单元测试，构建整个系统。
（3）自我管理人员
大家一起来估算，一起来选择任务，一起来跟踪任务进展。
Product Owner定义了项目做什么，Scrum Master 从过程上保证了如何实现项目，Team从技术上保证了如何实现项目。
在Scrum 方法中明确要求了3个文档。
（1）产品待办事项列表
（2）迭代待办事项列表
（3）燃尽图
1．Product Backlog
Product Backlog 中列举了本项目应该实现的需求，需求采用了用户故事的方式进行描述。用户故事是一句简短地采用用户熟悉的术语表达的需求，是用户讲给开发人员的故事，不是开发人员讲给用户的故事。既然是故事，就要有人讲，谁讲呢，是Product Owner来讲。每次讲时可能都有细节的不同，就要有变化，但是万变不离其宗，所以故事本身是有一定弹性的。故事可以有标准的格式，笔者称之为三段论式故事。哪三段呢？
（1）用户角色
（2）需要的功能
（3）目的
比如，有这样一个故事：
作为一个家庭主妇，我需要一个30平米的餐厅，以便于我可以招待10位朋友来用餐。
用户角色是家庭主妇，30 平米的餐厅是功能需求，招待 10 位朋友用餐是为什么需要这个功能。千万不要小看这个三段论式的故事，需要仔细琢磨每一段的作用。用户角色表明了是谁使用这个功能，如果一个功能没有明确的使用者，是否可以删除呢？如果一个用户角色不重要，是否这个需求的优先级比较低呢？目的说明了为什么需要这个功能，这个功能解决了什么问题，如果一个功能没有明确的目的，是否可以删除呢？如果目的不太关键，这个需求是否可以优先级比较低呢？
优先级？没错，我多次提到了优先级，需求一定要分优先级！谁来划分需求的优先级？Product Owner！如何划分优先级？根据商业价值！根据对客户、对最终用户的商业价值来划分优先级。如何区分商业价值的大小呢？比如提问如果不实现此需求，如果推迟实现此需求客户是否会不满意？是哪类人不满意？不满意到什么程度？一个称职的Product Owner 可以凭经验划分出需求的优先级。
是否仅仅描述了这样一句话就充分了呢？其实还有第四段，即用户故事的验收标准，或者称为用户故事的测试要点，这也是由Product Owner完成的。Product Owner可以先完成前三段，在和Team Member 的沟通过程中逐步丰富完善验收标准。对于前面我们提到的那个故事，如果你实现了这样一个餐厅，比如是一个2米宽、15米长的餐厅，那位家庭主妇会如何想？哈哈，如果她心理健康的话，估计她立马让你跳楼！如果她心理不健康，她会跳楼的。当然在敏捷方法中不会出现这种现象，在开发过程中，Product Owner会与你随时沟通交流需求，在沟通中Product Owner 还传达了这样的信息：
（1）我希望这个餐厅是5米×6米；
（2）我希望这个餐厅灯光明亮；
（3）我希望这个餐厅靠近厨房，我不希望超过1 0步；
（4） ......
这就是验收标准！也可以换一种角度，从如何验收的角度来描述：
（1）我会量量这个房间是否是5米×6米。
（2）我会测测如果在这个房间里白天打扑克，不开灯的话，能否看到扑克的花色和点数；
（3）我会测测从厨房到餐厅需要走几步；
（4）......
如果一个故事提不出来验收标准怎么办呢？不实现它，晚实现它，直到明确了验收标准。
到目前为止我们实际讲了在Product Backlog 中包含了5 段：
Product Backlog = 需求 + 优先级
= 用户故事 + 验收标准 + 优先级
= 用户角色 + 功能 + 目的 + 验收标准+优先级
也有将验收标准单列出来的，但我认为验收标准应该是需求的一部分，只不过换了一种描述需求的方式而已，所以还是作为Product Backlog 的一部分比较好吧。
前面我一直在提“功能”二字，没有提非功能的需求，如果有非功能的需求怎么办？两种处理办法，一是如果能明确到某个故事，就描述在故事的验收标准中；二是写一个“技术故事”，单列出来，提醒开发人员注意这些故事，这个故事未必是 Product Owner提出的。
对于用户故事我们希望能够达到如下的理想：
（1）独立性。尽可能避免故事之间存在依赖关系，故事之间存在依赖关系会造成划分优先级的困难，在安排开发顺序时需要考虑故事之间的依赖关系。
（2）可协商性。故事是可协商的，故事是有弹性的，故事是需要讲的，不是必须实现的书面合同或者需求。
（3）对用户或者客户有价值。确保每个故事对客户或用户有价值的最好方式是让用户编写故事。
（4）可预测性。开发者应该能够预测（至少大致猜测）故事的规模，以及编码实现所需要的时间。
（5）短小精悍。一个故事在一个迭代周期内一定是可以实现的，而我们提倡短周期迭代。
（6）可测试性。所编写的故事必须是可测试的，能够定义出验收标准。
注意，这是理想！
Product Backlog在项目进展过程中是会发生变化，只有Product Owner有权来修改此文档。你可以用 Excel 文件来描述它，也可以采用一些敏捷项目管理的工具来帮助你维护，或者使用一些缺陷的跟踪工具如JIRA之类的。最直观、最朴素的办法是采用即时贴，直接贴在办公室的白板上，让大家都能随时看到。
2．Sprint Backlog
Sprint Backlog 就是任务列表，如果映射到传统的项目管理理论中就是 WBS （Work Breakdown Structure），而且是典型的采用面向交付物的任务分解方法得到的WBS 。注意，在PMBOK中，WBS 分解到工作包级，此处的WBS 是指分解到具体的活动级。
比如有一个Product Backlog条目为：
作为系统的合法用户，可以通过录入账号和密码登录到系统中。
为了实现此需求，Team Member 识别出任务，进行了工作量的估计，进行了任务的认领，其结果记录表2-1所示。
此表格是由开发人员基于经验采用头脑风暴的方法大家一起分解得到的，里面列举的任务是为了实现该用户故事必须做的事情，按照简化的原则，可做可不做的任务则删除之。估计的工作量是由任务责任人自己估算的，任务的工作量合计应该不超过用户故事估算的工作量。如果任务拆分后发现工作量的合计远远大于用户故事估计的工作量，则可能需要对用户故事的工作量估算值进行修订。
Product Owner 负责基于商业价值挑选某次交付中应该包含的用户故事，而开发人员负责基于开发的风险、用户故事之间的依赖关系等，挑选在某次迭代中要实现的用户故事。
Sprint Backlog 可以采用Excel、白板或者敏捷的项目管理工具进行维护。
3．燃烬图
Burn Down Chart 翻译为燃烬图（或燃烧图），很形象，是 Scrum 中展示项目进展的一个指示器。我一直认为用户故事、每日站立会议、燃烬图、Sprint Review、Sprint Retrospective真是越琢磨越有味道的好东西，也因此很喜欢 Scrum 这种方法，这些实践简单有效，非常经典。
燃烬图的样例如图2-4所示。
横坐标为工作日期，纵坐标估计剩余的工作量，每个点代表了在那一天估计剩余的工作量，通过折线依次连接起所有的点形成估计剩余工作量的趋势线。另外还有一条控制线，为最初的估计工作量到结束日期的连线，一般用不同的颜色画上边的两根线。
对此图的研判规则如下。
（1）如果趋势线在控制线以下，说明进展顺利，提前完工的概率比较大；
（2）如果趋势线在控制线以上，说明延期的概率比较大，此时需要关注进度了。
注意，趋势线并非一直下行，也有可能上行，即发生了错误的估计或遗漏的任务时，估计剩余的工作量也有可能在某天上升了。
每天开完15分钟站立会议后，由Scrum Master 根据进展更新燃烬图。第1个点是项目最初的工作量估计值，第2个点是最初的估计工作量减去第1天已完成任务的工作量，依次类推计算后续的点。任务完成的准则如下。
（1）开发人员检测：所有的单元测试用例都通过了。
（2）Product Owner 检测：通过了所有的功能测试。
燃烬图最好是张贴在白板上，让每个项目成员抬头就能看见，这样给大家一个明确的视觉效果，每个人随时都能看到我们离目标有多远。
燃烬图可以每天画，表示完成某个迭代的进展趋势，也可以在某次迭代结束的时候画，表示完成整个项目的进展趋势，此时横坐标就是迭代的顺序号。
燃烬图和传统项目管理理论中的挣值图比较起来更加简单、直观，这种设计深得管理的精髓！度量的精髓！真是让人佩服！
在敏捷方法中提倡看板管理，将这 3个文档都贴在一个白板上，让项目组的所有成员都能一目了然。
案例：项目管理看板
图2-5为2013年6月份笔者摄于北京某家客户处。
在Scrum 方法中定义了4种会议活动。
（1）Sprint Planning。
（2）Daily Meeting。
（3）Sprint Review。
（4）Sprint Retrospective。
除去开发活动外，这4种会议构成了Scrum 方法的核心活动。这4种会议的要点如表2-2所示。
案例：敏捷迭代总结
2012 年杭州某公司的一个项目组采用敏捷的方法完成了一个项目，在此过程中，每次迭代结束后，项目组的每个成员都总结了本次迭代的经验教训，这些总结很有代表性。我汇总了这些经验教训，点评如下。
每日站立会议是Scrum 方法中的一条关键实践，看似很简单的一个活动，其实内涵丰富，站立会议通过每天面对面的沟通，可以：
（1）快速同步进展，让项目组内部的员工互相了解彼此的进展，从而了解本项目的整体进展。
（2）给每个人一种精神压力，信守承诺。这是一种面对面的精神压力，直面项目进展。
（3）培养团队的文化，让每个人意识到：我不是一个人在战斗，我们是一个团队。
为了保证每日站立会议的质量，需要注意如下的要点。
1．任务的分配与领用
（1）任务的责任人要明确。
（2）任务的颗粒度小于2天。
（3）如果有的任务颗粒度实在无法拆分到2天以内，则需要设置中间的检查点。
（4）任务的完成时间要明确。
（5）任务的完成标准要明确。
（6）任务识别要尽可能完备，不要在过程中增加很多遗漏的任务。在识别任务时，团队中的各个角色都要参与，要充分讨论。
（7）增加、修改的任务要增加小贴纸，明确地在看板中标识出来，这些任务可以采用不同颜色的贴纸标识。
（8）高层经理不要越级直接给团队成员下达任务。
2．任务的完工检查
（1）不能只靠责任人汇报说完成了就认为任务已经完成了，应该有检查。如果是编码，则要通过规范符合性检查、工具静态检查、人工代码走查或单元测试，并通过Product Owner的确认。如果是编写文档，则应该通过了评审，如果是预研，则应该展示预研的结果。
（2）要区分任务的完成与需求的完成。需求的完成需要多个任务完成的支持，不但要跟踪任务的进展，也要跟踪需求的进展。如果不是采用迭代模型，而是采用瀑布模型，可以定义一个任务进展的内部准则。比如对于一个需求，如果需求定义完成，则认为这个需求完成了10%；如果详细设计完成，则认为这个需求完成了30%；如果代码完成，则认为这个需求完成了50%；如果单元测试通过，则认为这个需求完成了70%；如果系统测试完成，则这个需求认为完成了100%。
3．进展的跟踪
（1）采用燃烬图标识每个小组的进展，每天站立会议完成后更新燃烬图；
（2）采用燃烬图标识整个产品开发团队的进展，可以每天或每2天更新燃烬图。
（3）每个小组、整个产品的进展都要及时跟踪。不能关注了局部，忽略了整体。
4．站立会议
（1）每天定时、定地开站立会议，不需要事先通知。
（2）在站立会议上每个人当且仅当回答以下3个问题：
昨天完成了什么？
有什么难题需要别人帮助解决？
今天做什么？
（3）在汇报每个人的进展时，不需要汇报是如何做的，只汇报进展；
（4）需要别人帮助的问题在会后单独讨论。
5．小组长
（1）主持会议，确保每位组员发言时不能跑题。
（2）可以点评、提醒每个人的工作，但是一定要简短点评。
（3）如果对总体情况进行总结，一定要简短。
6．会议纪律
（1）不能迟到。如果迟到就惩罚之。
（2）只有一个声音在发言。不能一个人在发言，其他人在开小会。
（3）非本小组的成员，可以旁观，不需要发言。
（4）不能中途有人退席。有的人汇报完自己的进展后就退席是不允许的。
7．物理设施
（1）站立会议时一般要有白板，白板上粘贴的是本项目组的任务状态：未开始的任务，进行中的任务，中断的任务，完成的任务。其实也有一些敏捷的工具，可以电子化 Sprint Backlog，但是还是不如物理的白板更有视觉的冲击力。
（2）白板的面积要大，如果所有的任务不能在白板上贴下，则可以只贴本次迭代的或最近一段时间的，比如2周的。
（3）如果白板面积不够，可以不用贴纸，手写任务。
（4）贴纸容易掉，可以用小磁条或不干胶粘在白板上。
（5）限于办公环境，每个小组的站立会议可以错开时间开。
8．其他注意事项
（1）一定要当面开会，不能邮件替代站立会议。
（2）一定要每天开会，每天跟踪项目的进展。
（3）不需要整理会议纪要，除非有其他必须的目的。
案例：站立会议
2010年深圳某客户在公司内推广站立会议，2010年4月份笔者曾经到这家客户观察过 1个大产品的 10 多个项目小组执行站立会议的情况，并将结果与体会记录整理成了一篇博文：《每日站立会议的10个成功要点》。2013年8月23日上午（深圳，滂沱大雨，雨声如鼓）故地重游，我又观察了该公司一个项目的站立会议，记录如下。
（1）某项目组站立会议，早上9点13分开始，9点26分结束，费时13分钟。
（2）人员陆续而来，9点13分开始后，9点15分、9点20分、9点21分分别又来了3个成员，累计13个人参与了该会议。
（3）主持人是打开一个Excel格式的计划，对此计划进行跟踪，计划中包含的列有：任务、任务描述、任务跟踪记录、计划开始日期、计划结束日期、任务状态、责任人。
（4）主持人采用轮询的方式跟踪任务进展，边询问，边记录到Excel计划的任务跟踪记录列。
（5）主持人了解每个人的进展后，进行了简单点评，有问题则给出了指导意见，项目组其他成员也给出了一些建议，所有的问题当场都给了结论，需要尝试的，让项目组成员去尝试了。
（6）项目组成员彼此之间有接口的，互相询问、沟通了接口的进展情况。
（7）在某个成员汇报工作进展的时候，有的成员没有专心听，而是和其他成员开小会，在讨论自己感兴趣的话题，主持人没有制止。
（8）有的项目成员在整个过程中游离在团队之外，不关心别人的进展，始终在玩自己的手机。
（9）在跟踪任务进展过程中，经过简短讨论后，主持人随时增加了一些必须的任务，并责任到人了。
（10）没有画燃烬图。
（11）未按时完工的任务大都是需要其他项目组配合完成的任务。
总评：一项简单的措施坚持下来不容易，坚持做好更不容易。
极限编程（Extreme Programming，简称XP）是一种敏捷的软件开发方法。在迭代生命周期模型中贯穿了12条实践。
（1）现场客户：此实践继承自快速应用开发（RAD）方法的用户驱动的开发，要求客户、用户或其代表全程参与开发的过程，和开发人员一起工作，其职责为：
需求定义、需求讲解、需求优先级制定、需求验收标准定义、功能测试、功能验收。
此实践中的客户和Scrum 方法中的Product Owner 的职责类似。
（2）策划游戏：在 XP 中项目计划划分为 2个层次：发布计划与迭代计划。在定义计划时，要进行以下4次的平衡。
① 项目的估算总工作量（需求工作量）与项目组成员可以提供的工作量（开发能力）的平衡。
② 某次发布的需求工作量与在本次发布内项目组成员开发能力的平衡。
③ 某次迭代的需求工作量与本次迭代的项目组成员开发能力的平衡。
④ 某次迭代内某个人的任务工作量与其开发能力的平衡。
估算工作量时可以采用策划扑克法或其他敏捷的估算方法。
（3）小版本发布：频繁发布软件版本供用户、客户进行确认，以尽早取得客户的反馈。
（4）平稳的开发速度：两层含义，一是每周工作40小时，不加班，让开发人员高效地、愉快地工作。二是避免快而脏的开发模式，在开发过程中保证质量的投入，不要到项目的后期集中改错。
案例：平稳的开发速度
我的一位同事采用敏捷方法做软件开发很多年，他曾经有过这样一个经历：有一次项目组新加入了一个员工。这位新员工以前没有敏捷开发的经验，他对项目组其他成员坚持做单元测试、持续集成很不以为然，认为大家的开发速度比他慢很多。在迭代结束联调时，其他人的代码很快就能集成并测试通过，而他的代码却问题很多，别人都下班回家了，唯独他需要留下来加班修改错误，经过2次迭代后，此人终于意识到了敏捷实践的优点。
（5）系统隐喻：对于系统的架构设计、概要设计，采用类比或比喻的方式进行设计，便于项目成员之间互相快速、通俗地沟通系统的设计思想。系统隐喻对于设计人员的水平要求比较高，因为将系统抽象的设计思想采用通俗的类比刻画出来需要较高的设计水平。
（6）简单设计：不为未来不确定的变化进行设计，不进行过度设计。
（7）结对编程：两人共用一台计算机工作，两人一起协商进行编程，结对不是固定的，每天调整结对的人员。很多软件公司对此实践则进行了变通执行，如：
① 每天早晨进行半小时的结对设计，每天下午下班之前进行一小时的结对代码走查。
② 执行结对修改。当修改错误或需求变更时才进行结对，其他时间不结对。
（8）编码规范：定义项目组的编码标准和规范，要求成员一致地执行，可以采用工具进行编码规范的静态检查。
（9）测试驱动的开发：在完成需求后即进行验收标准的编写，在写产品代码之前优先进行单元测试代码的编写，在编码过程中可以随时进行单元测试。
（10）持续集成：代码通过单元测试后可以与其他已经完成的代码进行编译链接，然后执行静态检查、单元测试等。此工作是实时进行或者定期进行，可以在持续集成的服务器中设置集成的策略。
（11）重构：重构是在不改变代码的外部行为的前提下，优化内部的实现方法。当修改错误时，当需求变更时，当代码评审时，可以对代码的坏味道进行重构。
（12）代码集体所有：项目组的所有成员对所有的代码共同负责，当发现代码的改进点时谁都有权利、有义务进行代码的优化。
这12条实践是相辅相成的，必须一起采纳才可以称得上是极限编程方法，不能仅仅采取了其中几条措施就称为极限编程了。在这12条实践中，后6条实践是紧紧围绕编码活动的，系统隐喻与简单设计是针对设计活动而言，在客户现场实践中包括了需求开发与功能测试、验收测试的活动。因此，我们说XP是侧重于工程活动的一种敏捷开发方法，75%的实践都是工程活动。
在实践中通常是将XP方法与Scrum 方法配合在一起使用，一种方法覆盖了工程活动，一种方法覆盖了管理活动，二者互补。
时间箱管理是敏捷方法中的一条实践，其含义是项目中某些活动的完成时间必须在规定的时间内完成。该实践有助于提高整个项目的工作效率，避免帕金森现象。
在敏捷方法里，时间箱管理的具体体现以下几点。
（1） 每次迭代必须在固定的时间内完成，比如 2 周或 1个月。每次迭代必须交付一个质量得到充分检验的、可以运行的软件版本。如果有些需求不能在某次迭代内完成，则推迟到下一个迭代中完成。
（2） 项目的策划会议必须在 4个小时内完成，某次迭代的策划会议必须在 4个小时内完成。
（3） 每天15 分钟的站立会议。
（4） 在每日站立会议上发现的问题要在1 天内解决。
（5） 1个小时内做出决策。需要项目的负责人或教练对于管理的问题在 1 小时内做出决策，不能拖延决策。
（6） 每次迭代结束后的评审会议必须在 2个小时内结束。在迭代评审会议上主要是示范本次迭代完成的产品或产品构件，获得客户及相关人员的反馈。
（7） 每次迭代结束后的总结会议必须在2个小时内结束，通常是在30 分钟内结束。主要是总结本次迭代的经验教训，下次迭代能够做得更好。
上述规则中的具体时间数字并非是绝对的，每个项目组可以根据自己的实际情况自行定义。
策划扑克法是估算软件规模与工作量的一种敏捷方法。该方法的规模计量单位是故事点（Story Points），故事点只是一个计量单位的名称而已，你也可以给它命名为其他名字。故事点其实不仅仅是对规模的度量，也包括了对需求复杂度等其他因素的度量。故事点并非业界统一的一个度量单位，不像度量长度的单位：米。大家都知道1米有多长，你说的1米和他说的 1 米是等长的。故事点仅对本项目具有近似相等的规模，不同的项目所定义的故事点很可能是不等的。
策划扑克法参与的人员包括了所有开发人员：程序员、测试人员、数据库工程师、分析师、用户交互设计人员等等，在敏捷项目中一般不超过10人。产品负责人参与策划扑克法但是并不作为估算专家，如图2-6所示。
策划扑克法的步骤如下。
（1）每位参与估算的开发人员发放一副估算扑克，扑克上的数字标为近似的斐波那契序列：1，2，3，5，8，13，20，40。
（2）选择一个比较小的用户故事，确定其故事点，将该故事作为基准故事，作为参照物。
（3）从其他故事中任意选择一个用户故事。
（4）主持人朗读描述。主持人通常是产品负责人或分析师，当然也可以是其他任何人，产品负责人回答估算者提出的任何问题，大家讨论用户故事。
（5）每个估算者对该用户故事与基准故事进行比较，选择一个代表其估算故事点的牌，在主持人号令出牌前每个人的牌面不能被其他人看到，然后大家同时出牌，每个人都可以看到其他人打出的牌。
（6）主持人判断估算结果是否比较接近。如果接近则接受估算结果，转向步骤（3）选择下一个故事，直至所有的用户故事都估算完毕，否则转向步骤（7）。估算结果是否比较接近的规则，项目组可以自行定义。
（7）如果结果差异比较大，请估算值最大及最小的估算者进行解释，大家讨论，时间限定为不超过2分钟。如果大家同意，也可以对该用户故事进行更细的拆分。
（8）转向步骤（5），一般很少有超过3轮才收敛的现象。
在该方法中，参与的人员对于被估算的需求进行了充分的沟通，并综合了程序员、测试人员等各个角色的专家观点，融专家法、类比法、分解法为一体，可以快速、可信、有趣地进行估算。
在估算完故事点后，可以凭经验估算一个故事点的开发工作量，从而得到所有的用户故事的工作量。也可以进行试验，试着开发一个用户故事，度量花费的工作量，得到开发效率，即在本项目中一个故事点需要花费多少工时，再去估算所有故事的工作量。
在敏捷方法中，要求度量的数据少之又少，可谓简单实用。
（1）规模
故事点：用以估算工作量、度量开发效率。
（2）工作量
计划的工作量：用以排定项目计划。
剩余任务的计划工作量：用以跟踪项目进展。
（3）效率
开发速度：每次迭代完成的需求的规模（如故事点），用以估算项目需要的迭代次数。
其他度量元根据项目组的实际情况，可以由项目组自己定义。
2012年12月8日晚，笔者和两位朋友聊天，他们从国外的大企业工作了多年，回国创业开办了一家软件公司，按照敏捷的方法进行了2年的软件开发。在实践中有些具体的问题，大家在一起进行了沟通讨论，从敏捷方法的文化到敏捷方法的具体实践的做法，沟通了大概3.5小时，第1个小时的沟通笔者忘记录音，后边的沟通笔者做了录音。根据回忆和录音，将讨论的问题整理如下，属于“非典型企业的典型问题”。
在实施敏捷方法时，遇到了“形似而神不似”的问题，敏捷方法的“神”究竟是什么？
我总结为两条：质量与沟通。很多企业是没有把握住这 2条，而导致敏捷的失败。先说质量。
（1）在敏捷方法中，“多快好省”四个字进行平衡时，首先是要固定质量，在固定质量投入的前提下，再去平衡进度、需求和投入。在剩下的这三个要素中，往往先裁剪需求。
（2）质量的含义包含了内部质量和外部质量。外部质量是用户可以感知的，是对需求的符合性。内部质量是开发人员感知的，决定了软件的易维护性。内部质量决定了外部质量，敏捷方法是二者并重的，并非仅仅关注了外部质量，但传统的方法往往仅关注外部质量。
（3）质量的管理首先关注质量的投入。质量的投入表现在质量管理的活动上：测试驱动的开发、静态检查工具的使用、结对编程、代码走查等。没有质量的投入就没有质量的产出。敏捷方法对于质量应该如何投入给出了具体的实践，而不仅是停留在概念上。
（4）提升软件开发效率的最有效方法是减少返工，一次做对是提升效率的最有效方法，因此就要预防错误。预防错误的方法包括和开发人员对需求的理解达成一致，结对设计，测试驱动的开发，结对编程等。
再说沟通。
（1）敏捷方法为什么可以少写文档，因为它通过口头交流的方式替代了文档交流。有哪些具体的口头交流的手段呢？在策划会议上项目成员对用户故事做了沟通和讨论，开发人员做了结对编程，每天开了站立会议，用户代表或产品负责人在过程中实时地做功能测试等等，这些手段都保证了在文档比较少的前提下，可以保证产品的方向、产品的具体功能不会偏离用户需求。
（2）在敏捷方法中沟通了什么？首先是需求，其次是设计，再次是进展，最后是经验教训。在需求方面沟通了对需求的理解，需求是否实现了，需求的沟通是重中之重。用户故事是用来讲的，是用户讲给开发人员听的，开发人员是否实现了听来的故事，是需要讲故事的人进行确认与验收的。对于需求、对于进展都要尽早地报告坏消息：如需求理解错了；需求无法实现；需求实现错了；需求没有按时实现。
在敏捷宣言中讲到了4条宣言，在XP方法中有4个价值观，在这些描述中笔者体会最关键的还是这2条。
每个开发人员要将以上的 2条落实到他们每个人的细节行动上，大家需要不断反思：做这件事情你是否保证了质量？是否通过沟通减少了错误的发生？
团队文化就是互补的文化，就是互相配合、互相帮助的文化。在中国的教育体系中，从小学到大学都没有培养团队协同的思想与理念。每个人的单兵作战能力还可以，但是大家不知道如何形成一个团队，从项目经理到团队的成员都缺少这方面的思想认识或具体的做法。团队文化包括了积极主动的文化、互相协调的文化。比如在开站立会议时，就有人只是关注自己的工作，不关注团队中其他人的工作，你的是你的，我的是我的，而不是我们的。也有的人认为我的就是我们的，是我们的那就不是我的，不是我的所以我也就没有责任。
如何形成团队文化？
（1）在一个公司中，企业的文化首先是老板的文化，老板的一言一行影响了员工。我们可以比较一下联想、华为、富士康等企业的文化，你就可以发现这个结论。如果一个团队没有形成一个良好的文化，首先领导就要反思，是否自己的言行出了问题。
（2）小团队容易形成团队文化，而大团队形成团队文化就比较困难。小团队靠人治，大团队靠法治。敏捷方法中提倡小团队，其中一个好处，就是容易形成这种互相配合、互相协同的文化。
（3）文化体现在细节，文化需要不断地进行重复强化。要从每个细节活动中去反思是否符合团队的文化。
（4）文化的载体有 2个：规章制度与人。通过企业的规章制度体现企业的文化，通过以老带新来传承文化。
有些比较复杂的任务、不够清晰的任务，比如编写文档等是否适合采用敏捷方法来管理？在 XP 中有结对编程，适用到对客户的支持时可以借鉴结对的思想。如何保证质量？如何通过沟通减少中间记录？对于文档的编写我们可能不使用结对编写文档，但是我们是否可以对这个文档进行评审呢？在写文档之前我们是否对文档做了结构的设计呢，就像我们做系统隐喻一样呢？是否做了方案的讨论，我们都可以借鉴敏捷的实践，你也可以把它作为一个用户故事，一个用户故事就是一个需求而已。
只要明白了敏捷的思想，你只要类比就可以了。比如用户故事的四段论，看上去很简单，谁要这个功能？什么功能？为什么要这个功能？有了这个功能如何验收？不能假想功能，做了功能没有人使用，这个功能要解决什么问题？目的是否明确？通过验收的标准进一步澄清目的。我们把这个思想类比到日常工作中，我们给一位员工下达一个任务时，常常发生对方没有按我们的要求完成任务，需要进行返工，尤其是布置任务的人比较繁忙时，往往是简单说了一句，布置一下任务就放手让别人去做事情了。如果我们借鉴用户故事的方法，我们可以这样给其他人安排任务，我想让你做什么事情，为什么要做这件事，你做完了以后，我会检查哪几点，这样就可以减少很多误解和返工。看上去用户故事是很简单的一条实践，但是你需要仔细琢磨这条实践解决了什么问题，它背后的道理是什么。
欲速则不达。平稳的开发速度如何理解？如何提升软件开发的效率？不返工就能提高速度吗？如何不返工？在做之前做了充分的设计，传统方法是写文档和评审，敏捷方法是讨论，是三个臭皮匠顶一个诸葛亮。
每次迭代结束后，大家做回顾，提升团队的能力。每次迭代结束后团队的整体能力应该有长进，开发的速度越来越快，越来越稳定，是个正反馈的自适应过程。
要通过成功走向成功来激励员工，每次迭代要能成功结束，而不是每次迭代都要会失败。每次迭代结束后要调整下一次迭代的开发速度，确保下一次迭代是切实可行的。
每个失败的项目都可以找这个借口：项目周期短、需求变化快、人员有限。
需求、工期是由客户确定的。作为客户来讲，他不可能去合理地评价给定的需求是否可以在某个时间内完成，至于投入多少人则更是开发方自己的问题。
开发方对客户做出了承诺就要兑现承诺，否则就不要承诺，既然承诺了，就没有理由再去抱怨工期短、需求变化快。开发方必须接受这个现实，认可这个现实。
CMMI 是应对这种局面的一种解决方案，CMMI 是全球最大的软件客户—美国国防部资助开发的模型，是甲方驱动的模型，是得到甲方认可的方法。敏捷方法呢？敏捷方法如果能够真正推行开来，同样也需要客户的认可。
敏捷方法的推广应该始于客户，始于甲方：
（1）需要甲方认可质量第一，功能多少与工期第二。
（2）需要甲方对需求划分优先级。
（3）需要甲方认可分批地、阶段性地交付系统。
（4）需要甲方参与阶段性确认或者全权委托代表进行阶段性确认。
（5）需要甲方在开发过程中安排熟悉需求、有需求决策权的专家参与项目，与项目组保持实时沟通。
否则，不具备成功的基础，则敏捷的开发管理仍然会失败。
Barry Boehm 于 1983 年提出了软件工程的七原则（Seven Basic Principles of Software Engineering），这是很经典的七个原则，有人将题目翻译为软件工程的七个基本原理，其实， principles在此处还是翻译为原则更为准确。依据原文笔者对于各原则的理解如下。
原则一：使用分阶段的生命周期计划管理（Manage Using a Phased Life-cycle Plan）
（1）一定要有项目计划。
（2）项目要划分生命周期阶段，每个阶段都要有计划。
（3）计划要分层或分阶段逐步细化。
（4）要使用项目计划管理项目，不能弃之不用。
原则二：执行持续确认（Perform Continuous Validation）
（1）尽早发现错误。大部分缺陷是编码之前注入的，缺陷越早修复，成本越低。
（2）尽早发现错误的措施，包括：深入评审；设计阶段编写用户手册、使用手册、数据准备手册；原型；模拟；自动化的检测工具；设计审查与走查；等等。
原则三：维护规范的产品控制（Maintain Disciplined Product Control）
执行配置管理，确保工作产品之间的一致性。
原则四：使用现代化的编程实践（Use Modern Programming Practices）
采用现代化的开发方法、开发实践提升软件的效率与质量。
原则五：维护关于结果的清晰责任（Maintain Clear Accountability for Results）
对于项目的阶段产出、各个小组之间的承诺、每个人的产出与承诺要明确，要可验证。
原则六：使用少而精的人员（Use Better and Fewer People）
（1）人与人之间的效率差别达10倍甚至25倍以上，因此要使用精英团队。
（2）采用多种方式提升沟通的质量与效率，包括：不要通过加人的方式解决进度问题；项目的初期不要太多的人员；为高性能提供高的回报；淘汰低性能者；使用自动化的辅助工具。
原则七：坚持过程改进的承诺（Maintain a Commitment to Improve the Process）
识别、分析技术与过程的改进，建立持续改进的机制。
如果仔细去分析敏捷的软件开发方法，则可以发现，恰恰敏捷的实践很好地满足了上述七个原则。
