敏捷的3355

3个角色

Product Owner：主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。

作为产品负责人，PO清楚地知道产品的愿景，需要对产品待办列表的梳理、优化、优先级排序等负责。PO决定Why和What，一般可以对应为我们理解的产品经理和业务分析师的角色。

Scrum Master：主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍， 一般可以对应为我们理解的项目经理的角色。

Scrum Team：主要负责软件产品在Scrum规定流程下进行开发工作。每位成员可能负责不同的技术方面（开发、测试），要求团队有很强的自组织能力，能够交付一个端到端的真正对客户有价值的产品。

3个工件

Product Backlog：PO首先将需求按照优先级进行排列，产生一个Product Backlog。作用类似于传统开发中项目经理确定需求文档。产品待办列表就是产品的“What”。PO通过“讲故事”的方式，让团队理解产品的目标，帮助整个团队对用户故事有充分和统一的理解。

Sprint Backlog：有了Product Backlog列表，我们需要通过Sprint Planning Meeting（Sprint计划会议） 挑选出用户故事（Story）作为每次迭代完成的目标。

潜在可交付的产品增量：要求每一个Sprint结束都产生用户可用的软件，也被称着“潜在可交付的产品增量”（Potential shippable product increment, PSPI）。能否每个Sprint生成满足质量定义的PSPI 是Scrum 执行效果的试金石。

因此这里关键的是团队内有一致同意的DOD（完成的定义），基于其中的内容来判断是否迭代内所有东西都做完了。

同样，随着时间推移，团队DOD内容会不断修改完善 。“潜在可交付”并不意味着构建出的东西必须实际交付，交付是产品负责人的业务决策，基于发布计划来确定。

五个活动

Sprint Planning（IPM）：Sprint计划会议在Sprint一开始召开。PO和团队共同决定计划在这个Sprint完成哪些用户故事。

Daily Scrum Meeting（Standup）：每日站会，一般在15分钟以内。团队成员相互交流任务的进展，计划以及遇到的困难。

Sprint Review（Showcase）：Sprint评审会议发生在Sprint将要结束的时候。团队和客户一起评审本次Sprint的产出是否达到预期。

Retrospective：回顾会议发生在Sprint的最后，由Scrum Master负责召集团队召开。会中大家回顾和小结这个Sprint做的好的地方以及有哪些不足。保证团队能够持续改进，不断提高。

Backlog Refinement：Product Backlog的梳理，可以发生在整个Scrum周期的任何时间。

Scrum的精髓

亨里克.克里伯格（Henrik Kniberg，资深敏捷教练，《精益开发实战：用看板管理大型项目》的作者）从更深层次解析了Scrum的精髓，提出了Scrum的本质上有三个拆分和两个优化。

Scrum的三个拆分

拆分组织：把组织拆分成小规模、跨职能的自组织团队。

拆分产品：把工作拆分成一系列小而具体的交付物，按优先级排序，估算每项任务的相对工作量。

拆分时间：把时间拆分成固定大小的短迭代（通常为1~4周），在每个迭代结束时对可交付的产品增量进行演示。