SAFe快速入门

背景与来源

时下，不论是SCRUM，XP，Kanban或他们的衍生变种，各种常规的敏捷在中小团队中往往如鱼得水。然，在复杂的组织中，团队与团队之间的协同总是十分挑战，敏捷有时候似乎不那么不再适用，流程越来越多，响应越来越慢，加班越来越多，交付质量很难跟上，抱怨也越来越多，士气低落。

SAFe是该问题的方案之一。市面上对这类问题有一个统一的称为：大规模敏捷。而常见的应对方案主要有以下几种

1. SAFe
2. LeSS
3. Scrum of Scrums
4. DAD
5. NEXUS

SAFe核心概念

想解决的问题：

1. 精益敏捷领导力
2. 团队和技术敏捷
3. DevOps和Release on Demand
4. 商业解决方案和精益系统工程
5. 精益解决方案管理

方法领域

1. 敏捷
2. 精益
3. devops
4. 系统化思考

7大核心竞争力

1. 精益敏捷领导力
2. 团队和技术敏捷
3. 敏捷产品交付 - 客户与价值为中心
4. 企业方案交付
5. 精益项目组合
6. 组织敏捷
7. 持续学习与改进的文化

组织复杂度级别

team （通常影响单个业务部门）

通常是指单个敏捷小队，负责某个模块或系统，参考scrum team角色组成（主要有PO产品经理，Scrum Master，Scrum Team)

主要角色

1. Product owner
2. Scrum master
3. Scrum Team

主要活动

1. 迭代计划
2. 迭代执行
3. 系统演示
4. 迭代回顾

program （通常影响几个业务部门与几个研发团队）

多个team组成，负责某个产品或方案或某个业务方向，多出主架构、主PO，RTE角色，同时BO也是很关键的角色。多出火车的概念。

主要角色

1. 火车工程师(RTE)：负责一列火车，重视集成
2. 系统架构师
3. 产品负责人
4. 业务负责人：（理想情况下是业务部分，定义要做的系统和出的钱）

主要活动

1. 建立项目，组建团队与启动会
2. PI计划，需要团队成员对要做的事做估算
3. 火车同步，多个敏捷团队之间的同步
4. 系统演示
5. 回顾

工件

1. PI (Program Increment)
2. Release Planning

solution （通常影响多个业务部门与多个研发团队）

概念上和Program类似，但通常跨多个program，多出解决方案级别的主架构，主PO，STE角色；业务负责人的角色名字改成了Customer，因为复杂和投入大，对钱更加敏感；一般会在 "xxx会"中讨论（由中层组成，某些场景下加入特定高层）

常规活动上和Program类似

portofolio

比Solution再复杂，多出Epic Owners/企业架构师。一般是公司高层了，负责企业项目的方向与治理，相对来说，落地过程中跟随他们的情况调整。

和Scrum相比，几个核心词汇

• Agile Release Train (ART): 敏捷火车，通常由多个敏捷团队组成
• Features：满足干系人的功能
• Program Increment（PI）：Porgram的迭代时间，一般是单个团队迭代时间的一个公倍数，同时最好拉齐团队的节奏。
• Program Backlog/Solutioin Backlog：想要构建的Feature; team的backlog从program中来
• Release Train Engineer（RTE）：敏捷火车的负责人
• Solution Train：一般由多个ART构成，在组织复杂解决方案时，需要协调多个ART的情况下；由此也对应了一个Solution Train Engineer
• Value Stream: 价值流 （来源于精益）

SAFe与工具JIRA的集成

Jira是一个项目与任务管理工具，可以在jira中对应的层级的问题描述映射为如下：

1. Story
2. Feature
3. Capability
4. Epic 同事每个层级再做自己的board, kanban与filters