敏捷宣言：坚持不懈的追求技术卓越和良好的设计，敏捷能力由此增强
为什么需要团队和技术敏捷力
团队和技术敏捷能力是业务敏捷力的基石，包含：
敏捷团队：高绩效、跨职能团队
规模化敏捷团队：多个敏捷团队在敏捷发布火车（ART）场景中运作
内建质量：应用实践来创建高质量、设计良好的解决方案，支持当前和未来业务需要
一、敏捷团队
---这部分详细内容可参考ACP文集：https://www.jianshu.com/nb/50057125---
敏捷团队
敏捷开发的基本构件，5~11人跨职能团队，可在较短时间盒内定义、构建、测试和交付价值增量
团队有权力和责任管理自己的工作，以提高工作效率
SAFe敏捷团队角色
PO（product owner，po）：管理团队待办事项，确保反应客户需要
SM（scrum master）：仆人式领导者和教练，导入敏捷过程、消除障碍创造环境，引导高绩效、持续流程、持续改进
团队代办事项
代办事项backlog：包含用户故事user story、使能故事enabler story
混用敏捷方法
如scrum、kanban、xp等
估算工作
数量（有多少）、复杂性（有多难）、知识（哪些是已知的？）、不确定性（哪些是未知的？）
估算的方法：如斐波那契额数列、T-Shirt方法
迭代
定期的、可预测的计划、开发和评审的节奏
PDCA循环（计划、执行、检查、调整）
迭代计划
评审、梳理和估算故事
定义验收标准
拆分为较小的故事（如有需要）
根据已知速度（story points），确认迭代交付目标
承诺迭代目标
二、内建质量
建立流动性
CDP continuous delivery pipeline 持续交付流水线
消除传统的“启动-停止-启动”式项目启动和开发过程，以及阻碍进度的阶段门限
采取“可视化和限制wip，减少批次规模，管理队列长度”、“基于对可工作系统的客观评价设立里程碑”
同行评审和结对
所有工件在被接受或发布前，都要经过多方的观察和审视
集体所有权和标准
任何一个人都可以更改一个工件，增强系统或提高其质量，减少团队之间和团队内部的依赖关系
自动化
将重复性手动任务自动化
将构建、部署和发布解决方案的过程自动化
将持续交付流水线（CDP）中的质量检查自动化
完成定义
定制完成定义（definition of done，DoD），确保表现一致的质量和完整性的水平
符合接收标准
测试是自动化的
所有测试均已通过
满足非功能性需求（NFR）
必须修复的缺陷清零
相关文件已更新
其他计划实践
敏捷架构：通过协作、浮现式设计、意图架构，以及简单设计来支持敏捷开发实践
敏捷测试：每个人都要测试，以小的增量进行开发和测试，并且团队应用测试先行和测试自动化实践
测试驱动开发（test-driven development，tdd）实现代码或组件之前构建并执行测试，tdd是开发实践而不是测试方法，先构建测试用例
行为驱动开发（behavior-driven development，bdd）通过定义和自动化测试解决方案的全部功能帮助团队确保内建质量，还可作为确定、记录和维护需求的方法
重构：更新简化现有代码或组件的设计，而不更改外部行为
探针：用于获取必要的知识，以减少风险、更好的理解需求，或增加故事估算的可靠性
三、规模化敏捷团队
详情：https://www.scaledagileframework.com/organizing-agile-teams-and-arts-team-topologies-at-scale/
ART补充角色
敏捷发布火车工程师（release train engineer，RTE）：仆人式领导，负责引导项目群执行、消除障碍、管理风险和依赖关系，以及持续改进
产品管理者：负责“构建什么”，构建内容是根据愿景、路线图，以及项目群待办事项列表中的新特性来定义的。要求是符合期望、技术可行、经济可行，持续发展的产品
系统架构师：定义系统总体架构的个人或团队。在团队或组件之上的抽象层次工作，并定义非功能性需求、主要系统的要素、子系统及接口
业务负责人：ART的关键利益相关者，对敏捷发布火车交付的商业成果负有最终责任
客户：解决方案的价值接受者
系统团队：协助构建和支持DevOps基础设施，从而进行开发、持续集成、自动化测试、准生产系统部署
共享服务：专家组成，如数据安全专家、信息架构师、数据库管理员（DBA）
