前言

从1968年第一次提出软件工程的概念，软件产品和系统改变了人类的生活方式，它们已经渗透到了社会的各个角落。巨大的新系统开发以及现有系统的维护需求都保证了计算机在相当长的时间内都会是个容易找工作的热门专业。令人遗憾的是，和其他工程（如电子工程、土木工程、机械工程等）相比，软件工程的开发是效率最低、浪费最大一个领域。Frederick Brooks（1987）在30年前就清楚地阐述了软件系统开发的特殊性及困难点，也建议了一些可能的突破点。软件从业者也在实践中不断尝试，可惜几十年来都没有真正突破参照制造业形成的计划驱动、接力开发、按预定过程执行的软件开发模式。越来越多的人意识到这种模式不能有效支持解决软件开发中存在的需求不确定性、技术创新要求的问题。

这几十年来我一直从事软件工程的教学、咨询和研究工作。在这个过程中，我深深体会到学校教的软件工程方法和企业实际用的开发模式都有不少不合理的地方。我们用来度量项目好坏的指标，很多时候并不能体现企业领导者真正关注的点，同时软件过程改进的一些误区也给企业、团队及个人带来了不同程度的危害，如盲目僵化地使用六西格玛方法指导软件过程改进；在不理解CMMI模型实践希望解决的问题的前提下，进行评估驱动的CMMI导入。这些做法使得过程改进对组织的质量文化起了负面作用，对企业商业目标的实现没有起到真正的支持作用。

老实说，我也发表过一些研究性的论文，在不少软件工程会议上也做过一些案例分享，却一直没有触发写书的念头，因为写书真的是一个重体力活。最近十几年来以敏捷和精益开发为代表的软件工程革命性变革，让我感觉到我们比以往任何时候都更加接近软件方法开发之匙。从大的框架角度，从开发管理原则角度，从具体实践角度，从企业实施效果角度，已经形成了一套相对完整、具备指导意义、具备系统性的新一代软件开发方法。

摸索出一些有效软件开发模式是我这些年投入很大精力在做的事情。如果有一本能够充分反映这几方面成果的书显然具有重要意义，这极大地促使了我忽略肩周炎、腰椎间盘突出的痛苦，下决心开始码字写书。本书不追求所谓纯粹的敏捷或精益，而是希望找到解决软件开发中长期没有很好解决问题的钥匙。我一贯相信存在必有其合理性，所以这把钥匙一定是各种模式中好的实践的结合物。

软件组织的管理人员、技术人员、质量人员和过程改进人员都可以从本书中获得他们需要的知识点。本书的一个特点是希望把原因讲清楚，回答好“为什么”的问题，因为理解“为什么”比知道“如何做”更重要。理解了“为什么”才能从“形似神不似”中走出第一步。贯穿本书的一个主题是如何通过敏捷、精益实践，用低成本实现软件产品的高价值点，时刻把握住软件开发中的核心经济指标，避免盲目追求可能没有真正价值的替代度量指标。

我在近几年做敏捷、精益培训及实施指导中发现，大部分Scrum、极限编程、看板（Kanban）实践者虽然接受过敏捷培训，阅读过一些敏捷和看板书籍，也有些实施经验，都会提一些类似的问题：什么是正确实施方法？如何在自己特定的企业让敏捷、精益在组织、团队、项目中落地，使其价值最大化？许多在CMMI框架下建立了开发体系的读者，都面临着和CMMI模型有效结合的挑战。希望本书能对持有类似疑问的读者有所帮助。

本书主要包含4部分内容，相互之间有一定的独立性。本书读者并不一定需要有敏捷和精益的背景知识，他们可以根据自己的需求获得有价值的帮助。前三部分的重点是讨论以Scrum和极限编程为代表的敏捷实施，第四部分则是深入探讨看板及新一代精益软件开发方法。在探讨Scrum、极限编程、看板、新一代精益的核心理念、架构、实践时，我会提出具体实施的建议。这些建议包含实践层面及理念层面的东西，体现了近年来业界对敏捷及精益的最新理解。有些建议也许会是有争议的，这些争议可能源于作者坚持敏捷、精益核心实践的完整执行以保证价值最大化，也可能源于对灵活度的把握的理解不一。

由于各种原因，本书的撰写耗时很久，未能按计划交付，在此向一直耐心等候的编辑致谢，向一直期待此书完成的读者致歉。作为延期的代价，我有必要将近几年软件开发模式及方法的新实践追加进去，同时将一些因时间推移而价值变低的内容做些删减。例如，新一代精益软件开发的内容本不在本书最初计划范围内，但今天它已经成为不可忽略的内容，因为新一代精益模式将敏捷革命带入了一个新的境界，它在方法论、原则、具体实践等方面大大丰富了软件工程的内容。

