在图的最下方灰色的横条是实施SAFe的基础，包括如下内容：
https://blog.csdn.net/wejiyu/article/details/105454644
PI计划（项目集增量计划）：这是SAFe中非常重要的一个计划，它为ART提供了决策，并且将业务和技术目标进行统一；实际上PI计划和ART处于同一层级。
IP（创新和规划）冲刺：创新和规划会发生在每个PI，并且会有多个目的。它扮演了满足PI的目标的缓冲，并为创新、继续教育、PI规划，以及检视和适应提供了专用的时间。IP冲刺活动实现了许多精益敏捷的原则，这些原则可以使业务敏捷性。
在SAFe的敏捷团队中，包括了两个关键的角色，一个是 Scrum Master；另外一个是Product Owner。
项目集增量（PI）目标是敏捷团队或者火车为即将到来的项目集增量中要达成的商业和技术目的的摘要。在PI规划中，团队要创建PI目标，下图为团队PI目标。
https://blog.csdn.net/wejiyu/article/details/105454711?depth_1-utm_source=distribute.pc_relevant.none-task-blog-OPENSEARCH-2&utm_source=distribute.pc_relevant.none-task-blog-OPENSEARCH-2
用户故事
一、什么是用户故事
用户故事描述了对用户、系统或软件购买者有价值的功能。一个好的用户故事包括三个要素：
1.角色：谁要使用这个功能。
2.功能：需要完成什么样的功能。
3.价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：
英文：As a <Role>, I want to <Activity>, so that <Business Value>.
中文：作为一个<角色>, 我想要<功能>, 以便于<商业价值>
举例：“作为招聘网站注册用户，我想要查看最近3天发布的招聘信息，以便于我看到最新的招聘信息”。
由于用户故事的描述信息以传统的手写方式写在纸质卡片上，所以Ron Jeffries(2001)对这三个方面称为3C：卡片(Card)、对话(Conversation)和确认(Confirmation)。
卡片（Card）：用户故事一般在小卡片上写着故事的简短描述，工作量估算等。
交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
确认（Confirmation）：通过验收测试确认用户故事被正确完成。
二、如何编写用户故事
故事应该很清晰地体现对用户或客户的价值，最好的做法是让客户团队来编写故事。客户团队应包括能确定软件最终用户需求的人，可能包括测试者，产品管理者，真实用户和交互设计师。因为他们处于描述需求的最佳位置，也因为随后他们需要和开发者一同设计出故事细节并确定故事优先级。
为了构造好的用户故事，我们关注六个特征。一个优秀的故事应该具备以下特点：
独立的（Independent）— 我们要尽量避免故事间的相互依赖。在对故事排列优先级时，或者使用故事做计划时，故事间的相互依赖会导致工作量估算变得更加困难。通常我们可以通过两种方法来减少依赖性：1.将相互依赖的故事合并成一个大的、独立的故事；2.用一个不同的方式去分割故事。
可讨论的（Negotiable）— 故事卡是功能的简短描述，细节将在客户团队和开发团队的讨论中产生。故事卡的作用是提醒开发人员和客户进行关于需求的对话，它并不是具体的需求本事。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
对用户或客户有价值的（Valuable）— 用户故事应该很清晰地体现对用户或客户的价值，最好的做法是让客户编写故事。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
可估算的（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：1.开发人员缺少领域知识；2.开发人员缺少技术知识；3.故事太大了。
小的（Small）— 一个好的故事在工作量上要尽量小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
可测试的（Testable）— 故事必须是可测试的。成功通过测试可以证明开发人员正确地实现了故事。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：用户必须觉得软件很好用。
https://www.cnblogs.com/jetlian/p/3576170.html
Scrum of Scrums
Scrum Masters拉通会 :每周一和周四的早上10:00
Inspect & Adapt
检查和调整会 （含PI Demo）
团队
请大家关注早上的业务部分的分享，并不是所有团队的PI目标都是来自特性的。
请主动和其他团队紧密协作，确保能识别和解决依赖关系。
Scrum Masters【服务型领导】:
你的责任是管理时间盒，依赖关系和模糊不清的事项。
1、注意维持会议秩序
2、提出有效的问题，帮团队达成一致。【当大家在一个Story上纠缠不清时，要从整体进度角度跳出来推进整体进度】
3、不要加入自己的观点。【不要批评人】
4、关注每个人的情况
Product Owners
你可能会有不清楚的事项，请和product managers和架构师们，梳理清楚你的待办事项。
1、耐心回答团队的问题
2、注意分辨假设和事实，提供更多的事实，找出方法验证假设
3、注意团队提出的风险
4、用例子帮团队理解
PO会，梳理并解决需求之间的依赖问题
SM会：把握进度
不承诺的【不是有时间就做的】：难度的、依赖比较多的。是为了维护可预测性
只答应可以交付的。做一个靠谱团队
验收标准Dod,以终为始来估时
提升竞争力：服务能力，支撑的效率
1个投诉背后，可能有20个懒得投诉。 复购
可视了，客户、老板 才觉得靠谱
响应式的需求。超过50%的时间并非是重点项目
每个迭代每个人8个点。即除了开会预留8天时间。开发半天+测试半天，一个点
数据量化，优化多少？
觉得你的问题，是否得到回答
问问题的初衷
是否已经拉通的标志
相互支撑的团队
PO在讲需求时，让研发直接估故事点，这会比较难，比较耗时。PI planing时用户需求已经给研发评审过了
业务价值【排优先级】，即在时间有限的情况下，帮助团队做决定
