推荐理由 ♥♥♥♥ 

推荐所有学习敏捷开发，教敏捷开发的朋友都看一遍这本书。如果只了解敏捷容易一叶障目。即使CMMI有这样或那样的问题，但也请你静下心来了解一下CMMI。

作者对体系理解的深度和十多年的心得体会，很值得去学习。高人的领悟是带你登堂入室的阶梯。

虽然是运维出身，但我读起这本有关敏捷开发的书仍然津津有味，已经说明书写得好看。我边读边写笔记，总共写了204个。

既然是讲敏捷和精益开发，所以必定是敏捷引出主旨。当你满心欢喜地读着敏捷的意义和价值，进入对敏捷的无限憧憬时，作者笔锋一转，带出《CMMI框架下的敏捷实施》。

为了消除读者的疑虑更好地阅读后续篇章，作者先把敏捷和CMMI的错误偏见做了一个解释。提出“CMMI+敏捷：解决软件开发之匙”。讨好读者不易。特别是对CMMI有成见的读者。

“讨好”一词用的只是玩笑话。以作者的资历其实不用讨好谁。写书要讲些技巧，传达你的思想那就得让读者有耐心看完你的书。

个人觉得本书第三部分《CMMI框架下的敏捷实施》的第七章《盲人摸象---关于敏捷和CMMI的错误偏见》和第八章《盲人摸象---关于敏捷和CMMI的错误偏见》是全书的核心价值所在。其它章节可以不看，但这两个章节强烈建议都读一读。

前面六章讲敏捷都是大家耳熟能详的部分。最后两章讲精益软件工程，更多是精益在软件工程中的实践。

悦读 Tips

《知行合一：实现价值驱动的敏捷和精益开发》带给你的不仅是作者对敏捷的理性分析，更有价值的是让你看到CMMI体系的力量。再深入一些讲，这是组织级的力量。慢慢读，从中读出CMMI以组织能力的形式对团队敏捷的赋能吧。

以上，阅读小提示。

敏捷和CMMI，水与火的世界

《来自两个阵营的偏见》

“CMMI的军工系统的背景，敏捷先驱者多来自相对小规模软件开发的背景，两个阵营的差异导致在相当长一段时间忽略了对方方法中好的部分，更没有意识到对方的长处正是自己的不足。”

“极端和偏见往往是一对孪生兄弟。如果过往的CMMI不愉快经验使你成了敏捷的粉丝，再重新认识一下CMMI所代表的最佳开发实践，对你会有帮助的。因为CMMI中的很多实践、理念能够大大提升你的敏捷过程能力，在一定程度上可能会弥补敏捷的不足。”。

在读本书之前，我承认对CMMI也有很大偏见。这种偏见来自于对CMMI的不了解，同时也受到来自敏捷的部分误导。

在消除偏见方面，真的很感谢作者。至少在我这里，从他的文字中找到了体系建设的共鸣。虽然他做的是CMMI过程管理体系，我做的是IT服务质量管理体系，但道理是相通的。

在这个共鸣层面，我很快就认可了作者的思路和价值观。认同CMMI和敏捷并非水火不相容。即使有分歧，但依然可以携手共进。

过程改进，说到做到，做不到则不说

《CMMI的核心和价值》

“让过程执行者忠实执行组织定义的过程，需要让他们看到过程及过程改进的价值：看到质量的提升，看到效率的提升，看到客户的认可。只有让管理者及工程人员信服组织制定的过程是项目成功的重要保障，那么这些标准过程才会真正让大家接受。”

“单纯追逐通过成熟度的级别，往往会让你忘掉客户真正的期望、产品及项目的价值和公司的商业目标。所以CMMI的改进必须是为实现公司商业目标服务的。”

做体系的朋友都知道一句话：管理两张皮。作者在书中也提到的“每家企业都有两个过程，一个是书面的文档化的过程，另一个是组织及项目里面实际执行的过程”。

但解决这个问题不容易。作者虽然提出了几点建议，但真正落地依然困难重重。这也是管理和技术的区别。有时候开玩笑说，凡是技术能解决的都不是问题。解决不了的，难解决的一般都是管理问题。

“CMMI终极目标（也是持续过程改进的目标）就是让企业减少浪费，提高效率，在项目开发中更好地实现客户价值。和敏捷一样，在一个建立了相互信任的开发环境中，CMMI也鼓励企业在过程中清除所有没有价值的活动，从而提升生产效率。敏捷的改进集中在项目团队层面，而CMMI更关注组织层面的改进。”

所谓价值驱动，就是始终“看到质量的提升，看到效率的提升，看到客户的认可”，并将其作为过程改进的唯一动力。

