一张图看懂 Scrum

Scrum 工具包括：3个角色、3个工件、5个活动和5个价值观。

3个角色

01 Product Owner：

职责：

清楚知道产品的愿景，分为近期和远期。

清楚愿景才不至于被干扰带偏道路，才可以清楚的区分重要紧急、重要不紧急、不重要紧急、不重要不紧急事件。我们可以集中精力于重要不紧急事件，这样就能减少重要紧急事件的发生。

获取外界的诉求并进行整理成 User Story。

外界：用户、运营部门、其他业务方

User Story：需要实现的功能，以客户的角度，描述「我需要功能A，来达到我的什么目的」。

对整理好的 User Story 所需要的资源进行各方协调并得出「是否可行、什么时候可行」的结论。

一个功能的实现，有时候牵涉各个业务系统，往往各个业务系统所对应的Team排期是不一样的，就需要提前进行沟通。尽最大努力避免在开发的过程中才发现问题，这时候才和其他业务系统沟通影响面就很大，其他业务系统人员很可能拒绝进行协助，业务紧急强行协助导致会打乱了其他团队的开发计划。

根据产品的近期目标，对 User Story 进行优先级排序；期间有更好的 Idea 需要对 User Story 优化，这是一个持续的过程。

注意：Story 的优先级只能有一个1，一个2…一个10。不要把这些功能放得同等重要，这期都得全部实现，全部都是1，这样的做法就失去了优先级的意义。仔细的思考，斟酌，比如问自己「少了这个功能会有什么影响——公司会因此损失100万吗？公司会倒吗？」，有时候并没有想的那么紧急，只是先入为主的思想陷入了局限的泥潭失去了大局观。最后一定是能够得出一个唯一序列的优先级排序的。

需求从外界到 PO 手里的时候，不应该一味地紧缩一线开发人员的时间。PO 的责任不能仅仅是满足外界的诉求，还应该考虑 Team 人员的工作状态和情绪，他们可是实现你「蓝图」的一线人员。（公司所有人都致力于目前公司的蓝图，PO 正是在推动着这张大蓝图中的某个模块。）因此 PO 应该全面考虑团队的目前状态，有时督促团队全速前进，有时应该是 Team 的保护伞，这些都是为了实现公司蓝图更好、更快的前行。

初步决定 Team 每个 Sprint 要完成哪些 Story 任务。

这里只能是初步决定，精确的结果需要在下面的 Plan Metting 中 Team 对其进行时间评估，最后根据该个 Sprint 的任务饱和度，进行 Story 的裁剪或增加。有许多情况并非如此，「这个 Sprint 整理的所有的需求都要实现」，没有考虑过公司现在 Team 所配备的资源情况和完成能力才会有这样的决定，这也往往导致了产品——开发之间的诸多矛盾。心理活动，产品：「这么简单的功能都完成不了」，开发：「你行你来呀」。诸多时候我们以 5000 多年以来的人文素养平息了这场风波，妥协的结果就是质量堪忧甚至完不成任务。

在一个 Sprint 开始后结束前，如果有紧急需求进入，需要站出来保护团队，因为往往很多需求都是认为很紧急而已。

尽量避免 Team 受外界影响，这时候插入紧急需要往往会打乱开发节奏，从而引发各种问题和风险。这个「紧急」需求，如果经过讨论和仔细分析后，大家得出的结论还是是紧急并重要的话，那么这个需求形成的 Story 就需要插入此次 Sprint，优先级列表在这个时候就起作用了，可以在此次 Sprint 的优先级列表中移除一些低优先级 Story。

02 Scrum Master：

职责：

协助 Product Owner 整理需求。

开发是最熟悉每个业务流程以及可能的牵涉方的，要完成列表中的 Story，需要协调哪些资源，以及协助评估现在的资源能否顺利完成这些 Story。

作为 Scrum Team 的带头人，需要确保团队的合理运作，清除 Sprint 开发中的障碍，引导 Team 高效的完成每日工作。

组织团队工作，sprint planning meeting、daily standupo meeting、sprint review、retrospective meeting 组织各项会议的开展（该四个会议在5个活动中会详细介绍）。

帮助大家接收敏捷的理念，推动团队按照敏捷价值观和原则所倡导的方法做出决策。

不要过高估团队的适应能力，当然也不要过低评估团队的适应能力。推行敏捷定是一个长期的过程，Team 人员有着不同的工作经历，不同的公司不同的文化背景，以及现在公司的企业文化影响，推行一套理念都需要专注于明确的目标（Focus）、反馈（Feedback）、纠正（Fix）——简称为3F原则，然后依此循环，长期的反复的过程。

尽量保证团队在每个Sprint中不被打扰。

