Take Away-敏捷notes

Volatility 波动 Uncertainty 不确定性    Complexity 复杂   Ambiguity  模糊

Vision   愿景 Understanding 理解     Clarity  清晰     Agility 敏捷

Ø 十二大原则

1. 我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。

2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。 

4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。

5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

7. 可工作的软件是进度的首要度量标准。

8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

10. 以简洁为本，它是极力减少不必要工作量的艺术。

11. 最好的架构、需求和设计出自自组织团队。

团队定期地反思如何能提高成效，并依此调整自身的行为表现。

Ø 四大价值观 4大宣言

个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

Ø 3 大角色

Product Owner （PO）PO是了解客户需求以及相关商业价值的团队角色，作为客户代表，定义产品功能，决定产品发布的内容和日期，对产品的投入产出负责。根据市场变化对需要开发的功能排列优先顺序，合理调整产品功能和迭代顺序。

Scrum Master (SM) 敏捷教练SM 将帮助团队消除任何阻碍团队生产力的障碍，SM的角色是培训和激励团队成员。他起到教练的作用。

Development Team （Dev.Team）开发团队由关键开发者或架构师等5-9人组成，他们各有职责但又是多面手，能独当一面又能互相支持。他们在敏捷开发在不断的组织和管理属于自己的工作，由此产生的协作力将优化团队的整体效率和能力。

Ø 5 个会议

1.产品梳理会：30min.拆分历史，分析并排列用户故事，经过分析将不明确和待完善的地方加以完成，以免将这些残余问题留到迭代计划会上。

2.迭代计划会 Sprint Planning Meeting，1-2h。选择本次迭代的目标并给出工作量估算。

3.每日站会 Daily Scrum Meeting

会议主要讨论三个问题：

-        昨天做了什么?

-        今天将要做什么?

-        有需要帮助的地方吗?

4.迭代评审会 Review Meeting

5.迭代回顾会 Retrospective Meeting

Ø 构建敏捷文化（目标）：文化→价值→原则→实践→工具

优化我们的思维和行为模式，减少不必要的时间浪费，提高产品的市场满意度：MVP

MVP - minimum viable product，最小可行产品

以最简易的产品形式进入市场试错，多犯错、早犯错，然后根据错误对产品进行快速迭代。以最小的时间成本和金钱成本去试错，从而换取在市场中的快速成长的机会。

做产品的时候，很容易脱离实际的市场，而市场的变化是十分迅速的，一个“完美方案”不应该是在脑子里想出来的，而应该是切合市场，从实际的市场需求和反馈中推演出来的。

Ø Design Thinking（工具）

用户视角

设计思维五大步骤

同理心（Empathize）—— 研究用户的需求

定义（Define）—— 陈述用户的需求和问题

构思（Ideate）—— 挑战假设并创造想法

原型（Prototype ）—— 开始创建解决方案

测试（Test）—— 尝试您的解决方案

Ø Backlog 管理（工具）需求管理 或 Job 管理方法

Ø  Waterfall PRD 文档 VS Scrum Backlog

Waterfall PRD传统的瀑布工作模式使用详细的需求说明书来表达需求，需求人员负责做需求调研，根据调研情况编制详细的需求说明书，进行需求评审，评审之后签字确认交给研发团队设计开发。在这样的环境下，需求文档是信息传递的主体，也是一份契约。然而这种详细的PRD 文档有以下5大弊端：

1. 单向的信息传递，容易出现理解偏差。

2. 文档很正式，我们会误以为它一定是对的，不去质疑它，让我们停止作出判断。

3. 有了详细的文档，我们不会反复讨论它，相互确认。

4. 书面文档不利于团队共享责任，它扮演了证据的角色。

5. 编制详细的、表达准确需求文档需要花费大量的时间，如果需求变化频繁，维护成本更高。

Scrum Backlog敏捷使用产品Backlog来管理需求，产品 Backlog 其实就是一个优先级排序的需求清单，优先级的需求在 Backlog 的最上层。更强调团队共享责任，团队会用10%的时间梳理工作。共同目标是通过讨论协作，正确理解需求之后把这些需求变成客户真正需要的功能，而不是单向的任务传递。

1. 详尽适当（高优先级的比低优先级的技术更详细。优先级越低，细节越少）

2. 可估算（以故事点或者理想人天形式表达）

3. 演化（根据用户的不断反馈，识别出新条目会被加入Backlog里面

4. 按优先级排序（所有条目都是按照优先级排序的，最重要、优先级最高的条目最先实施，一旦完成，便从 Backlog 移除。纸质卡片）

Ø 敏捷会议原则（工具）

ü 明确会议需要达成的目标

ü 明确时间和日程 - 控制时间 40分钟以内

ü 提前通知和准备

ü 讨论行动方案，而非问题

ü 会议要得出结论 - 发出会议纪要和行动计划