敏捷宣言：坚持不懈的追求技术卓越和良好的设计，敏捷能力由此增强

为什么需要团队和技术敏捷力

团队和技术敏捷能力是业务敏捷力的基石，包含：

敏捷团队：高绩效、跨职能团队

规模化敏捷团队：多个敏捷团队在敏捷发布火车（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），确认迭代交付目标

承诺迭代目标

规模化敏捷团队

ART补充角色

敏捷发布火车工程师（release train engineer，RTE）：仆人式领导，负责引导项目群执行、消除障碍、管理风险和依赖关系，以及持续改进

产品管理者：负责“构建什么”，构建内容是根据愿景、路线图，以及项目群待办事项列表中的新特性来定义的。要求是符合期望、技术可行、经济可行，持续发展的产品

系统架构师：定义系统总体架构的个人或团队。在团队或组件之上的抽象层次工作，并定义非功能性需求、主要系统的要素、子系统及接口

业务负责人：ART的关键利益相关者，对敏捷发布火车交付的商业成果负有最终责任

客户：解决方案的价值接受者

系统团队：协助构建和支持DevOps基础设施，从而进行开发、持续集成、自动化测试、准生产系统部署

共享服务：专家组成，如数据安全专家、信息架构师、数据库管理员（DBA）

内建质量

建立流动性

CDP continuous delivery pipeline 持续交付流水线

消除传统的“启动-停止-启动”式项目启动和开发过程，以及阻碍进度的阶段门限

采取“可视化和限制wip，减少批次规模，管理队列长度”、“基于对可工作系统的客观评价设立里程碑”

同行评审和结对

所有工件在被接受或发布前，都要经过多方的观察和审视

集体所有权和标准

任何一个人都可以更改一个工件，增强系统或提高其质量，减少团队之间和团队内部的依赖关系

自动化

将重复性手动任务自动化

将构建、部署和发布解决方案的过程自动化

将持续交付流水线（CDP）中的质量检查自动化

完成定义

定制完成定义（definition of done，DoD），确保表现一致的质量和完整性的水平

符合接收标准

测试是自动化的

所有测试均已通过

满足非功能性需求（NFR）

必须修复的缺陷清零

相关文件已更新

其他计划实践

敏捷架构：通过协作、浮现式设计、意图架构，以及简单设计来支持敏捷开发实践

敏捷测试：每个人都要测试，以小的增量进行开发和测试，并且团队应用测试先行和测试自动化实践

测试驱动开发（test-driven development，tdd）实现代码或组件之前构建并执行测试

行为驱动开发（behavior-driven development，bdd）通过定义和自动化测试解决方案的全部功能帮助团队确保内建质量，还可作为确定、记录和维护需求的方法

重构：更新简化现有代码或组件的设计，而不更改外部行为

探针：用于获取必要的知识，以减少风险、更好的理解需求，或增加故事估算的可靠性