建议读者从第1章评价项目成功标准入手，真正理解传统开发方法和软件产品的不匹配之处，以及造成的低效后果。在这个基础上，读者可以从第2章和第3章中了解到敏捷方法价值观、框架、原则以及为何它能够在很大程度上解决传统开发模式的不匹配问题，并明确为什么从“先知后行”到“知行合一”是软件开发的必然之路。从传统的瀑布开发模式转向敏捷主导的模式是一件痛苦的事，如何管理这个转型也是第3章讨论的问题之一。例如，导入Scrum不能保证解决企业软件开发中的所有问题，但它会让这些问题突出地暴露出来。实施敏捷的企业有两种选择：一是面对问题，努力将敏捷中对应问题的实践作为解决方案的一部分；二是为了避免变革的痛苦，将问题埋在地毯下，仅仅引入容易在企业内部实施的实践。令人遗憾的是，许多引入敏捷的企业选择了第二种方式。它们也能取得一定效果的改进，但那些被忽略的实践，往往很可能是对它们最有价值的实践，敏捷的一些重要价值没有得到真正的实现。

本书第二部分重点讨论如何建立以Scrum为框架的软件开发管理体系，并从有效管控技术债务角度出发，形成和Scrum框架匹配的工程实践。我最近将业界常用的技术债务扩展成质量债务的概念（Cong,2017），这是一个非常重要的课题，是对敏捷、精益环境下的质量管理的一个新尝试。如何有效管理技术、质量债务，做到健康迭代而不是带病迭代，其实也是贯穿本书的一个主题。国内许多软件组织已经引入了Scrum开发模式，从第4章到第6章，我在Scrum布局准备、管理方法的落地以及和极限编程的结合等方面中做了比较系统的整理。不论是否具备敏捷实践经验，读者都可以通过一些实施案例及作者观察到的优秀实践，进一步理解这些章节中的内容。

本书第三部分详细描述了CMMI和敏捷开发模式结合的有效方法，其内容是许多软件企业非常关注的，因为目前许多国内的软件组织都引入了CMMI开发模型。许多政府、企业项目招标时，把CMMI资质作为一个重要的评分项。当这些组织实施敏捷时，就面临如何在CMMI框架下实施敏捷的挑战。第7章澄清了一些敏捷和CMMI的偏见，通过实例解释了二者的互补性。我也把CMMI研究院在敏捷和CMMI结合方面获得的最新成果纳入了相关章节中。读者在读第8章时，可以详细了解到如何在敏捷环境下实施CMMI开发模型中的所有过程域，做到在合理平衡稳定度与敏捷度的前提下，不断提升开发过程的能力。本书第三部分不仅能让读者对敏捷的不足之处有更深入的了解，也可以纠正一些业界常见的CMMI的价值及使用方法的偏见。为了保证让对CMMI开发模型不了解的读者也能看懂相关内容，我尽我的能力对模型做了通俗易懂的解释。

本书第四部分首先重新深入探讨了软件工程和其他工程的差异，特别是其“软”“易变”“非线性增长复杂度”“创新”等特点，读者可以更加深入理解为什么我们遵循几十年的，借鉴制造业的开发模式并不能高效匹配软件系统的开发。这有助于读者理解敏捷、精益存在的基础，同时读者也可以看到以Scrum和极限编程为代表的敏捷方法的一些不足之处。国内一些软件组织已经开始引入初级精益方法——看板，我在第10章首先澄清了一些看板实施的误区，然后重点阐述了如何把Don Reinertsen（2009）提出的支持创新的新一代精益开发方法移植到软件产品开发中，将其原则、实践作为精益软件工程的核心内容。软件的实践者其实已经用了其中不少原则，但他们只是凭直觉，只是支零破碎地在用些皮毛。第10章从系统角度全面探讨了软件开发应该遵循的原则，这对软件组织的管理者、工程人员、过程改进人员都会有很大的帮助。

本书不是纯学术著作，而是一本结合实例讲解操作方法的书。我同时希望将操作步骤背后的方法论、存在的价值解释清楚。引入敏捷、精益是一场变革，我想清楚地告诉读者：为什么要变？需要变什么？如何管理这些变化？如何实现价值？本书的续篇应该通过读者的实践来完成，如果阅读本书能让一些读者受到些启发，并开始在自己工作范围内做一些改进的尝试，我想，这也就达到了我写此书的初衷。

最后我特别感谢人民邮电出版社的编辑杨海玲女士，她对本书的编写给出了很多好的建议，付出了大量心血。再次谢谢我服务过的众多软件企业，这本书算是对你们的信任的一个小小回报。