Scrum 简介

---

概览

基本概念

Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。

Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法：Scrum of Scrums. ——百度百科

历史与现状

以下列两大数据来谈谈Scrum的前世今生：

• 这是一种由 2 位美国人——Jeff Sutherland和Ken Schwaber共同创造的一种开发方式
• 全球 56% 的公司采用Scrum这种开发方式

注意，以上说的是公司，而不只局限于软件开发公司，其泛用性使其可以被运用于各行各业，零售、军事、风险投资都会成为Scrum出现的地方。

常用开发方式

对比

开发方式 约束条件 使用率 XP 12 10% Scrum 10 56% Kanban 3 5%

（数据统计：Henrik Kniberg）

另外两种方式不做赘述，详情可自行询问度娘，以下传送门： 极限编程(XP) 和 看板管理(Kanban) 。

值得一提的是，XP和Kanban这两种开发方法并非一无是处，相反，它们在软件开发乃至更多领域有着深远的意义与影响。

比如XP这种方法，在2001年曾红极一时，其中测试驱动开发（TDD）这一约束条件，至今在软件开发领域仍为经典。

再拿Kanban来说，这是“丰田生产模式中的重要概念”，它是目前约束条件最少的一种敏捷开发方法，只有3个条件。若要再简化，那就只能称之为“没有方法，随心所欲地开发“。

意义

对于一个团队而言，选择一种合适的开发方式意义重大，它在后续工作中，对团队工作效率起了至关重要的作用。除非你想单打独斗，一个人完成一整个项目，那么你可以忽略一切的方法，一切的约束，随心所欲地做自己的开发。

民间有句俗语”烂大街的东西都是好东西“，不妨我们来了解一下这种使用率遥遥领先的敏捷开发方法Scrum，以我个人的视角向您介绍一下。

约束条件

角色

• Production Owner(PO)：产品负责人在一个团队中起着指导性的作用，他的工作主要是与客户交流，从而提炼出客户的需求，并将客户需求，分解为一个个任务，分配给开发团队完成。在公司里，我们常常见到一些由软件架构师担任的项目经理，在团队中，它们扮演着的便是PO的角色。

• Scrum Master(SM)：Scrum主管是一个团队的领导人，他不负责技术开发的工作，他的作用是协调团队，并让团队严格执行Scrum开发方式，他是一个监督者，也许他就是你的boss。

• Team：开发团队，从字面理解就好，一群程序员们，各自独立工作，完成PO下达的任务。

会议

• Sprint Planning Meeting：先介绍一下冲刺的概念，在本文的一开始我们也介绍到了，Scrum是一种迭代式增量软件开发过程，那么这里的冲刺，即是指每一次产生这种增量的过程。Scrum开发方式将整个开发流程分解为若干个阶段，每个阶段都会有或多或少的进度，无论多少，团队总是在前进中的。每次的前进，我们称作一次Sprint。而每次Sprint之前，我们都会组织一次会议，该会议会由PO主持，由他来介绍这一次的Sprint需要完成哪些任务，并将这些任务下达给Team里的每位成员。所以说，冲刺计划会议起到的是方向性的作用。

• Daily Standup Meeting：每日站立会议是个日常的例行会议，在实际工作中一般会选择放置在中午，也许是饭后，也许是茶休，该会议以简短著称，每次不超过15min，所以选择站着开会的方式。这种会议由Team成员自己完成（PO不参与会议，可由SM组织），互相交流前一天完成了什么，遇到了什么问题，今天计划完成什么，保证了工作的前进性。

• Review Meeting：冲刺评审会议在每一次冲刺结束前召开，类似于阶段性的项目答辩，主要是由Team向PO汇报在这一阶段的Sprint当中完成的任务和带来的进度，PO会给予评价，并且让PO对下个Sprint所要布置的任务有个预期，从而结合经验对工作安排进行调整，这能保证工作的外部修正。

