站在自己的角度总结培训笔记，保护隐私，来源不注明。

WHY

当前时代的挑战——乌卡VUCA（Volatility 易变性, Uncertainty 不确定性, Complexity 复杂性, Ambiguity 模糊性）

Cynefin模型（一种领导者决策模型框架），根据因果关系提供五种场景：

Simple 简单
Complicated 繁杂
Complex 复杂
Chaotic 混乱
Disorder 失序

应对复杂系统往往有这些建议等：

fail fast, fail better
缩短反馈周期
不能忽略的人性因素

WHAT

敏捷宣言4 + 敏捷原则12：可参考

个人和互动优于流程和工具
人被认为是最重要的因素。团队专注于个人和互动。这种价值促进了项目的自我管理和共享所有权。
工作产品优于综合文档
此价值侧重于交付工作产品/软件。文档是必要的，但如果没有可用的产品，它是无用的。团队不应该让文档过程分散他们生产工作产品的注意力。
客户协作胜过合同谈判
业务需求频繁变化是正常的，所以一开始就把所有事情都放在合同之下是不现实的。双方（团队和客户）必须灵活地接受产品变更。团队应与客户密切合作，以实现共同的愿景和目标。因此，双方需要建立互信并进行灵活的合同。
响应变化而不是遵循计划
要求通常会根据客户的需求而变化。因此，从项目一开始就制定具体的计划是无效的。建议在开始项目时制定一个高层计划。接下来是更多信息：不时获得的产品相关知识，产品待办事项中的改进功能，以及基于优先级的项目实施。为此，建议每个团队成员都参与规划产品待办事项。
我们的首要任务是通过早期和持续交付有价值的软件来满足客户。
欢迎不断变化的需求，即使是在开发的后期。敏捷流程利用变化来获得客户的竞争优势。”
频繁地交付工作软件，从几周到几个月不等，优先考虑更短的时间范围。
业务人员和开发人员必须在整个项目中每天一起工作。
围绕有动力的个人建立项目。为他们提供所需的环境和支持，并相信他们能够完成工作。
向开发团队和在开发团队内部传达信息的最有效和最有效的方法是面对面交谈。”
工作软件是进度的主要衡量标准。
敏捷流程促进可持续发展。赞助商、开发人员和用户应该能够无限期地保持恒定的步伐。
对卓越技术和良好设计的持续关注提高了敏捷性。
简单——最大化未完成工作量的艺术——是必不可少的。
最好的架构、需求和设计来自自组织团队。

老师给了一个乒乓球传球视频，生动解释了什么是真正的效率：资源效率no，流动效率（交付）yes！

敏捷不是一种项目管理方式，它是一个价值观，可以用在除了项目管理以外的其他方向

Scrum框架

Scrum方法是敏捷Agile的常用框架，其他更少用的框架例如kanban和XP。

还有一些规模化Agile框架：

SAFE Saling Agile Framework
Spotify
Less
Scrum@scale

Scrum框架实践

三个角色

Product Owner 产品负责人（不一定是产品经理）
Scrum Master 敏捷教练
Scrum 团队（包括开发、测试人员、设计人员、用户体验 (UX) 专家和运营工程师等等）

三个工件

Product Backlog 产品待办事项
Sprint Backlog 迭代待办事项
增量

三个支柱

透明
检视 inspect
调整

五个价值观

focus 专注
courage 勇气
openness 开放
commitment 承诺
respect 尊重

五个事件

计划
站会
迭代
评审
回顾为何梳理不算事件：因为需求梳理随时可发生，不需要单独开个会

关于迭代

迭代是时间一到就结束/开始，与实际项目进度无关。一般时间段固定，不能提早/拖后结束。“发布”与迭代无关，是按需发布（一般PO决定）。迭代与“会议”的关系：

迭代第一天，开迭代计划会
中间：每日站会
最后一天，开迭代评审会（review），评审产品增量是否符合期待，获取反馈
最后，开迭代回顾会

如何在人数多的团队开站会

可以选择这种策略：

先开大会
各自小组开
各小组再分别进行总结

回顾会特点

拒绝外部参加（如其他团队、老板），因为主打开诚布公
最难开的一个会
定的行动项，需要是具体、可落地的
多问WHY

DoD vs DoR

DoD (Definition of Done)：质量层面 DoR (Definition of Ready)：就绪的定义，指的是这个需求被所有人理解了，才能被计划到迭代里

用户故事

用户故事是从需要新功能的人（通常是系统的用户或客户）的角度对功能进行简短的描述。格式可以是：作为WHAT，我想要一些WHAT，因此WHY。

3C原则：

Card 卡片
Conversation 对话
Confirmation 确认

自管理团队

自由和成熟度的平衡