如果发现有发现影响团队工作的任务来临，要敢于说「NO」，如果确实是重要紧急的需求，而该 Sprint 工作量已经饱和情况，就有必要协商移除之前优先级最低开始的User Story，以保证工作的顺利进行。

03 Team：

职责：

学习和使用敏捷的理念，反馈工作或流程中存在的问题，甚至提出解决方案。

积极去推动任务的进展，提高自我执行力。

高效的沟通，尽量避免通过第三方传达的沟通方式。

高质量的完成 Sprint 开发需求，按期交付。

3个工作

01 Product Backlog：

指有优先级的产品待办事项列表。Product Owner 收集来自于各方的需要、期望、诉求等等，并整理成 User Story 表达形式到产品待办列表中，评定优先级。

02 Sprint Backlog：

每个 Sprint 的任务开发列表 。

03 Burndown chart：

燃尽图，能够直观的看到在每个 Sprint 剩余工作时间和任务完成情况，有效的把控 Sprint 功能交付的风险。

5个活动

01 Sprint：

冲刺（有的公司叫班车，从起点站发车，到一站后需求完成下车，新需求上车，迭代的过程以此往复），一个固定的时间周期（通常为2w~4w，新项目可以是1w）。

02 Sprint planning meeting:

通过会议得出的本轮迭代任务。Sprint 开始的时候，Product Owner 、 Scrum Master 和 Team 根据团队的资源和能力，从 Product Backlog 中按照优先级选取这个 Sprint 要做的 User Story，并且对 Team 提出的问题进行解释和澄清，最终形成本轮的 Sprint Backlog。Team 负责将这些 User Story 拆分成一个个小的 Task，给出完成每个 Task 的时间估算，一般可在 6 小时内完成(6小时一般是一天的高效时间，其他时间可作为 Buffer)，达到可量化。

03 Daily standup meeting:

每日站会，一般选在早上，15分钟左右。每个人讲述进展情况（昨天做了什么，今天准备做什么，遇到什么问题），遇到了 Block 的问题，需要 Scrum Master 出面来扫清障碍保证 Team 能够专注的完成任务。这样能够及时的暴露出开发过程遇到的问题，能够的有效的评估风险以及及时讨论解决方案。通过这样透明化的披露，可以将个人和他人的工作结合起来，会更好的考虑自己的工作是否会影响别人。通过每个人进展的汇报，整个 Team 随时可以了解到离完成我们的 Sprint 目标还有多远。

每个人主动在 To do（准备做）一栏中的选取今日要完成的任务放入 InProgress 一栏并且开工，第二天立会继续按此勾兑，同时将已完成的任务放入 Done（完成）一栏，Blocked 项 Scrum Master 会负责跟踪，和扫除障碍。

04 Sprint review：

在 Sprint 周期结束，需要进行一次评审会议，向 Product Owner 和利益相关方展示完成的功能。回答利益相关者的问题，并记录期望的更改。评审会议可以让其他人了解团队在做些什么，并得到反馈。

05 Retrospective meeting：

回顾会议，通常在 Sprint reivew 会议之后开始。回顾会议是团队内部针对本次 Sprint 内发生的做的好的进行累积，可以改进的、存在问题的作为 Fix 项， Fix 项作为下一轮Sprint任务，也就是持续累积和改进的过程。将好的吸取，不好的改进，那么流程就会越来越完善。

5个价值观

团队内在的灵魂

01 专注：

只专注于每个 Sprint 要完成的事情，团队和个人的能力和精力都是有限的，在有限的时间内专注于最有价值的事情，以取得好的结果。

02 勇气：

团队完成任务的过程中肯定都会遇到一些棘手问题的情况，要有勇气去挑战和面对。

03 公开：

Sprint 的进展，遇到的问题，阻碍都应该对所有人可视化，透明的。这样的团队才能彼此了解，彼此尊重，同时也能暴露问题。

04 承诺：

团队在 Sprint 开始的时候做出承诺，并在迭代中全力完成，达成功能交付。

05 尊重：

尊重各个团队以及团队的人员。不要越界（超出了自己的范畴）议论，「产品觉得这么简单的功能还要那么久才能完成」、「开发觉得 UI 怎么设计得这么 Low」、「UI 觉得这么简单的效果你们都做不出来」等，我们要相信他人能够在这个岗位上就有胜任的能力，要相信他的专业能力。

结语

采取高效的沟通方式，除非情非得已，不要由中间人转接你们各自的诉求，直接沟通，减少交流成本。

Scrum 只是一套工具，实施主要还是看人。其中的流程并非一定完全硬套，工具是死的，实施的人是活的，当然是可以根据公司的情况对某些流程进行调整、替换、甚至删除，总结一套适合团队的流程最要紧。最重要的是定下一套流程规则，然后遵守这套规则，循环往复的发现问题和解决问题，完善流程。