• Retrospective Meeting：冲刺回顾会议在每一次冲刺结束后召开，与Review Meeting不同，该会议PO不参加，是Team内部的反思和总结，保证了工作的内部调整。

工作

• Product Backlog：产品待办列表是由PO草拟出的一份文件，上面会列举出客户的种种需求，并将其按照一定的优先级排序。

• Sprint Backlog：冲刺待办列表是由PO为Team安排的一份工作流程，通过客户的需求，PO会将它们分解为一个个实际的任务，Sprint Backlog便是这样一份任务清单。

• Growth：增量是Scrum工作中的核心所在，这点不用细说也能明白，任何一种工作方式，最终目的都是为了推动项目进度的前进，增量指的就是这个前进量。有的文章中会把工作的最后一条表示为冲刺燃尽图(Burndown Chart)，该图表列举的是工作中尚未完成的部分而不是已经完成的部分，该图表向所有成员公开，以保证Scrum工作中的迭代性。

工作流程

由以上角色、会议、工作的约束条件，我们不难得出一个Scrum团队完整的工作流程。在说流程前不得不提一点，Scrum是种经验方法，来源于实际的开发工作中，并且应用于开发工作。

1. 由PO与客户交流得出需求，并将需求用产品待办列表和冲刺待办列表的形式，在冲刺计划会议中展现给开发团队。
2. 开发团队按照PO分配的任务开始开发冲刺，并且每日开展站立会议。
3. 开发结束前开展冲刺评审会议向PO汇报增量，PO着手安排下一冲刺阶段的任务。
4. 开发结束后开发团队内部召开冲刺回顾会议，总结反思本次冲刺，积累经验，为下一次冲刺做准备。
5. 重复步骤2-4直至开发工作完成。

注意事项

• 必须保证工作的透明性。这点是为了保证每日站立会议的召开是有意义的，从而真实地确定增量和剩余未完成的任务。

• 不要在开发工作已经正式启动后，再实施Scrum开发方法。Scrum需要有一定时间的适应期和实践期，中途插入Scrum方法，反而会耽误整个项目的进度，只会起副作用。

• Scrum主管务必指导开发团队严格遵守Scrum约束条件。开始的一个甚至数个月内，Scrum方法需要一段时间的适应期，这时候Scrum主管的监督职责尤为关键，确保了未来Scrum能否持续下去。

后记

一点个人经验

研究团队运作方法一事，其实本不是出于兴趣，也相信如果不是管理学专业的人才也不会主动研究这些。实际上，本人这一学年出任了学校一个项目的组长，项目组成员也都是博主的同学。

对于Scrum方法，也只能说是久仰大名，但一直未见其真面目，不免有些许遗憾。接着出任组长这一机会，大概学习了一番。

说实话，一开始项目团队并未采取任何的开发方法，属于0约束的开发方式，用Microsoft MVP李智桦先生的话说就是”胡作非为“。但后来想采取Scrum的方式，结果是，得出了上文注意事项中的第二条 -_-。

想着我们团队一行6人不是很大，于是采取了一种偷懒的方式Scrumban，上文中主流3中开发方式并未提及，但这的确是国内不少小团队都在采取的一种敏捷开发方式，保留了Scrum的基本结构又像Kanban一样没那么多约束条件。虽说效果还不错，但说到底我们还是应该鼓励主流的Scrum嘛，毕竟Scrumban是个四不像。未来如果还有机会参与项目组的话希望能注意到这一点。

所以我们大概采取的方法就是：由项目导师来担任这个PO给我们布置任务或是给我们一些方向，我们每两周进行一次汇报当作是评审会议。每天晚上有空的话我们也会简单地聊聊项目的进度和遇到的麻烦，开个不正规的站立会议。每个阶段完成我们也有内部反思，但总体而言并不是那么恪守Timetable吧。

参考资料

《Scrum指导书》官方网站：http://www.scrumguides.com
MVA课程：大师分享 Scrum 原汁原味