《知行合一： 实现价值驱动的敏捷和精益开发》，快速浏览完，准备下一步的详细阅读，作者重在实践，从“怎么做”和具体实践经验来介绍，值得点个赞。
丛斌
297个笔记
前言
>> 重点讨论如何建立以Scrum为框架的软件开发管理体系，并从有效管控技术债务角度出发，形成和Scrum框架匹配的工程实践。
>> 第三部分详细描述了CMMI和敏捷开发模式结合的有效方法，其内容是许多软件企业非常关注的，因为目前许多国内的软件组织都引入了CMMI开发模型。许多政府、企业项目招标时，把CMMI资质作为一个重要的评分项。当这些组织实施敏捷时，就面临如何在CMMI框架下实施敏捷的挑战。
第一部分 神形兼备的敏捷开发模式
>> 第1章 从“先知后行”到“知行合一”——从传统开发模式到敏捷开发模式
北大西洋公约组织的科技委员会在1968年10月组织了一次会议，在那次会议上，出现了“软件工程”这个词。50位来自11个国家的软件用户、软件生产者和高校从事软件教学的教授一起讨论了下列一些软件工程中碰到的突出问题。
随着数据系统不断渗透到现代社会日常活动中，如何保证这些系统的可靠性成了一个日益突出的问题。
大的软件项目的进度及特性需求难以控制。
>> 我们首先审视下列4个问题。
（1）什么是成功的项目？项目中的决策应该由什么来驱动？
（2）Royce博士提出的瀑布开发模式真的适用于复杂软件产品开发吗？
（3）复杂软件项目的特点是什么？
（4）根据复杂软件项目特点，我们需要建立一个什么样的开发模式？
通过对这4个问题的讨论，
1.1 重新审视项目成功的标准
项目目标的定义：约束条件➕目标
>> ，项目就一定是个失败的项目吗？
似乎有点绝对，传统项目在交付的时候需要做均衡，时间优先，成本优先，质量优先，还是做均衡。
>> “传统铁三角”的致命问题是前面的两个假
>> 追求价值最大化应该是每一个项目的管理目标，也是所有重要决策的依据。
似乎大家都只有花钱（申请费用）的时候才会考虑投入产出比
>> 所有的管理者应该习惯这种管理思路：不论项目中需要做什么大小决策，都应该做投资回报分析，可是传统开发模式常常不能有效支持价值驱动管理模式。
>> 所有的管理者应该习惯这种管理思路：不论项目中需要做什么大小决策，都应该做投资回报分析，可是传统开发模式常常不能有效支持价值驱动管理模式。
这个例子非常贴切，比常举的点菜例子更加贴合实际。
>> 国产电视剧模式就类似于以瀑布模式为代表的传统软件开发模式，它要求我们“先知后行”。需要有明确的计划，只有整个电视剧杀青后，才会第一次收集到观众的反馈及收视率的数据。很明显，这种模式是很难支持价值驱动的管理模式的。因为在实际场景下，价值的判断是需要用户的使用反馈的。
而美国电视剧模式则是“知行合一”的方式，这也是本书讨论的敏捷开发模
1.3 复杂软件项目的共性：需求的不确定及技术的不确定
最重要的两点，不确定性就是风险
>> 需求的不确定性以及团队所用开发技术的不确定性。
>> 需求的不确定性以及团队所用开发技术的不确定性。
STACEY矩阵
例子举的很好
>> 这里我用一个例子说明需求进化和蔓延的区别。
>> 这里我用一个例子说明需求进化和蔓延的区别。
>> 不确定度分成下面几类。
>> .3.2 实现每个客户需求都有代价，但不是每个需求都有价值
>> 计调查显示近60%的软件产品功能基本不被使用，只有20%的功能经常被用户使用，另外20%左右的功能偶尔被使用。
这个分法定义内容可借鉴：
>> 技术平台的不确定性分成下面3个度。
>> 技术平台的不确定性分成下面3个度。
>> 团队一开始不了解自己的效率
人是
>> 瀑布模式也不能有效支持跨职能团队的快速磨合：系统分析员主导需求阶段的工作；设计人员只在设计阶段忙碌；开发人员在实现阶段唱独角戏；测试人员是在代码提交后才开始全面介入。也许大家会一起参加一些例会及技术评审会，但讲话的基本是当前阶段忙碌的小组。
1.4 从“先知后行”到“知行合一”
>> 瀑布模式在很多复杂项目上的失败是诱发敏捷运动的最主要原因。任何一个新方法的提出一定是为了解决旧方法中的缺陷，敏捷弥补了以瀑布模式为代表的传统开发的不足。从另外一个角度来讲，敏捷又是我们习惯的做事、学习方式。还记得小学二年级老师如何教你写作文的吗？他会帮你先写个提纲，然后你写出第一稿，他会告诉你哪些地方写得好，哪些地方写得不好，然后你再写出第二稿，重复这个过程，直到老师满意为止。我们从小就知道，想把任何一件事做好做精，就需要不断重复实践，不断完善。和瀑布模式不一样，敏捷模式是人类的自然做事方式。
1.4.1 知行合一是自然的结论
当你开始开发一个需求模糊或技术不成熟的产品时，知行合一的模式是自然的选择。敏捷方法中有4个核心元素。
敏捷的四个核心要素；迭代开发、特性驱动FDD，时间盒，增量提交
>> 敏捷方法中有4个核心元素。
>> 敏捷方法中有4个核心元素。
控制变更成本更为重要
>> 争取第一次把事情做对！我忍不住给了个建议，是否考虑将其改为：争取将变更成本降到最低！我的解释是，不论第一次你做得多好，它都可能会变，控制好变更成本更重要。时间盒希望团队关注问题的解决，而不是完美的方法。
>> 争取第一次把事情做对！我忍不住给了个建议，是否考虑将其改为：争取将变更成本降到最低！我的解释是，不论第一次你做得多好，它都可能会变，控制好变更成本更重要。时间盒希望团队关注问题的解决，而不是完美的方法。
>> 捷。
在项目前期我们很难了解所有的产品需求及价值
>> 理解会越来越清晰。
客户频繁的反馈是避免弯路最重要的手段，团队对自己方法的及时反思是提升效率的法宝。
正确的可执行代码是项目进展状况最准确的度量。
>> 让不同职能小组形成一个团队一起工作是解决接力中信息流失的有效做法
测试前移可以改善开发、测试、客户间的对话，真正提高代码质量。
>> 管理者应该是领导者
>> 同时做多个项
>> 是效率的杀手。
快速反馈
>> 快速反馈机制是我们在复杂的、不确定的开发环境下生存的最有效方法之一
>> 快速反馈机制是我们在复杂的、不确定的开发环境下生存的最有效方法之一
>> 摸着石头过河，但要不断抬头看一下方向是否正确，如果走了弯路，就及时调整，将错误成本降到最低。
>> 敏捷就是在开发中学习、成长、调整和完善。
1.4.3 敏
>> 法
传统开发模式的主要特征除了瀑布接力开发外，还有一个是任务驱动管理。
面向的是任务，而不是功能特性。
>> 任务驱动的最大问题是把关注点从我们应该关注的地方移开了：实现的产品需求功能特性。
>> 任务驱动的最大问题是把关注点从我们应该关注的地方移开了：实现的产品需求功能特性
>> 任务驱动的另一个弊端出现在团队承受大的进度压力时。为了赶进度，团队只能减少任务，往往首先被压缩的是质量控制相关的活动，如技术评审、测试。
此点分析到位
>> 瀑布模式解决进度问题的方法是砍掉任务（通常是测试任务），而敏捷解决进度问题的方法是减少用户需求特性。前者牺牲的是质量，而后者砍掉了价值最低的用户需求。
>> 瀑布模式解决进度问题的方法是砍掉任务（通常是测试任务），而敏捷解决进度问题的方法是减少用户需求特性。前者牺牲的是质量，而后者砍掉了价值最低的用户需求。
2.1 经常被错误解读的敏捷宣言及敏捷原则
>> 先知后行（定义好一切再开始软件开发）的弊端，尽早、持续交付软件增加了开发团队和产品团队（客户）的沟通机会及质量。知行合一的增量开发也能让用户尽早开始使用开发出的有价值的系统功能特性。
>> 最大化地减少不必要工作的艺术——这是敏捷精
>>
1．尽早、持续交付有价值的软件是我们满足客户的最优先考虑。
2．即使到了开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。
3．频繁交付可以工作的软件，交付间隔越短越好，可以从一两周到一两个月。
4．在整个项目开发期间，业务人员和开发人员必须可以天天随时沟通、一起解决问题。
5．围绕一群有动力的个人进行项目开发。给他们提供所需要的环境和支持，并且相信他们会把事情做好。
6．对一个开发团队来说，面对面沟通是最高效的传递信息的方法。
7．工作的软件是软件开发中首要进展度量指标。
8．敏捷过程提倡可持续的开发。产品的赞助者、开发者和用户应该能够保持一个长期的、恒定的开发节奏。
9．不断关注卓越技术及优秀设计能增强敏捷力。
10．简于形——是最大化的减少不必要工作的艺术—这是敏捷精髓。
11．自我组织的开发团队能够逐步摸索出最适合的构架、需求和设计。
12．每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后对自己的做事方式进行必要调整。
那么什么样的开发模式称得
3.1 形似神不似的Scrum实施
搞清楚你的问题，搞清楚你需要什么后，也就是痛点，才能有效引导一个新流程框架的落地
>> 俗话说：好的开始是成功的一半。知道为什么引入敏捷，明确要解决的问题是一个好的开始。
>> 俗话说：好的开始是成功的一半。知道为什么引入敏捷，明确要解决的问题是一个好的开始。
3.2 使用Scrum的艺术
>> 软件开发团队的跨职能小组之间不应该是PK的关系，应该是荣辱与共、同在一条船上的关系：产品缺陷给使用的用户带来了不便是整个团队的耻辱，发布前发现的每一个缺陷都是值得整个团队庆祝的事。
>> 团队从被动到主动，不可能一步到位。管理者必须给团队创造一个安全的环境，让他们放手发挥自己的能动性，出了问题不要责难，而是要鼓励。中国的Scrum过程经理在这方面面临的挑战更大，他需要指导团队逐步学会使用自己的权力，去担当，去学习，逐步形成一个真正的团队。
>> 考虑两个今天需要做的决策选择：是用简单的方法实现功能、需要的话明天再修改，还是用复杂的、超前的方法来实现同样的功能，因为明天可能需要？敏捷的选择永远是前者，因为今天实现的额外复杂功能以后可能永远不会被使用。
不久前我为一家电信应
>> 敏捷实施中所需要的勇气，在这里我讲的是一个软件工程师在面对问题时应有的勇气。
不只是软件工程师，任何一个人员，都需要有说真话的勇气。
>> 在这里我讲的是一个软件工程师在面对问题时应有的勇气。
>> 敏捷中我们再加4个字——“错了再改”。Scrum中的频繁反馈会让你很快就有纠错的机会。
这个是一直困扰我的问题！！！看看书上如何解析？
>> 在国内我常听到这样一种说法：敏捷是好，但我们开发人员能力不足，所以我们无法敏捷
>> 在国内我常听到这样一种说法：敏捷是好，但我们开发人员能力不足，所以我们无法敏捷
>> 因为敏捷并不是为技术精英设计的，如果你的团队在传统模式下能够开发出软件，那么他们就有能力敏捷。但我同意这样一种观点：没有自律，没有把团队能力提升作为敏捷迭代一个目标，我们无法打造一个高效敏捷团队，这也是自我管理的重要基础。
>> 只有你的团队真正开始实施Scrum后，你才能逐步真正理解它以及它的价值，在实践中学习（learning by doing）是掌握Scrum的唯一方法
>> 一起攻克一个复杂问题，高效协作，学习调整时，你会慢慢体会到Scrum的妙处
>> 自律就是接受责任有担当，就是接受并遵循确定的开发架构，就是遵循团队定义的设计原则，就是遵循团队定义的编码规范，就是写出简洁的代码，就是不把质量作为一个牺牲品，就是遵循团队的行为规范，就是乐于让同伴检查自己的工作。这些不仅是贴在墙上的口号，而且是团队的日常实践。
>> 自律也是让开发过程完全透明，每天都使自己的工作和团队其他成员的工作同步
>> 的
所有的流程设计均需考虑将各条规则相辅相成，互相补充，但是灵活的流程必须满足一点，比如考核流程，需给执行流程的人员留有空间，上升的空间，而不是将人堵死，就像一个山谷，必须留有出口，这样大家才有努力的空间。
>> 敏捷（Scrum）实践有极好的互补性，每一条都有自己的缺陷，敏捷的妙处是这些缺陷会被其他实践所弥补。正是这些相辅相成的实践，让我们能够实现敏捷带来的价值。
>> 敏捷（Scrum）实践有极好的互补性，每一条都有自己的缺陷，敏捷的妙处是这些缺陷会被其他实践所弥补。正是这些相辅相成的实践，让我们能够实现敏捷带来的价值。
>> 很难在一个短的周期（1～4周）开发出对客户有价值、可发布（满足质量要求）的软件。
>> 跨职能团队
>> 能够在一周内完成。
>> 很难有一个真正做到自我管理的团队。
>> 很难让整个开发过程变得透明。
>> 很难获取产品的反馈并做及时、合理的调整。
>> 很难获取对所用敏捷过程的反馈并做出及时调整。
>> 的回顾会是获取反馈的好时机，对问题错误做根
>> 敏捷和CMMI结合的探索也许可以是解决软件开发问题之匙。
>> 让产品经理知道开发团队的能力——每次迭代能实现多少功能，这是让版本计划变
>> 敏捷对卓越技术的追求及明确的“完成”标准是控制带病迭代的关键。
—任何一个体系都是一项系统工程，其结构是整体架构，环环相扣，如果在某一环节缺失，必然会导致无法行成闭环，僵化-固化-优化是必不可少的。
>> 尽可能完整地引入Scrum是让其价值最大化的保证，令人遗憾的是敏捷实践者往往忽略这一点。
>> 尽可能完整地引入Scrum是让其价值最大化的保证，令人遗憾的是敏捷实践者往往忽略这一点。
3.3 极限编程是Scrum最好的伙伴
>> 极限编程追求简单，宁肯今天用最简单的方法实现功能，也不自作聪明预测将来，用复杂的方法实现大而全的功能。
>> 如需要，将来再修改，坚决避免开发出没人使用的功能的情况
分钟，测试的反馈；天，客户的反馈；周，系统功能的反馈，避免同样问题，分析后提升评审和测试的能力，评估速度，调整迭代发布计划；月，用户的反馈。这一点可以尝试，但是最重要的是考虑在团队内如何执行落地。
>> 。在传统开发模式下，有一个常见的错误认识：系统一旦上线投入使用，你就无法做大的修改。极限编程让对上线后的系统进行修改变得容易。
通过分钟，测试的反馈；天，客户的反馈；周，系统功能的反馈，避免同样问题，分析后提升评审和测试的能力，评估速度，调整迭代发布计划；月，用户的反馈。
>> 。在传统开发模式下，有一个常见的错误认识：系统一旦上线投入使用，你就无法做大的修改。极限编程让对上线后的系统进行修改变得容易。
>> 。在传统开发模式下，有一个常见的错误认识：系统一旦上线投入使用，你就无法做大的修改。极限编程让对上线后的系统进行修改变得容易。
>> 在迭代后期，如果你发现架构的缺陷不足，你会怎么办？你必须敢于先放弃新功能的实现，集中精力修复架构的问题。当你发现一个程序模块存在大量问题时，你必须有勇气把它扔掉、重新编写。
>> 不要为明天去设计、去开发，努力解决好今天的问题，相信自己明天有能力实现必要的复杂方案（如果需要的话）
>> 微量变更体现在多个方面：设计一次变一点，计划一次变一点，团队一次变一点，Scrum和极限编程的导入也要一步一步地实施
>> 整个极限编程的思路就是将变更成本降到最低。
质量至上（qu
>> 卓越或超级卓越
任何流程落地都需要考虑具体情况，具体分析，结合现状，进行有效的导入
>> 结合本地特点（Local adaptation）。
>> 结合本地特点（Local adaptation）。
非真实的数据，会引起统计分析和原因分析出现偏差，所有数据引入前需先做数据整理。
>> 真实客观度量（Honest measurement）。
>> 真实客观度量（Honest measurement）。
>> 编码、测试、倾听、设计是极限编程提出的4个核心活动，之所以称其为核心活动是因为它们是软件开发不可缺少的活动
>> 关于测试：一个重要的测试秘诀是找到你能容忍的缺陷级别，例如，用户一个月抱怨一次是你可以接受的。找到这个标准后，依此建立你的测试体系
>>
有下列几个特征。
局部变化不会导致其他部分变动；
每个逻辑在系统里只在一个地方存在；
每个逻辑和它所操作的数据距离很近；
容许系统只在一个地方扩展。
—-实际情况，这种适用于全新设计，对于老的已经成型的系统，如何改善呢？？
scrum在维护类项目怎么导入呢？？？
>> 有下列几个特征。
局部变化不会导致其他部分变动；
每个逻辑在系统里只在一个地方存在；
每个逻辑和它所操作的数据距离很近；
容许系统只在一个地方扩展。
scrum在维护类项目怎么导入呢？？？，下面规划有这些内容，也是个公司经常遇到的问题，一起来看看作者是怎么改善的？
>> 团队需要有机制支持下面3件事。
做好的设计。
修复坏的设计。
让所有用到设计的人了解当前的设计。
我在国内企业做开发过程咨询时，常常碰到的一个问题是：如何建立所谓紧急项目流程？这类项目往往有刚性的需求范围和不合理的刚性的进度要求，如果按正常开发流程，团队根本无法按时提交。这类项目成了不少实施CMMI企业的头痛之处，在本章结尾的“两个团队的故事”部分，我会讲一个如何用极限编程核心活动建立紧急项目流程的故事。
>> 团队需要有机制支持下面3件事。
做好的设计。
修复坏的设计。
让所有用到设计的人了解当前的设计。
我在国内企业做开发过程咨询时，常常碰到的一个问题是：如何建立所谓紧急项目流程？这类项目往往有刚性的需求范围和不合理的刚性的进度要求，如果按正常开发流程，团队根本无法按时提交。这类项目成了不少实施CMMI企业的头痛之处，在本章结尾的“两个团队的故事”部分，我会讲一个如何用极限编程核心活动建立紧急项目流程的故事。
>> 小版本
>> 隐喻
>> 简单设计（
>> 用最简单的方法实现系统，一旦发现不需要的设计，立即将其清除。
>> 结对编程
最难落实却最有用的
>> 代码共享
>> 代码共享
>> 持续集成（continuous integration）：每当完成一个新的任务时，就进行集成和构建，有可能每天要做多次集成构建。
这也是我最困扰的一点，除非是遇上非常自觉的人，但是概率最高有20%
>> 样的工作，一个人花6小时完成，另一个人花了12小时完成（加班4小时），作为管理者你觉得谁做得更好呢？
>> 样的工作，一个人花6小时完成，另一个人花了12小时完成（加班4小时），作为管理者你觉得谁做得更好呢？
>> 这种模式下，要做到不以牺牲质量为代价的高效开发，团队需要有一个大家都理解的开发架构，这个架构能让团队成员清楚地了解到自己负责开发的模块和其他模块之间的关系；需要一个所有开发人员必须共同遵循的编码规范，这个规范要保证代码的持续优化；需要一个能随时验证代码变更正确性的持续集成环境，确保开发隐患的及时清除。
>> 敏捷实施模式：Scrum+极限编程能够做到1+1＞2。
3.4 引入Scrum等敏捷方法是一场需要勇气的变革
>> 如果领导者不关注必要敏捷技能的获取，那么很可能引入的是形似神不似的敏捷。领导者的责任是提供必要的投入，保证相关人员获取实施推动敏捷所必备的技能。获取这些技能的方式很多，例如，引入松土培训，在试点、实施过程中引入敏捷教练，在内部建立沟通交流机制，让大家逐步掌握敏捷方法、实践和相关的工具。
准备
第二部分 建立以Scrum为框架的软件开发管理体系
>> 瀑布模式到敏捷模式的转换会遇到的挑战。
>> 如何在组织层面布局？如何在基础软硬设施建设方面打好基础？
>> 当然合理的敏捷布局不是一步到位的，需要我们在迭代中不断完善。
4.1 敏捷转型的布局规划
>> 重要布局决策：
>> 管理层的主动支持至关重要，他们的期望是什么？通过什么方式、什么渠道向他们汇报敏捷执行情况？
4.3 确定Scrum的角色
>> Scrum of Scrum的一个重要工作就是解耦，在分配用户故事给Scrum团队时，尽可能让每个Scrum团队的工作在每次迭代时不受其他团队的影响，各自的需求功能相对独立，在迭代中的测试不需要调用其他团队的代码。
>> Scrum of Scrum需要做的另一个决策是不同团队的迭代周期应该如何规划。图4-10也给了两个选择。
>> Scrum中的共享团队资源
在下列场景中，我们需要建立一些资源共享的Scrum团队，提升开发效率：
4.4 敏捷过程对文档的要求
>> 敏捷过程对文档的要求
除了产品需求列表、迭代需求列表、版本计划，Scrum没有明确提出其他文档的要求，但这并不意味着不需要其他文档。敏捷不是不要文档，而是不要没有价值的文档、重复内容的文档、在满足标准名义下产生的没人用的文档。
4.6 敏捷工具
这点非常认同，一定要先线下或非自动化用的好之后，再考虑上线系统或者使用自动化工具。
>> 这里我给出一个建议：一定要在过程相对稳定后再引入工具。让工具适应你的过程，而不是让你的过程去适应某个工具！
>> 这里我给出一个建议：一定要在过程相对稳定后再引入工具。让工具适应你的过程，而不是让你的过程去适应某个工具！
5.1 应对变化的敏捷计划：波浪式的版本规划
>> 这个公式就是要求富士通的产品团队，争取以最小的代价为客户实现最大的价值。这也是敏捷的核心价值之一。
>> 通过MMF，你是在推销产品愿景，最小功能集是给有远见的客户而不是给所有人的。
5.2 Scrum迭代中的管理：频繁反馈，及时调整
>> Scrum计划包括以下3个层次
即发布计划
>> 版本计划
>> 版本计划
>> 5个会议
5个会议/仪式
>> 个会议
>> 作为“角色”，我希望完成“活动”，这样可以获取“业务价值”。
>> 每日例会的后续会议。
>> 敏捷企业应该是学习型企业，好的敏捷团队一定是一个善于学习的团队。
5.4 Scrum中的风险管理
>> 假设为了充分测试5个全职开发人员写的代码并保证进度，我们需要3个全职测试人员，如果团队只有1.5个测试人员，那么测试会拖项目的后腿。
同样的问题，项目目标不清晰
>> 检查团队迭代计划时，我们发现迭代计划目标性不强，没有关注实现相对独立、对用户有价值的功能特性。迭代需求列表中所选的用户故事没有清晰的关联性，团队在选取迭代需求时，
>> 检查团队迭代计划时，我们发现迭代计划目标性不强，没有关注实现相对独立、对用户有价值的功能特性。迭代需求列表中所选的用户故事没有清晰的关联性，团队在选取迭代需求时，
>> 价值交付定义为每轮迭代最重要的度量指标；
>> 每次迭代必须有一个主题，大部分用户故事应该是围绕这个主题提出的。
>> 应该实现一个MMF。
>> 客户同时要求团队遵循一些极限编程的工程实践，这些实践及Scrum流程都已经文档化。目前这个团队正在执行第二年合同的内容，虽然客户有些意见，但团队的努力还是得到了认可。
当时我很少接触过外包类的敏捷开发模式，这让我对这个位于二线城市的小企业有了很大的兴趣。我耐着性子了解了另外3个团队的情况，很显然，这3个团队至少需要18个月的时间才能达到CMMI三级的要求，6个月的时间连过程试点一轮都不够。
针对罗总的期望，我提出了一个简单的方案。
将评估范围限制在他的Scrum团队，我把它称之为“三一”评估：一个客户、一个团队和一个过程。评估不包括其他3个团队。
争取在10个月内完成评估。
请适当增加一些评估预算以支持必要的改进咨询、培训工作。
第6章 把握好敏捷的度——敏捷工程及质量控制实践
>> 如果我们不能把控好敏捷和自律的平衡点，项目的质量有可能会失控。
>> 敏捷对质量控制的一大贡献是抓住了质量控制应该关注的点，更加明确了质量是所有人的责任，而不仅仅是测试人员的责任。
6.1 再议技术债务
>> 技术债务是修复已上线程序中结构质量问题的成本，如果这些问题不解决，组织清楚其带来的后果：后续升级开发失控或用户操作失灵
>> 常见的债务来源有
>> 进度压力逼迫开发团队走“捷径”，如程序中不写注释，造成后期理解的困难；测试不充分，导致产品中存在操作隐患等。
>> 过早地选择了某个通信模式，后期的应
>> 未识别出程序其他需要修改之处，造成软件产品中的不一致。
用户故事没有得到足够的分解。分
>> 没有对复杂的、有依赖关系的技术文档、代码进行互查或评审
>> 缺少必要的系统文档支持
>> 需要整个团队考虑各种因素来确定，一般来讲一定要避免仅仅由团队去假设客户将来的需要！仅由开发预测未来需求，一般意味着麻烦
>> 有开发人员都需要接受重构方法技巧培训，并在开发中不断学习提升。
>> 技术债务的度量
近来业界提出了一些复杂的技术债务度量，这些方法很难真正被团队使用。其实一些简单的度量就可以刻画出债务状况，例如：
上线时发现的缺陷数；
维护中新功能开发的平均时间；
上线后修复缺陷的平均时间。
这些指标的增加，意味着技术债务的增加。
技术债务很难被量化，Israel Gat将其转换成钱。如修复5万行代码需要10万元的话，那么每行代码的代价就是2元。用这个方式和高管沟通技术债务，容易引起他们的关注。
如果使用这种方式度量债务，团队可以设定一个贷款限额（credit limit），当债务超出这个值的时候，也许你就不能再开发新功能了，需要静下心了还债了。
6.2 敏捷中的需求开发及管理
>> 贯穿整个开发过程中的需求澄清：串讲及反串讲
>> 。只有二意的需求，没有二意的程序！
>> 产品线的需求演变过程经历下列的形式：原始需求（Initial Requirement, IR）→特性需求（Feature Requirement, FeR→功能需求（Function Requirement, FuR）→已分配需求（Allocated Requirement, AR）→接口→验收标准。
上述产出物代表了需求逐步细化，向最终代码演进的过程。
6.3 敏捷中的设计和开发
>> 简明设计的以下4条要求（重要性由前到后）
>> 说明还不够简明
>> 所有需要沟通的思路都在系统里面有所体现
>> ）复制的逻辑或结构都会让代码难读难改。
>> 用最少的元素
>> 只发布必须发布的接口
相对于未发布接口——如J
>> 高内聚，低耦合
>> 解耦是降低模块间的依赖、提高复用的一个好办法。
>> 有明确的入口标准
>> 在制订计划时，需要根据评审规模，依据评审速率（如设计页数/小时、代码行数/小时等）安排评审的投入时间，保证必要的评审有效性（发现足够缺陷）
>> 收集评审效率数据并给出结论。评审中收集缺陷、投入时间等效率数据能够帮助我们更好地制订评审计划，也能指出评审短板。
6.4 敏捷中的测试
>> 6.4.1 测试驱动开发的价值及方法
质量意识宣传点
>> 持续集成：提高开发效率的重要保证
>> 持续集成：提高开发效率的重要保证
>> 每次集成都通过自动化的构建（包括编译、发布、自动化测试）来验证，从而第一时间发现集成中的错误，给出实时反馈
>> 持续集成系统应该具备下列能力。
提供统一的代码库。
>> 自动构建并能做到快速构建的能力。
>> 自动测试的能力。这也就是测试完全自动化，开发人员提供自测试的代码，任何人都可以只输入一条命令就运行一套完整的系统测试
>> 每个开发人员可以随时向代码库主干提交代码。这也就是提供主创建，让任何人都可以
>> 每次代码提交后都会在持续集成服务器上触发一次构建
>> 持续集成的关键是完全的自动化：读取源代码、编译、连接、测试，整个创建过程都应该自动完成。
>> 持续集成应该同时遵循下列原则。
（1）所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败。
（2）开发人员每天至少向版本控制库中提交一次代码。
（3）开发人员每天至少需要从版本控制库中更新一次代码到本地机器。
（4）需要有专门的集成服务器来执行
>> 修复失败的构建是优先级最高的事情。
>> Humble（Humble et al.,2011）详细描述了持续集成的方法及实施。
>> 敏捷环境下如何执行单元测试、集成测试、验收测试和系统测试？在什么情况下，团队需要做手工测试呢？
>> 单元测试的构架是敏捷测试的关键环节，针对不同编程语言的xUnit构架都是很好的选择。
>> 些测试每日在构建服务器上会跑一到两次，也使用一些如前介绍的集成工具，如Hudson、Jenkins或Anthill等。
验收测试是系统行为驱动测试，在Scrum中由产品经理主导完成，XP则要求客户主导实施。
>> 让发现的缺陷的价值最大化
如何处理评审和各类测试发现的缺陷是软件组织成熟度的一个重要指标，成熟的组织会把每一个缺陷都当成改进的机会。
>> 以是迭代回顾会的一个重要议题。
这部分属于接下来重点改善点
>> 对于客户验收或用户使用中发现的缺陷，建议分析必须能回答下面4个问题。
（1）为什么内部评审、测试未能发现这个缺陷？应该是哪个环节发现？分析结果应该告诉我们哪里的网口太大，导致缺陷漏了过去，我们需要补上这些漏洞。
（2）提交程序的哪些模块可能有类似的缺陷？你应该主动告诉客户这些埋有同样“地雷”的模块，在其引爆之前将其清除。
（3）如何修复这个缺陷？相信你已经做了。
（4）如何保证类似缺陷不再出现？这个是最难做的，主要需要从人、方法过程角度来思考，这是团队效益最明显的改进点！
>> 对于客户验收或用户使用中发现的缺陷，建议分析必须能回答下面4个问题。
（1）为什么内部评审、测试未能发现这个缺陷？应该是哪个环节发现？分析结果应该告诉我们哪里的网口太大，导致缺陷漏了过去，我们需要补上这些漏洞。
（2）提交程序的哪些模块可能有类似的缺陷？你应该主动告诉客户这些埋有同样“地雷”的模块，在其引爆之前将其清除。
（3）如何修复这个缺陷？相信你已经做了。
（4）如何保证类似缺陷不再出现？这个是最难做的，主要需要从人、方法过程角度来思考，这是团队效益最明显的改进点！
7.2 CMMI的核心和价值
>> 什么是CMMI的主题？不言而喻是过程管理。它要求团队忠实地遵循制定的过程，完成开发工作，同时在实践中不断学习，来完善这个过程。过程强调并保证开发相关活动中的沟通，以达到必要的透明度。这个沟通可以是在一个项目内的，也可能是项目之间的。通过建立有效的度量体系，支持过程改进、项目管理以及决策的要求。
也就是流程100%执行
>> 如果不能保证制定的过程在组织日常工作中落地，CMMI的价值是不会实现的。我在指导企业做过程改进时最常讲的一句话就是“说到做到，做不到则不说”。
>> 如果不能保证制定的过程在组织日常工作中落地，CMMI的价值是不会实现的。我在指导企业做过程改进时最常讲的一句话就是“说到做到，做不到则不说”。
7.3 CMMI+敏捷：解决软件开发问题之匙
>> CMMI和敏捷具有高度互补性。CMMI关注的是“做什么”，而敏捷关注的是“如何做”。将这两个模式有效地结合起来有可能是解决软件开发问题之匙（Cong,2016）。
7.4 来自敏捷宣言起草者及CMMI作者的最新声音
这部分需再仔细看
>> H公司是国内一家知名通信龙头企业，十几年来一直非常重视过程改进。经过多年努力，H公司建立了一套IPD（集成产品开发）的产品开发流程。
>>
H公司是国内一家知名通信龙头企业，十几年来一直非常重视过程改进。经过多年努力，H公司建立了一套IPD（集成产品开发）的产品开发流程。
8.1 从使用角度看CMMI
>> 讨论重点从“为什么”转到“如何做”
>> CMMI开发工程线包括下列5个过程域：
需求开发（requirement development, RD）；
技术解决方案（technical solution, TS）；
产品集成（product integration, PI）；
验证（verification, VER）；
确认（validation, VAL）。
无论采用传统瀑布模式还是敏捷模式，产品开发团队都会经过这5个过程活动，尽管瀑布模式会是线性接力模式，敏捷模式则会按同步并行、交叉实施模式。
>> 产品集成不是将组件一次性地装配起来，它往往是一个重复过程，是增量完成的。在这个过程中，管理好产品与产品组件的内部与外部接口，以确保接口间的兼容性十分重要。瀑布环境下的产品集成和敏捷环境的集成差异很大，瀑布环境下的软件集成往往是在项目后期开始，而敏捷环境下产品集成是频繁的活动，在迭代过程中每天进行。
VER是什么？如何在整个开发过程中保证团队在做正确的产品是验证过程关注的事情。在软件开发过程中，验证的主要手段是通过技术评审及测试来实现。VER的主要目的是验证产品功能特性的正确实现，需求评审、设计评审、代码评审走查、单元测试、配置项测试、集成测试、系统测试是常见的验证手段。将缺陷植入点和识别点的距离降到最低，是验证过程的努力目标。
VAL是什么？根据客户对产品的质量要求，每个软件团队都会在开发过程中及在将产品提交给客户前做必要的验证工作。验证和确认的主要差异是产品功能使用环境的考虑。
>> 将缺陷植入点和识别点的距离降到最低，是验证过程的努力目标。
>> 工作。验证和确认的主要差异是产品功能使用环境的考虑。验证保证产品在用户实际使用场景能正确工作，常见的确认手段包括验收测试、试运行、模拟、用户评审等；
>> 敏捷中的过程改进融入了团队的活动中（如Scrum中的回顾会），但缺乏组织级的改进实践及团队间的经验共享。CMMI管理组织活动的过程域很好地弥补了敏捷的不足。
>> 达到积累、复用、知识共享的目的。
8.2 完善Scrum实现CMMI项目管理的要求
>> 。如何让大家改变习惯性的思维及工作方式，达成一致的理解，这是很大的挑战。敏捷的增量实施的方式会是让其落地的有效办法。
如图8-1所示，Scrum自身基本可以
8.4 用敏捷手段实现CMMI支持活动的要求
>> 我认为QA可以在3个层次上进行稽核：有没有；对不对；合理不合理。
>> 为实现客观评价的价值与效率，敏捷组织需要确定以下几点。
谁来做QA的工作。
过程、产品的评价如何进行。
评价的重点是什么，将评价哪些过程与工作产品。
评价活动及结果将如何做到和团队的节奏合拍（例如，作为每日会议的一部分、检查单、同级评审、工具、持续集成和回顾）。
>> 如何进行QA活动？应该是活动中（每日例会）和节点（如迭代结束时的回顾会议）的结合。进入迭代前团队需要一起确定稽核的对象、方式，并对QA的价值达成共识。
>> 对不同的不符合问题可能有不同的处理方式：有些需要实时处理，如在每日例会中提出、例会后解决；有些问题有可能需要在回顾会议上讨论，在后续迭代中调整完善。团队应该养成好的习惯，可以在迭代日志或关注问题版面上记录重要的问题
>> 想象一下下列问题对哪个组织、团队不重要：
你的团队能做多少事？今年比去年有提升吗？
每万行代码，你给用户带来多少缺陷？
评审发现缺陷的能力如何？不同测试发现问题的能力如何？
开发过程工作量如何分布——需求分析，设计，开发，测试还是项目管理？
缺陷的阶段植入如何分布——需求、设计、开发还是缺陷修复？
团队在执行哪些过程时最困难？
影响组织实现业务目标的短板在哪里？
>> 敏捷环境下实施本目标活动时要解决下列问题。
每个度量项的应用场景是什么：谁来用？什么时候用？怎么用？
每个度量项的度量单位是什么：这个问题看似简单，但并不简单。如很多团队用代码行度量规模，但如果不考虑细节问题，就会出现不可比的问题。如注释行算不算，自动生成代码算不算，不同语言的差异如何处理等细节都必须定义清楚。
每个度量项的收集存储如何执行：度量项的收集点是什么，原始数据从哪里来，谁来收集，谁来验证数据的正确性，如何存储。
每个度量项如何分析、沟通：如何分析度量项，出现在哪些报告记录中，通过什么方式告知相关利益方。
度量项的价值在于帮助组织、团队了解过程、产品、项目的状况，识别改进点
>> 一定不要忘了轻量易用的原则。
>> 度量需要积累，用度量指导决策的习惯需要逐步养成，这也是一个成熟团队、一个成熟组织的标志之一。
>> 均值在组织层面完全可以用来度量整体开发效率，判断度量改进效果在效率方面的体现。
>> 这也是为何度量的可操作定义（operational definition）格外重要。
>> 当然这个实践要求应该是轻量灵活的，不要为做DAR而做DAR，只做有价值的DAR。
8.5 敏捷环境下实现CMMI过程管理的要求
>> 如何在组织层面推动过程改进是被敏捷遗忘的一个角落。敏捷强调团队内的持续过程改进，至于团队间的经验共享则没有提及
>> （1）迭代周期；
（2）迭代内测试；
（3）迭代用户故事；
（4）产品经理；
（5）产品需求列表；
（6）估算；
（7）迭代燃尽图；
（8）迭代回顾；
（9）Scrum过程经理；
（10）Scrum团队
>> 如何平衡好日常工作和改进工作是每一个组织面临的挑战，敏捷组织也不能逃避。
>> 们在规划和实施改进时，也应该遵循敏捷的方式，增量改进，及时反馈调整，计划时做到远粗近细。
>> 一个自我管理的敏捷团队也同样需要组织的支持，团队忙于产品开发，不可能时时关注新技术、新方法、新过程、新工具。让团队及时掌握新的东西，也是一个敏捷组织应尽的责任，实施OT可以让它尽到这个责任。
8.6 敏捷环境下实现CMMI高成熟度的要求
>> 敏捷模式下较为常见的QPPO一般包括两条线：团队效率以及质量。
>> CMMI五级的两个过程域要求改进必须是问题、痛点驱动，改进必须关注投入产出比，改进成果必须有效地在组织层面推广。敏捷基本没有覆盖这两个过程域的实践
>> 敏捷团队应该只对重复出现的缺陷和问题、真正包含有价值或创新的新实践的结果实施CAR。
>> 下列是一些常见的改进来源：
团队通过根因分析形成的改进建议；
团队内部的优秀实践；
业界的优秀实践（包括CMMI）；
软件工程的新技术、新工具、新方法。
8.7 敏捷环境下的CMMI评估应关注的两个问题
>> 敏捷组织在准备CMMI评估时，普遍有个担心：我们覆盖了模型所有的要求吗？更头疼的问题是如何完成敏捷实践和模型实践的映射。
>> 最小活动集合，让团队根据具体项目特点由小到大进行裁剪，这样就能大大减轻小项目团队的计划工作，同时又能保证“必须做”的活动不会出现在从大到小的裁剪中
9.2 敏捷的局限及挑战
>> 通过4个深入浅出的例子，清楚地解释了MVP的目的，以及由简至繁的产品进化过程及方法。建议读者看一下这篇博文，其网址是http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp。
>> 提出支持快速开发的架构要能做到以下3点。
支持子系统的复用：显而易见，高复用度意味着高速开发。高复用要求我们的架构设计必须是模块化的。
尽早冻结子系统间的接口：接口需要明确定义清楚，并划分清楚相关责任田。接口设计的冻结点确定要足够早，同时接口设计要有足够的灵活性，这样既可以有效支持同步开发，同时又能处理好不可避免的需求变更。在某种意义上，这是一个用成本换速度的办法。
尽量避免使用对进度影响大的技术：由于新技术的使用往往会导致进度的不确定性，如果进度是第一考虑，那么架构设计应优先考虑支持使用熟悉的成熟技术。
>> 忽略了开发中的等待队列
>> 什么是降低响应时间最经济的做法呢？常见的做法有加班、想办法提升团队能力、引入新的技术和工具等，而这些都是费力难讨好的做法。多年来我们忽略了一个最省力的方法，就是管理好软件开发过程中的等待队列。
>> 忽略了开发过程中的变异管理
第10章 软件开发的新模式——新一代精益软件工程
>> Scrum过于简化了软件开发中的一些活动
>> Scrum的另一个问题是它没有做到端到端的覆盖，其从概念到开发、到运维服务的过程是个“从概念到利润”的价值链。
10.1 初级软件精益开发模式：看板方法
>> 看板包含很多方面的内容，但其核心就是实现一个精益拉动计划系统，它主要包含以下3大块。
>> 看板的另一个重要特点是，你可以将其和你现有流程相结合，指导更具针对性的过程改进。
10.2 精益软件开发框架
>> 精益软件框架（Leffingwell,2011）。这个框架包含了以下5部分内容。
屋顶，目标：快速、持续交付有价值的需求。
支柱1：对人的关注。
支柱2：持续改进。
基础：精益管理支持。
内容：精益产品开发流。
>> 如何用经济指标而不是替代指标指导软件开发活动
>> 队列理论及统计分析方法及其应用
>> 开发过程中的批量规模（精益中的所谓的Batch Size）及在制品（WIP）规模，
10.3 用经济指标指导软件开发
>> 从一开始意识到市场有需求到产品正式发布，延期成本在各个阶段都是一样的，但不同阶段的时间代价则差异巨大！
>> 2．追求响应时间的改进高于效率的改进
我认为单纯追求工作效率是软件过程改进的一个问题，也是替代指标遮盖了真正指标的常见例子。
10.4 用基本队列理论、统计方法管理软件开发过程
>> 测试响应时间就是队列等待时间加上实际测试时间
>> 等待时间和所投入资源以及资源利用率的关系如何确定呢？这恰好是非常成熟的队列理论可以帮助我们解决的问题
>> 有哪些有效做法可以减少等待队列规模从而缩短响应时间呢？
>> 1．平衡并设置恰当的资源规模
如果钱能解决的问题不算问题的话，那么按任务峰值设置资源就是最简单的做法。
>> 设置共享资源池、专家池是个好办法，他们可以支持所有项目
>> 通过培训提升人员能力，培养T型人才也都是低成本增加资源的有效做法。
>> 2．科学管理开发团队的任务包规模
除了处理好资源设置外，管理好等待队列还要求我们管理好给团队的任务包规模，也就是源头的控制。看板的WIP上限的设置是一个简单有效的做法。
>> 极少看到来自开发的需求变更申请。其实提出合理的需求变更可以成为开发团队拯救一个失控项目的最好手段。
>> ，当前版本暂不包括Y银行是一个明智的选择，因为我们只是将用户群从100%降到95%（假设Y银行的用户不超过5%）。这个损失换回的是项目按期、高质量完成。
>> 如果需求规格要求系统和所有微软Windows版本兼容，而前期版本的Windows用户已经接近于0，那么开发团队应该要求将这些需求从规格中删去。
>> 规划好产品特性、避免需求蔓延是软件精益开发管理最重要的一点。5.1.3节讨论的最小有市场价值特征（MMF）集方法对解决这个问题很有帮助，通过迭代方式实现持续交付对用户有价值的产品特性，同时保证每个迭代的需求列表规模不会让团队超负荷。
>> 增加软件开发各个环节的复用率对减少开发团队的任务量也很有帮助
>> 3．科学管理队列
有些项目管理背景的读者都知道关键路径对进度控制的重要性，队列管理也不例外。处理关键路径上的队列应遵循一个原则：尽可能将其从关键路径上移开。通过将宝贵资源投入到合适的点，
>> 4．软件开发中的3个队列例子
除了开发源头的需求队列外，软件开发过程中也有很多等待队列，这里我们举3个例子：评审、测试及缺陷修复和采购。
>> 软件开发过程中变异量的管理
>> 在统计学中，我们用标准差（也就是σ，即西格玛）来表示变异量，到目前为止，改进都是以追求标准差的缩小为目的的。
>> 从过程性能模型角度来讲，我们可以更加关注响应时间的预测，本章讨论的WIP的个数、等待队列规模、任务规模等都是很好的可控因子的候选项。它们和响应时间的关系及预测对软件开发过程有显而易见的价值。
>> （1）统一使用共享资源池，服务差异大的上游下来的任务
>> （2）缩短计划周期。产品需求规划一般不要超过两年，因为随着时间前推，所有预测的难度会呈指数级增长
>> （3）尽可能将大创新分解成多个小创新
>> （4）重复有益的活动。系统性地重复一个活动比将所有活动一次完成更能减少变异量。如极限编程的持续集成每日构建远比6个月做一次的好处多很多。
>> （5）复用减少变异。
>> （6）针对性的调整可以减少变异
>> 让上游人员掌握一些下游工作的方法，是通过针对性调整、减少变异量的例子。
>> （7）使用缓冲积蓄可以减少变异。这是个用钱或用时间买确定性的做法。
>> 如何将变异可能带来的代价最小化、价值最大化呢
>> （1）关注软件开发过程中变异的后果。
>> （2）快速反馈能够让团队管理好变异的后果，将价值最大化。
>> （3）将变异控制在可接受的范围内。
>> （4）用低代价的变异替代高成本的变异。
>> 。追加成本的变异带来了进度的稳定，花钱买稳定往往是在用低代价的变异（成本）替代高成本的变异（进度）。
>> 5）缩短迭代周期是降低缺陷的有效做法。
>> （6）将变异过程转移到成本最低的阶段。
>> 由于不确定性的存在，变异是软件开发的必然产出物。
10.5 两个关键关注点
>> 两个关键关注点
软件精益开发过程中，有两个至关重要的度量项：批量开发规模及在制品（WIP）个数。通过对这两个度量项的控制，我们可以在不追加资源的情况下减少响应时间。
>> 减少软件批量开发规模，它主要体现在减少需求颗粒度上
>> 可以把批量规模分成批量处理和处理后结果的传递两部分。
>> 。敏捷强调面对面沟通及团队一起办公，这也是减少批量规模的一个有效做法。开发测试工具的有效使用可以大大减少批量规模。
>> 需要注意的一点是批量规模有可能是动态，不一定要强求一致。因为规模过小，也会追加需要处理的次数，累积有可能增加管理成本，所以批量规模是小规模带来的价值和处理成本的平衡
>> 控制好软件开发队列的WIP个数
在资源紧张的情况下，
>> 精益实践告诉我们控制WIP的个数是一个有效的手段。
>> 控制WIP的个数需要管理者改变心态，他们必须认识到追求100%人员使用率不见得能够减少延时，有时反而适得其反。
10.6 精益管理控制实践
>> 精益管理控制实践
减少批量规模并控制WIP能帮助我们解决许多问题，但还是不能解决所有问题，开发过程中还是不能完全消除堵塞现象。这里我们讨论一些经过验证的有效精益管理控制实践。
10.6.1 在充满不确定的环境下，尽可能保持流畅的软件开发通道
>> 在管理堵塞时，有两个有用的原则：让堵塞情况可视；为不同队列设置不同的代价。
>> 保持产品开发通道流畅的方法
>> 第一个方法是建立开发节奏。节奏可以定义为在开发过程中形成定期、有规律、可预见重复活动。
>>
另一个敏捷常用的实践——每日持续集成也是一个很好的例子
>> CMMI中提出的里程碑点及项目定期出的状态报告、定期的决策评审和技术评审也是形成开发中节奏的例子
>> 同步拉通不同于节奏，它是让多个活动在同一时间发生。
>> 巧妙地在过程中设计同步拉通，对消除开发中的堵塞问题会有帮助
>> 充分、及时、有效地利用开发过程中的反馈信息
>> 如何充分、及时、有效地收集、使用反馈信息，敏捷没有给出成体系的方法。在这方面，Reinertsen给出了迄今为止最好的总结。
>> 一个重要基础工作就是建立一个有效的反馈度量体系。反馈的度量项很有可能是替代指标，我们必须将其和真正经济指标的可追溯关系说清楚。这些度量项应该是可控因子，通过调整这些因子，我们可以达到有效利用反馈信息的目的。
>> 我们需要学会正确区分固定目标和动态目标反馈处理的差异。固定目标追求的是按计划执行，而动态目标要求团队做出及时调整，这也是瀑布模式和敏捷模式的差异。
>> 另外，不要忽略及时反馈对人的心理的影响。当团队能够快速收集到自己工作的效果反馈时，他们会感觉到一切都在掌控中。同时，能很快看到他们的工作是有后果时，对团队的行为也会有正面影响。
>> 使用模块计划（modular plan）的方式也是有效处理软件开发中不确定因素的一个好做法。
>> 精益团队的一个重要共识是响应时间远比效率重要。
>> 即团队及个人的主动性问题，在一定程度上来讲这是最关键的问题
10.7 实践出真知
看完了，快速浏览完，准备接下来的详细阅读，经验较多，值得学习
>>
>> “最佳软件开发的境界是什么？”“做到CMMI五级就达到这个境界了吗？”
>> 每当读到这里，我总是要发出感叹：放弃真是一种智慧啊！当年Watts Humphrey和他的同事们在编著CMM五级时（CMMI五级基本继承了类似的理念），没有走乾坤大挪移作者的套路。他们把CMM最高级定义为组织具备自我优化的能力，能把问题和缺陷变成改进的机会，而不是试着给出软件开发的最佳境界，从这一点来说，Humphrey比乾坤大挪移的作者要有智慧。实践出真知，讲的就是在做的过程中，不断总结形成新的知识，从而达到能力的提升。
在结束本书的时候，我想说的是：如果说本书有一点价值的话，那就是它能触发一些软件从业者开始在工作中实践。只有不断实践、不断总结、不断挑战权威，才能将本书的东西变成自己技能的一部分，才能在提升自己能力的同时，提升组织的能力。
希望读者能够通过自己的实践写出好的续篇。