敏捷
XP和scrum作为敏捷开发里面最重要的两种思想，相辅相成的发展了20多个年头。要了解这两种方式的本质，要先了解发明人。XP的发明人Kent Beck来自美国的软件工程师，TDD（测试驱动开发）的推崇者。在软件领域最出名的是他的Junit单元测试框架。Jeff Sutherland和Ken Schwaber共同发展了scrum的敏捷理念。Jeff Sutherland毕业于西点，11年的军旅生涯里面当了医生，随后涉及到IT领域. Ken Schwaber软件工程师，产品和工业的咨询。
在这里我们可以了解到Kect Beck更偏向于技术，所以在XP里面除了价值，原则外，更看重各种开发的实践。而scrum则更偏向于人，团队，流程。所以我们采用的敏捷一般是XP和scrum的混合方式。既有XP里面的开发实践，也有scrum的关于人，团队，流程的框架。这两种理念相辅相成，共同发展，形成了今天的敏捷。
小规模的敏捷
在90年代末期，没有现在的云计算，没有大数据，没有docker，k8s。受限于当时的软件技术和规模。XP和scrum在当时的环境下不管从价值观，原则和可以落地的工程实践，都比当时普遍采用的瀑布开发方式好上太多。在2000年后敏捷开发方式开始一步一步成为主流的开发方式。后来持续集成，持续交付，精益开发，用户故事地图，实例化需求的发展进一步加强了敏捷的各个部分。
在当时的背景下，采用组织架构的重新划分，以及架构的持续演进，就可以从component team,变化为feature team. 在feature team里面，团队之间依赖少。所以一个个独立的团队自己采用XP和scrum方式进行持续改进。整个组织的交付效率和质量得益于不断提升的单个团队。
唯一的不变就是变化，这句话时刻提醒着我们。随着时间推移，软件的规模越来越大，SaaS，PaaS，大数据，中台化等技术和组织架构的变化。使得小而美的敏捷团队遇到了前所未有的挑战。
规模化的敏捷
软件规模变得越来越大后，遇到的首要问题是团队间需求的依赖问题。一个完整的具有用户价值的功能现在无法由一个团队完成。有时需求会横跨3，4个团队，甚至7，8个团队。团队间就像以前的component team一样依赖起来。整个开发的过程变得臃肿，反应变慢，反馈周期变长。这样敏捷团队的价值观和原则被现实打破。怎么才能短，快的交付有价值的需求，得到反馈，使敏捷的价值重现。所以后来出现了规模化敏捷的思考，就是基于现状找到可以解决的方法。不管从safe，还是less，或者Scrum@Scale,其实本质就是解决两个核心问题。
第一个问题就是：需求怎么对齐，其实也就是依赖团队间目标怎么对齐，怎么协同开发？
第二个问题就是：随着软件规模扩大，团队，团队人数怎么扩张？
针对第一个问题的本质是，如果无法解决团队间开发依赖问题，那么通过在依赖团队间建立统一的product backlog和统一迭代起止时间的方式进行缓解。统一的product backlog可以解决团队之间需求排序优先级的问题，再加上团队之间迭代的起止时间变得一致性，提升沟通，联调的效率，降低协作的成本。
针对第二个问题，还是考虑到团队人数开始变多，沟通渠道变宽，团队整体的透明性，沟通效率变差，团队变得迟缓。所以通过保持小而美的团队，通过一层层把小团队聚合起来，形成更大规模的团队群。上层团队之间的协作依靠团队代表成员（PO代表，scrum master代表，技术代表，测试代表等）进行沟通协作，来提升沟通效率。
当软件规模更大后，所有的规模化方法都是解决协作的问题，沟通效率问题，解决这类问题本身会产生更多的成本（相较于以前的小规模敏捷团队）
所以当组织达到一定规模化，进行敏捷的方式要进行相应的调整，根据每个组织的独特性一般有以下几点:
- 优先解决团队开发的依赖
- 通过统一product backlog
- 统一团队迭代进行依赖缓解（比如集中多个团队的sprint plan）
- scrum of scrums, scrum of scrums of scrums(或者其他方法用于同步团队间的进度)
- 集体团队回顾（持续改进团队依赖问题)
- 持续交付基础设施的完善
说了那么多，其实规模化敏捷也属于一直在探索的道路上，在这条遍布荆棘的道路上，一定要坚持敏捷的价值观和原则，找寻到适合自己组织和团队的方法。