什么是 Scrum
首先要知道 Scrum 是敏捷开发的方法论之一。
在学习 Scrum 之前我们需要简单储备一下基本的知识。
什么是敏捷开发？
敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。
怎么理解呢？首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发；
为什么说是以人为核心？
我们大部分人都学过瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。
什么是迭代？
迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。
关于 Scrum 和 XP
前面说了敏捷它是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而 Scrum 和 XP 就是敏捷开发的具体方式了，你可以采用 Scrum 方式也可以采用 XP 方式；Scrum 和 XP 的区别是，Scrum 偏重于过程，XP 则偏重于实践，但是实际中，两者是结合一起应用的，这里我主要讲 Scrum。
什么是 Scrum？
Scrum 是一种灵活的敏捷软件开发管理过程。这个名词来源于英式橄榄球。Scrum方法由 Ken Schwaber 和 Jeff Sutherland 提出，而 Scrum 就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。它将软件开发团队比作橄榄球队，全队有明确的最高目标：发布产品的重要性高于一切。团队高度自治，队员们熟悉开发过程中涉及到的各种技术，紧密合作，确保每个迭代都朝着最高目标推进。而且每隔 2 至 6 周，每个人都能看到能实际工作的软件，并且据此决定是发布这个版本还是继续开发以加强它的功能。
敏捷的四大宣言是什么，满足四大宣言符合十二准则的即属于敏捷：
敏捷宣言，也叫做敏捷软件开发宣言，正式宣布了对四种核心价值和十二条原则，可以指导迭代的以人为中心的软件开发方法。敏捷软件开发关注保持简洁的代码，经常性测试以及及时地交付应用的功能模块。敏捷宣言的创建是为了替代文档驱动的繁重的软件开发流程，例如瀑布式方法。
敏捷宣言强调的敏捷软件开发的四个核心价值是：
- 个人和互动高于流程和工具
- 工作软件高于详尽文档
- 客户协作高于合同谈判
- 变化响应高于遵循计划
敏捷选择提出的 12 条原则已经应用于管理大量的业务以及与 IT 相关项目中，包括商业智能（BI）。12 原则包括：
- 通过早期和连续型的高价值工作交付满足“客户”。
- 大工作分成可以迅速完成的较小组成部门。
- 识别最好的工作是从“自组织的团队”中出现的。
- 为积极员工提供他们需要的环境和支持，并相信他们可以完成工作。
- 创建可以改善可持续工作的流程。
- 维持完整工作的不变的步调。
- 欢迎改变的需求，即时是在项目后期。
- 在项目期间每天与项目团队和业务所有者开会。
- 在定期修正期，让团队反映如何能高效，然后进行相应地行为调整。
- 通过完成的工作量计量工作进度。
- 不断地追求完善。
- 利用调整获得竞争优势。
Scrum 适用于大中小型项目，在 Scrum 中最核心的是团队架构和软件研发框架。
什么是 Sprint？
Sprint 是短距离赛跑的意思，这里面指的是一次迭代，也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为 Sprint。
Product backlog
产品需求列表，产品待开发项(Product Backlog)，产品需要完成的所有用户故事的集合，用户故事有大有小，有史诗级的也有小粒度级别的：根据初始需求分解出的任务列表，包括功能性的和非功能性的所有功能； 由 Product Owner 为 Product Backlog 中的任务确定优先级别；当开发团队开始做某个任务的时候，再精确定义和分解这个任务。
Product Backlog 是产品所要具备的所有功能的总纲。当一个项目刚刚开始时，没人能够事先预见到所有的任务和需求，并为之做一个充分、详细而又包罗万象的计划。可行的方式是，先为一个项目写下所有它应该具备的显著特征和功能，数量不必很多，最好够让团队的第一个 Sprint 有活可干。随着 Sprint 的进行，生产出可发布的产品增量，客户对产品的直观认识也随之加深，他们可以据此建议更改或者添加产品 Backlog 中的任务。
在 Sprint 计划会议上，产品负责人为产品 Backlog 中的任务确定优先级，并向 Scrum 团队描述这些任务。Scrum 团队随后根据团队整体情况，确定他们能在这个即将到来的 Sprint 中完成哪些功能，并把它们挪到 Sprint Backlog 中去。
迭代任务 Sprint backlog
Sprint 待办列表或冲刺待办列表，Sprint 中需要完成的所有用户故事的集合，Sprint 的用户故事都应该在该 Sprint 中完成，并且都有满意条件。
迭代计划会（Sprint Planning）
在每个 Sprint 开始之前，需要召开 Sprint 计划会议。参加人员有产品责任人、Scrum Master、Scrum 团队和其他感兴趣的人，比如管理层人员和客户代表。Product Owner 从产品 Backlog 中挑选优先度高的任务，并与 Scrum 团队一起决定在这个 Sprint 中需要完成多少功能，Scrum 团队将这些任务分解成小的功能模块； Scrum 团队成员详细讨论如何能按需求完成这些功能模块，并估计完成每个功能模块所需的大概时间。
每日站会（Daily Scrum）
团队每日例会，条件允许的话，每天都应该在同样的时间和地点，所有成员站立着举行。由于是站立的状态开会，因此时间比较短，一般为 15 分钟左右。这个会议最好是在每天的早晨开，有利于团队成员们安排好当天的工作计划。只有团队成员可以在每日 Scrum 会议上发言，其他人员如果对项目进度有兴趣也可以参加，但只能旁听而不能发言。
会议由 Scrum Master 主持，Scrum 团队的所有成员轮流回答上图中的三个问题，即：
- 昨天我完成了什么工作；
- 今天我打算做什么；
- 我遇到了什么障碍；
通过这三个问题，团队成员之间可以彼此相互熟悉工作内容，充分了解项目进度，相互帮助解决问题。Scrum Master 除了倾听团队成员的发言外，他还有责任设法解决团队成员在会上提出的困难，尽快扫除阻碍他们工作的障碍。即使有的问题 Scrum Master 没有能力解决，例如某些技术细节问题等，他也应该找到团队中或其他团队的来帮助快速的解决问题。另外，还有两点需要注意的地方：
其一，这是团队成员之间的交流，也是相互的承诺，并不是用来向老板汇报工作进度的
其二，这也不是一个专门用于解决各种问题的会议，成员们遇到的问题可以在会上提出来，而有能力解决这些问题的人可以在会后帮助他们解决问题。
参会人员可以随意姿势站立，任务看板要保证让每个人看到，当每个人发言完后，要走到任务版前更新自己的燃尽图，如下图：
任务看版包含 未完成、正在做、已完成 的工作状态，假设你今天把一个未完成的工作已经完成，那么你要把小卡片从未完成区域贴到已完成区域。
每个人的工作进度和完成情况都是公开的，如果有一个人的工作任务在某一个位置放了好几天，大家都能发现他的工作进度出现了什么问题（成员人数最好是 5 ~ 7 个，这样每人可以使用一种专用颜色的标签纸，一眼就可以从任务版看出谁的工作进度快，谁的工作进度慢）
Sprint 审查会议（Sprint Review）
就是要演示并审核是否完成。Sprint 结束时召开；由开发团队展示这个 Sprint 中完成的功能，长度为两个小时左右，不需要PPT，一般是已完成的功能的 Demo。谁都可以参加：客户、管理层、Product Owner、其他开发人员等等。
在每个 Sprint 结束时，应该组织一个 Sprint 评审会议。Scrum 开发团队将在会上展示他们在这个Sprint中所做的工作。一般采用向大家演示产品新功能的方式来展示。
相对来说，Sprint 评审会议不必很正式。通常不需要用到 PPT 幻灯片，而且长度最好控制在两个小时之内。也就是说，不要让 Sprint 评审会议成为 Scrum 团队的负担，他们不必花太多时间来准备这个会议。
Sprint 评审会议的参与者，可以包括所有对该产品感兴趣的人：产品责任人，Scrum 团队，利益相关者，管理层人员，客户，甚至来自其他项目的开发人员等等。
在 Sprint 评审会议上，Scrum 团队用 Demo 的形式展示产品的新功能之后，与会人员依据在 Sprint 计划会议上确定的本 Sprint 的目标来评审具备了这些新功能的产品。
为什么一定要用Demo的形式来展示产品的新功能呢？因为这种方式有很多好处：
首先，参与会议的人都能直观的看到 Scrum 团队的工作成果
其次，利益相关者们可以据此提出更切合实际的反馈意见
第三，为了完成 Demo，团队会努力完成并发布那些功能，即使只是发布在测试环境下，也比没完成的好。如果不做 Demo，也许不少功能会停留在 “已完成99%” 的阶段。相比较起来，在有 Demo 的情况下，也许 “已完成” 的功能数量会相对少一些，但它们是确确实实完成了的，否则，那些 “99%” 的貌似完成的功能势必还要拖到下个 Sprint 来解决。
假如有一个刚从传统的开发模式转而采用 Scrum 的团队，由于不习惯这种自我约束、自组织的方式，在 Sprint 中并没做多少工作，那么在会上演示的时候，他们会觉得很尴尬。没准老板看到他们花了这么多时间只做了这么少的工作而感到很生气。发生这种情况当然是大家都不想看到的，但良药苦口，在下一个 Sprint 中，这个团队肯定会吸取教训，他们会明白无论什么情况下都必须 Demo，那么他们必然会很好的完成这个 Sprint 并演示给大家看。
Sprint 回顾会议（Sprint Retrospective）
在每个 Sprint 结束后，Scrum 团队会聚在一起开 Sprint 回顾会议，目的是回顾一下团队在流程、人际关系以及工具方面做得如何。团队识别出哪些做得好，哪些做得不好，并找出潜在的改进事项，为将来的改进制定计划。所有的 Scrum 会议都是限定时长的，Sprint 回顾会议的推荐时长是 Sprint 中的每一周对应一个小时（译者注：比如，一个 Sprint 包含2个星期，则 Sprint 回顾会议时长为 2 个小时）。
Scrum 团队总是在 Scrum 的框架内，改进他们自己的流程。
如何通过 Scrum 指导开发？
- 我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），项目开发过程中需求的改变也要写进去，在每个迭代(Sprint)开始之前，要开一个迭代计划会议(Sprint Planning Meetting)。在会上，产品责任人(Product Owner)为 Product Backlog中的各功能需求确定优先级(或者是在会前完成)。
- 有了 Product Backlog 列表，我们需要通过 Sprint Planning Meeting（Sprint 计划会议） 来从中挑选出一个 Story（用户故事）作为本次迭代完成的目标，这个目标的时间周期是 1 ~ 4 个星期，然后把这个 Story 进行细化。
- 随后 Scrum 开发团队（“自组织的开发团队”）按照优先级，从 Product Backlog 中挑选出他们认为能在本次迭代中完成的任务，根据 Product Backlog 列表，做工作量的预估和安排,把它们从 Product Backlog 中挪到Sprint Backlog 中来,形成一个 Sprint Backlog。
- Sprint Backlog 是由 Scrum Team 去完成的，每个成员根据 Sprint Backlog 再细化成更小的任务（细到每个任务的工作量在 2 天内能完成，最好是精确到小时）。
- 在 Scrum Team 完成计划会议上选出的 Sprint Backlog 过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）。刚开始由产品负责人或这 Scrum Master 主持，熟悉几天后可以每个人轮流组织站立会议，提高大家参与感，方式在实际工作中越开越失去意义，站立会议是根据实际情况而确定的，在项目开始之前或者项目发布时候，问题多且复杂，可以半天开一次站立会议；
- 做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实 TFS 就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到 TFS 中，中间有任何失败，都会用邮件通知项目管理人员。
- 当一个 Story 完成，也就是 Sprint Backlog 被完成，也就表示一次 Sprint 完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team 的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）。
- 最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮 Sprint 的产品需求中。
Scrum 开发流程中的三大角色
产品负责人（Product Owner）
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。提供愿景，提供边界，提供 User Story 优先级。特别注意：需要和开发团队沟通需求，需要考虑研发团队的研发能力，也就是不能压榨技术团队，不能强制或者强迫加班加点。
流程管理员（Scrum Master [ SM ]）
主要负责整个 Scrum 流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。没有行政权利（也就是说无法解雇员工），训练团队正确的做事方法，遵循 SCRUM 流程和做事原则，不代替团队做决定。特别注意：要忍住帮团队做决定的冲动，产品负责人和 SCRUM Master 不建议是同一人。
“自组织”的开发团队（Scrum Team）
主要负责软件产品在 Scrum 规定流程下进行开发工作，人数控制在 5 ~ 10 人左右，每个成员可能负责不同的技术方面（基本角色包括：需求分析师，业务分析师，程序员，测试人员，软件架构，DBA，用户体验师），但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；主动与产品负责人，SM 沟通，能够从大局出发，自觉完成工作，成员可以采用任何工作方式，只要能达到 Sprint 的目标。开发团队不是编码完就完成了。而是完成后要和团队一起沟通，演示并保证满意条件，最后提交可交付的产品并集成。在这个过程中一定要主动积极。
Scrum Team 的特点包括：
一起讨论需求。跨职能工作。自我管理，主动工作。团结合作，学习进步。注重团队承诺。一荣俱荣，一损俱损。
团队协作示例
Scrum 最佳实践
Scrum 在需求方面的核心理念
- 需求是涌现的
- 不要试图在项目初期就明确所有需求。
- 通过用户故事来组织及细化需求。
- 将些需求转变为讨论需求
- 使用用户故事来讨论需求
- 所有人都参与讨论需求，持续明确需求细节
用户故事
示例：
作为网站所有者，我希望系统可以统计广告点击率，以便我能清楚广告收益。标准格式及作用
- 作为—-角色（作用：可以通过用户的角度来思考问题）
- 希望可以—-目标（作用：思考系统有什么功能，达到什么效果）
- 以便—-原因（作用：思考该功能对于该用户有什么实质的价值）
用户故事的难点：
需求是由大大小小的用户故事组成，最开始的往往是个史诗级别的“大故事”，需要拆分成中故事，小故事。
难点：
- 发现和提炼用户故事。
- 由粗到细的拆分用户故事。
- 安排用户故事优先级，安排到不同的sprint中去实现。
如何写出第一个用户故事
实战：网上售票系统，写出一个用户故事。
参考答案：作为XX局长，我希望做一套网上售票系统，以便更高的为人民服务。
开始分解用户故事
- 细分 “以便…”这部分
- 反向思考 “我希望…”这部分
- 进行系统涉众（也就是干系人）分析，列出关键用户。
- 思考各用户在本产品上的利益所在。
- 思考“希望….”（目标）部分。
- 思考“以便…”（原因）部分，确认“希望…”这部分是否合适。也就是反向思考目标和原因是否匹配。
Sprint
一个 Sprint 就是一个小版本，建议时长是 1 个月，也可以更短。
一个 Sprint 不是一个小“瀑布”，很难区分需求、设计、编码或测试阶段。所有工作都基于对用户故事的讨论。测试先行，测试驱动，单元测试必不可少。设计也是“涌现”式的，不是一次性做好了就好，也是不断改进的。
产品负责人和 Scrum 自组织的团队商量并确定每个 Sprint 的用户故事。
怎么估算用户故事呢？
- 精确估算有“满意条件”的用户故事。
- 精确估算在 Sprint 中的用户故事。
- 粗略估算或暂不估算大、中故事。
- 估算由 Scrum “自组织的团队”负责。
- 精确估算时单位最好为小时，粗略估算时单位最好为天。
Burn Down Chart（燃尽图）
用来跟踪 Sprint 中未完成工作的情况。每做完一个 Sprint 的用户故事就烧掉，最后烧完 Sprint 也就完成了。如下图，每一个点代表一个用户故事，或者故事点，或者可度量的工作量。所有点组成 Sprint。我个人认为以用户故事为一个点，因为 Sprint backlog 中的用户故事已经是一个很喜欢的用户故事了，所以可以作为度量图。有人也有根据故事点做度量图，故事点就是拿出用户故事中的一个点作为基准故事点（最好找出可以正好 1 天完成的点），然后将用户故事中的所有点与这个基准点去比较，如果比基准点难就估算为 1.x 天，如果比基准点 easy 就估算 0.x 天等等。。。
