回顾结合使用CMMI与敏捷概念这一争议话题的著作和讨论，发现相关论点充其量也是在2004年~2006年之间才进入主流。截止本书出版之前，仍有许多人怀疑CMMI与敏捷方法能否真正实现共存(假定一个品牌(例如SEI的CMM)拥有20多年的发展历史，而占领更为广阔的市场可能需要更长的时间。由于社会媒体和互联网的出现，就有希望在不到20年的时间内让人们对该品牌的信息耳熟能详)。
在此我特别推荐Paul这本书中的多个亮点，非常值得对书中主题感兴趣的人拜读。他精选的案例研究很有代表性，涵盖多种类型的公司和不同的情况。在我审阅本书的早期版本时，竟然觉得Paul曾经与我自己的许多客户和以前的老板一起工作过。但在审阅原稿之前，我从未见过Paul，也从未与他共事。我们两个有如此相似的经历只不过进一步证明帕雷托最优性是正确的：80%的问题都可以用另外20%的问题去解释。此外，可以很轻易地将Paul介绍的案例关联并推广到许多组织。即使这些案例研究与读者的经历并不完全相符，也并不意味着彼此之间毫无联系或者没有需要从中汲取的经验教训。
我特别推荐本书的另一个原因是，Paul在这些客户案例的CMMI和敏捷方法都通用的基本知识方面花费了大量的精力。尤其是为增强敏捷实践和加快 CMMI 实践发展，他尽职尽责地推行“精益”原则和实践，而我认为这也是本书的精彩之处。
在此我需要指明一点，Paul的经验来自著名的“敏捷”开发技术，正如“敏捷”开发技术起源于“精益”原则一样。研究Paul的作品后通常得出一个重要的结论，那就是我们往往需要一个像Paul这样的专家将“精益”原则有效(而且客观地)引入软件开发组织中。软件与“过程”在这几年中的整合方式也存在一些问题，为该领域的发展带来诸多挑战。Paul示范了多种方法来创造不同的条件，以便将灵活性和有条不紊的改进都考虑在内，不管是对于普通顾问还是“精益”原则领域的专业顾问这都值得仿效，尤其是对于后者更是如此。奉劝没有扎实的“精益”原则和实践基础功底的读者，前几次最好先在专业人员的指导下尝试实施。
和Paul一样，我也希望将防范措施传播给更多的读者。无论是关于Paul在案例中包含的公司还是Paul提出的方法，需要指明的一点是：不断改进作为业务的驱动因素对成功至关重要。为了评级而实施CMMI或为了获得炫耀的资本而实施“敏捷”方法，都是行不通的。人们之所以会永无止境地追求能“一劳永逸”地解决业务问题的解决方案，是由人类的本性决定的。如果真有这样的良方，就没有所谓的难题了。Paul开发的技术和方法都基于他应对客户需求的实践，而不是枯坐办公室预先编制出来，然后再提交给客户讨论。Paul在了解客户需求的前提下形成适用的解决方案。比较周全的方法是先试验，再检查，最后调整。为确保CMMI或敏捷方法使组织受益、两者互相帮助或者真正能充分利用试验、检查、调整的过程，作为目标，组织必须具备以下几个特性：自我意识、学习能力、逆耳忠言、信任和拒绝接受平庸。否则，组织只能是在努力“照搬”Paul的作品，而不能“领会其中的精髓”。
请好好欣赏这本著作，希望大家都能达到自己的“最高”境界。
—Hillel Glazer
Entinex, Inc. 负责人兼 CEO
CMMI 高成熟度首席评估师
