这是一篇读书笔记，也是在翻译本书过程中，对重点的摘录。
本书不仅展示了REST是一种适合于构建面向服务解决方案的媒介，同时也展示了面向服务的架构模型是能够充分发挥商业潜力的REST风格的技术架构的坚实（通常也是必要的）基础。
Code Retreat，一个在没有工作压力下让人锻炼写Code技巧的活动，本次天津站在天津华苑站吶吧咖啡厅，由敏捷教练 – 申健带领大家进行。
当天到场参与的有将近20人，除了实践了结队编程（Pair Programming）以外，也尝试了TDD的作法，除了多数人使用的Java以外，也有使用C++的同好参与。虽然因为时间的因素没有进行难度太高的课目，但是每个人都扎扎实实的练习了一把，也都一致表示收获丰富，下次有一样的活动必定参加～～～^^
1.活动场地：吶吧咖啡厅，论场地、论气氛，还有美女程序媛n名，各方面天津场都完胜！！天津果然是过日子的地方啊～～～
顶尖金融服务企业中的大型组织是如何采用大规模Scrum框架(LeSS)的？
J.P.摩根的全球核心处理技术集团由Simon Cooper领导，是一个遍布全球的3000多人的组织。2013年集团决定要改变为(真正的)Scrum，并采用Large-Scale Scrum(LeSS)框架，这意味着在组织设计要做出相应改变。
之前他们曾零散地采用了”Scrum-But”及各种敏捷工程技术，主要是在开发团队中，但现有的权力和组织结构并无显著改变，与业务的交互也是一样——仍然是“合同谈判”而非“客户协作”。仍然存在负责交付“合同”的研发项目经理、团队主管、单一职能的专家角色，以及单独的组件团队和职能团队（比如测试团队）。
年初Craig与Simon Cooper及其直接下属的经理做了一次有力的对话，随后他们就决定将组织设计转变为基于LeSS的Scrum框架。
这次领导力对话认清了组织中目前“合同游戏”的动态，它阻碍了组织提高敏捷性和改善以客户为中心的特性交付。
这次领导力对话也针对真正的特性团队进行了探讨——跨组件和跨职能团队，它可以端到端地交付客户特性，不存在移交、依赖或延迟。这需要消除组织内的藩篱，比如职能部门和组件团队，以及相应的经理角色。
过去的几十年间，人们曾用过测试先行的方式，但20世纪90年代才真正提出测试驱动开发的方法。
BDD源自一些TDD实践者在寻求更好的词汇来描述在TDD循环中测试的意图。
英国人Dan North在2006年发表了《Better Software》的文章，首先意识到了TDD思想和”测试”一词会误导人们。Dan将这种风格的TDD命名为行为驱动开发，成功地将测试先行编程推进了一步。
由于test一词并没有抓住指定期望行为的精髓，它反而承载了太多的含义。相反，社区开始谈论specifications(需求说明，简称specs)和行为，而非测试与测试方法。
今天的BDD语境和领域远远超出了代码——最引人注目的是将BDD提升到需求层面，与业务分析和需求行为结合起来。
长期维护的特性分支，这种做法会为每个新的大型特性或项目建立一个分支，仅当准备发布时才合并回到主干上。看似可以独立地开发每个特性，互不干扰。不幸的是，软件系统是如此复杂，随着主干与分支渐行渐远，接下的合并工作本身将会成为一个项目，带来无数的新缺陷，这真是一场噩梦。
当团队需要同时支持多个客户的不同需求时，版本控制仓库中很可能为此存在了许多分支。这显然会造成大量重复浪费以及高昂的维护成本，在临近产品发布时带来巨大风险。
2011年，@申导 进入某银行的网上银行工作。由于各国市场环境、政策法规等原因，以借记卡为例，看似相同的业务和账户，其背后的处理逻辑和外部集成系统可能都是不一样的。
当时的代码库中，多个国家的代码互相拷贝，由不同组维护，各有自己的思路，虽然最早是同一个基础框架发展而来，但短短几年后各自结构和规范差别越来越大。比如，页面login有的在iframe里，有的不在。相同的修改需要到处merge，例如安全性补丁，回归测试工作量大。
秋天，他所领导的敏捷团队开始开发新一代手机银行项目，目标是用同一代码库来支持多个国家的业务需求。
传统的产品待办项列表(Product Backlog)相对于传统管理办法是一个巨大的进步，但是仍然存在一些问题：
在我给客户提供需求培训和教练服务时，以及在各种敏捷社区活动中，被多次问到scope fixed，deadline也fixed的时候，团队被强制“承诺”必须完成全部需求，此时除了抱怨还有其它方法吗？我把这类问题定义为“固定范围、固定交付日期情景下团队盲目做出不能实现的承诺，如何改善”的问题。
除了背地里大骂那些经理们无知之外，我们真的无计可施了吗？非也，”THERE IS ALWAYS A WAY OUT”， 我整理了下我在不同场合的回答和思考，做成了一个脑图，敏捷教练不传之秘也，供大家参考。
更多敏捷教练经验观点见 https://www.uperform.cn/blog-article/
某些公司对安全性有着较高的要求。在传统瀑布模式下，会有阶段性的安全检查milestone。但是在引入敏捷，每个迭代都需要交付，满足DoD。那么，security是否也应该是DoD的一部分？如何将安全性要求融入每个短迭代中呢？
参见下列脑图中的一些思考。
更多敏捷教练经验观点见 https://www.uperform.cn/blog-article/
组织导入敏捷往往更加关注形式和标准化，然后却发现不同团队的接受程度不同。 这里介绍了Spotify 的大规模敏捷之路。Spotify是继Pandora之后，国外第二大音乐媒体网站，在从6个人扩张到1200人的过程中，它使用一种了新型的矩阵组织来扩展：部落、分队、分会和协会。
