1、关于敏捷的一些解读
在敏捷宣言的起草者们看来，这种响应变化的能力固然可以借助合适的流程和工具有所加强，但最重要的还是一线软件开发者自身的能力和意愿。团队的能力最终取决于团队中每个人的能力以及人与人之间丰富而微妙的互动，流程和工具只能辅助，无法替代优秀的个人与默契的团队。
——P57
这是作者对“响应变化高于遵循计划”的解读。要做到响应变化，必须是以能力为基础。
反思这几年来，我一直在给团队成员强调个人能力的提升，但还是对这条价值观没有足够重视，没有采取实际、有效的手段来提升大家的能力。主要原因也与我自己已经不在一线撸代码有关。自己不能下场秀给其它人看，就不容易让别人信服。也有些想做的事情总是要指望他人，就不容易落得了地。
软件工程四大挑战：需求管理、项目管理、配置管理、质量保证 ——P61
对于为什么要以短迭代方式交付软件这个问题，极限编程给出的答案是应对风险：软件项目的进度可能延迟，甚至整个项目被取消；软件团队可能误解了用户的需求，业务的变化也可能导致需求变更。极限编程通过快速的短迭代及早交付价值最大的功能，并及时获得真实有效的反馈，从而消减上述风险。。。。。。采用短迭代方式交付软件可以将软件上线运营和创造经济效益的时间提前，从而改善整个项目的现金流。
为了让短迭代交付方式成为可能，极限编程提出了一系列相互关联的实践：
需求管理角度——以用户故事的形式分析和记录需求，使软件需求以一种允许乃至鼓励多次迭代交付的形式出现在软件团队面前；
项目管理角度——围绕用户故事开展的迭代管理方法，包括计划会议、成果展示、每日站会等，加上对进度与质量的度量和可视化呈现，使项目随时处于透明、受控的状态；
配置管理角度——以持续集成为核心，对修改动作的频度和方式作出了严格要求，使软件在迭代演化的过程中始终保持可用状态；
质量管理角度——测试驱动开发使软件获得很高的自动化测试覆盖率，在自动化测试的保护下，通过频繁而小步的重构改善软件内部质量，从而消减软件的频繁改动带来的质量风险。
——P81
2、不同类型的企业实施敏捷的路径区别
华为实施敏捷是从上至下。因为公司有很好的执行力。在经过了试点之后，公司层面就制定了三步走的战略，由小团队至整条产品线逐步推行。
而像腾讯、阿里等互联网企业，更多是由下而上的策略。
这几家公司的程序员都有很好的技术基础，极限编程的那些技术实践在敏捷尝试的一开始就得到了应用。
3、CMMI与敏捷的关系
本书梳理了CMMI在中国的推广历史，与敏捷关系的变化。
CMMI引进中国，是因为我们确实面临着软件工程的问题。但是引入之后，之所以获得广泛的推广，是由于政府的认证补贴政策。在咱们这个土壤中，于是就大量的公司为了拿补贴，进行表演式认证。即使过了5级，其真实能力也不一定达到二级。因此口碑就坏了。
CMMI说了要干什么，对具体怎么干没有详细说。敏捷因为是由具体干活的人捣鼓出来的，所以说的都是具体要怎么干。在开始的时候，CMMI和敏捷似乎有点水火不容的架势。后来敏捷越来越广泛，CMMI就说其本来就是兼容了敏捷的。
作者在谈到敏捷的广泛推广时，列举了好多当时发表的论文。其中也不乏很多只是标题冠以“敏捷”名号的，但从内容中看不出其真的有什么具体实践。这类作者以传统体制内企业居多。（也能够理解，为了发表论文，就得寻找当时的热点。但在体制内企业，即使时至今日要推行敏捷还如此之难，更何况10来年前。）
4、关于CMMI的话题对我引起的一点反思
我以为CMMI是得到了业界公认的、有效的一套体系，不仅在中国，在那些软件行业发达的国家也如此。
但作者说CMMI在发达国家并没有得到公认。
由此我就想到自己能够获取一手资料的重要性。我英文不好，自己从不看英文文献，因此所获得的基本都是二手资料，难以有自己独立的判断。所以学好英文还是很重要的。我曾经还认为如果不想出国，学不学英文不重要，这是多么浅薄的认识。
另外，作者提到了程序员杂志、讨论软件开发技术的网站，我都没有怎么关注过。这么多年来，缺乏明确的发展方向，也就缺乏对某些领域一贯的、深入的跟踪学习和坚持，这是最遗憾的地方。