在一定意义上，CMMI可以成为Scrum的安全网

《CMMI+敏捷：解决软件开发问题之匙》

“没有组织层面建立机制支持Scrum实施的过程定义、度量体系的建立维护、实施反馈的收集管理、培训以及Scrum过程的改进，很难保证敏捷过程的落地及持续改进。”

“CMMI中的相关系统工程、质量控制、度量等实践活动弥补了Scrum遗忘的角落。在Scrum架构下，通过引入极限编程等手段，实现下列CMMI的过程域的要求。”

这部分内容强调的是组织级体系建设对团队级敏捷的赋能。之前没有这方面的认识，直到我们做光大银行测试敏捷化成熟度评估咨询才理解这其中的价值。

对于金融行业而言，强大的职能管理矩阵和业务特点决定了无法直接照搬互联网的敏捷模式。体系化管理确保了金融行业的稳定性。即使推行敏捷也不能去破坏这个稳定性。

另外，我们在咨询过程中也发现，CMMI+TMMi+敏捷的组合就是以最大的组织级能力确保端到端交付的价值最大化。它们所追求的是整体的交付速率，而非简单的效率。这时候就发现组织级能力建设的巨大优势。

组织级的体系化管理能力、组织级的过程管理能力、组织级的测试技术能力、组织级的测试环境和数据管理能力、组织级的人员管理能力等等，综合起来共同为团队级敏捷赋能。

打个比方说，在金融行业里没有组织级赋能的敏捷团队更像是游击队。而有组织级赋能的敏捷团队更像是特种兵。

不要期望文档可以完全替代面对面的互动沟通。

《从使用角度看CMMI》

“我们从来不是为写文档而写文档，文档的目的是为了实现沟通理解。你的文档要让别人能看懂不是一件容易的事，因为最常见的问题是你在写文档时，一般只关注内容而常常忽略所描述内容的背景。”

“当你描述的内容有一定的复杂度的时候，仅仅靠文档是不可能达到沟通理解的目的的。为了让对方真正理解文档内容的背景以及要求，对话是必不可少的手段。而开发和客户的对话，也往往会产生一些文档，如用户故事卡、需求笔记、流程图等。”

我们在做测试敏捷化成熟度评估咨询时也经常遇到文档之争。敏捷试点团队强调了“敏捷”而降低了正式的会议频率，改变了沟通的方式。文档被迫变得越来越多样化。截图也行，邮件也行，微信也行......

在敏捷之下文档形式不重要，但在CMMI体系之下，文档的作用很重要。这两者之间有冲突吗？

说到是否冲突，本质还是要去看文档的目的是什么？作者认为是“达到在开发过程中有效沟通的目的。文档的目的是为了沟通，有和人的沟通，也有和机器的沟通。”只是为了写文档而写文档，那么这个文档就是没有价值的。

CMMI关注的是文档是否为价值而存在，敏捷关注的是沟通因何而存在。

最后，再解释一下标题：给敏捷江湖立个CMMI的规矩。在大型复杂的开发团队中，仍然是需要立个规矩，而不是放任敏捷的“横行”。以组织能力去保障敏捷达到效果的同时限制影响质量和稳定的因素。最终，这是一个管理上的平衡，并非方法之争。
 

制造业的生产过程是高度重复，其过程明确定义了每一个生产步骤。而软件开发中的不确定性，导致了过程重复度是有限的。任何两个项目都不会完全一样，不可能走过同样的开发步骤。这个差异是“明确定义的过程”不适用于复杂软件项目管理的重要原因。

瀑布模式在很多复杂项目上的失败是诱发敏捷运动的最主要原因。任何一个新方法的提出一定是为了解决旧方法中的缺陷，敏捷弥补了以瀑布模式为代表的传统开发的不足。从另外一个角度来讲，敏捷又是我们习惯的做事、学习方式。

瀑布模式解决进度问题的方法是砍掉任务（通常是测试任务），而敏捷解决进度问题的方法是减少用户需求特性。前者牺牲的是质量，而后者砍掉了价值最低的用户需求。

如果CMMI能和敏捷成功结合，它能够提供必要的基础建设，在保证敏捷迭代开发的前提下，有效支持将敏捷的应用向管理开发复杂系统扩展。

CMMI和敏捷具有高度互补性。CMMI关注的是“做什么”，而敏捷关注的是“如何做”。

在福特的管理体系下，管理者的工作是监督下属按照一种固定的方式工作；而在丰田管理体系下，管理者的责任是不断鼓励、帮助下属学习，不断摸索出更有效的工作方式。前者成功有一个前提，就是一切必须是预知的。
 

—— 丛斌《知行合一：实现价值驱动的敏捷和精益开发》