Scrum介绍
摘要
如今，项目管理的步伐越来越快。项目管理需要更灵活、更积极地，向应客户的需求。使用敏捷项目管理方法，项目经理可以在不影响价值、质量和商业规则的前提下实现所有目标，Scrum是一种迭代增量式的软件开发过程，用于敏捷软件开发。Scrum是一个包括一系列实践和预定义角色的过程框架。本文从瀑布模型出发，介绍了scrum的主要要素、过程以及遇到的挑战。
Scrum主要角色：
- Product Owner
- Scrum master
- 团队
Scrum过程：
- 建立Product backlog
- Sprint 计划会议
- 编写Sprint Backlog
- 每日例会
- Sprint演示（评审）
- Sprint回顾
关键词: 软件工程、敏捷开发、Scrum
目录
一、瀑布模型
在传统瀑布模型的开发中，我们倾向于对项目做全局的详细分析，然后做出整体的schedule，开发人员按照这个schedule进行后续的开发。瀑布模型有以下缺点：
- 在项目的各个阶段反馈太少
- 只有在项目的生命周期结束后才能看到项目的成果
- 通过过多的强制完成日期和里程碑来跟踪各个项目阶段
- 瀑布模型不能够很快的适应客户的需求变更
二、敏捷开发
在次基础上人们引出了敏捷（Agile）开发的理念，Agile (敏捷)开发整体概念的产生是基于一种方法更接近人类活动现实情况,以便取得更好效果的信念上。Agile(敏捷)强调构建可以即时操作的软件，相对于在构建前花费许多时间记录规格要求。Agile(敏捷)注重授于小型多职能的团队决策权，相对于大型层次和部门职能的划分，Agile(敏捷)注重快速迭代，并且其中结合尽可能多的客户反馈。
敏捷宣言：
- 个体与交互 胜过 过程和工具
- 可用的软件 胜过 完备的文档
- 客户协作 胜过 合同谈判
- 响应变化 胜过 遵循计划
敏捷价值观：沟通，简单，反馈，勇气，尊重
三、Scrum
Scrum是众多快速发展的Agile (敏捷)方式之，Scrum这个名字来源于英式橄榄球的一种争球方式，为什么要取这个名字？如图3-1所示。这种敏捷开发方法跟Scrum有相似的地方，迭代，反馈，快速反应和有效的沟通。Scrum是一个轻量级的软件工程过程，是一个软件管理框架。
图3-1 scrum
3.1 Scrum简介
Scrum是一个敏捷开发过程框架，是一套追求迭代开发、持续集成的开发管理方法。在Scrum中，整个开发周期包含若干个小的迭代周期，每个小的迭代周期称为一个sprint（冲刺）。Scrum的重要支柱之一是当Scrum开发团队确认承诺任务后，产品所有者 (Product Owner)在此Sprint期间不可以添加新的需求。
3.2 Scrum的角色
- 产品负责人 (Product Owner)
产品负责人是利益相关方的代表，他的工作重点是产品的业务方面。他负责给出一份明确的，可度量的，合理的产品 Backlog（product backlog），并从业务角度出发对Backlog 中各项问题按优先级排序。Scrum开发团队总是优先开发对客户具有较高价值的需求。
- Scrum Master
Scrum Master 是整个团队的导师和组织者,他负责提高团队的开发效率。
- 明确把握开发进度。
- 保证Scrum团队中各个角色及职责的良好协作。解决团队开发中的障碍。
- 做为团队和外部的接口，屏蔽外界对团队成员的干扰。
- 保证开发过程按计划进行，组织每日站会、Sprint计划会议、Sprint评审会议和Sprint回顾会议。
- 团队
负责交付产品的团队。一个团队通常由5至9名具有跨职能技能的人（设计者，开发者等）组成，承担实际的开发工作。
四、 Scrum过程
Scrum的过程如图4-1所示
图4-1 Scrum过程
4.1 建立Product Backlog
Product Backlog是Product Owner把客户的商业需求按照优先级排出来的列表，整个项目存在一个唯一的Backlog，Backlog的内容由Product Owner随时按照客户的需求进行更新，并且做出粗略的工作量评估，供开发团队进行参考。一个典型的Product Backlog如图4-2所示。
图4-2 Product Backlog
4.2 Sprint计划会议
Sprint会议用来确定Sprint backlog，Sprint会议计划会议是Scrum中最重要的一部分，在会议中，产品负责人告诉Scrum团队产品backlog中优先级较高的项，Scrum团队共同讨论产品backlog，一起决定接下来的一个Sprint中开发哪些功能，形成Sprint backlog，并估算Sprint backlog中每一项的开发时间。有一下事情在该会议中需要明确：
- Sprint的长度，Sprint的长度是一个trade-off的结果，Sprint越短，越"敏捷"，越能更早的看到成果，但是过短的sprint会使团队处于频繁的sprint机会会议、演示，发布等压力之下，目前建议的sprint长度为"三个星期"。
- Sprint的目标，每一个Sprint都应该确定一个目标，如果目标没有价值，就不应该开始这个Sprint。
- Sprint要包含的故事（story），就是要确定讲那些story从Product Backlog中放入Sprint Backlog中。
- 对每个Story的时间估算，scrum使用"纸牌"的方式，让每一个团队成员都参与到每一个Story的时间评估当中，具体操作是：买个成员都在纸牌上写下自己对当前story的评估时间，牌面朝下，等大家都已经完成后，所有团队成员把纸牌翻开，显示出自己对story的评估时间，如果团队成员评估的时间差距非常大，就需要大家再次进行评估，使用纸牌的好处是团队成员都可以对story的工作量进行评估，且不会受到其他人的影响，这样子得出的数据会更加的准确。
- 明确故事内容，确保让Product Owner和团队对故事有同样的理解，可以尝试将大的Story分解成不同的task从而便于理解。
4.3编写Sprint Backlog
在完成Sprint会议的基础上，由Scrum Master编写Sprint Backlog，Sprint Backlog可以由多种方式进行保存，excel等，本文推荐通过任务板来保存Sprint Backlog（将其挂在墙壁上），一个任务板的例子如图4-3所示。
图4-3 任务板Sprint Backlog
在每次例会后由Scrum Master更新该Backlog，可以看出，使用任务板的方式使得整个项目的进展情况一目了然，并且方便维护。
4.3.1燃尽图（burndown chart）
燃尽图清楚的表示在当前sprint中已经完成的story point和剩余工作时间的关系，燃尽图由scrum master在每日例会后进行更新，一个典型的燃尽图如图4-4所示。
图4-4燃尽图
4.4每日例会
每日例会在Scrum中叫"站立会议"，一般都不会超过15分钟，在每日例会后由scrum master更新任务板（包括燃尽图），在例会中每个人都会描述昨天已经完成的事情和今天要做的事情，以及自己遇到的问题（Scrum将会记录问题，在后续会解决这些问题），每日例会的主要功能就是update整个团队以及进度，它是一个汇报会议，每日例会不需要讨论具体细节，如果有细节需要讨论，单独发起会议，一个典型的每日例会如图4-5所示。
图4-5每日例会
4.5 Sprint演示
也叫Sprint评审，这只是简单的展示工作结果，所有与会人员可以提出问题和建议。会议可以持续10分钟，也可以是两个小时——会议目的只是对工作结果的展示和听取反馈在scrum中，所有的sprint都结束与演示，通过演示，团队的成果可以得到认可，其他人可以了解到团队在做什么事情，演示可以得到更多的反馈，通过演示会迫使团队真正完成一些工作。
4.6 Sprint回顾
在Sprint评审会议结束之后和下个Sprint计划会议之前，Scrum团队需要举行Sprint回顾会议。在回顾会议上，Scrum团队会一起讨论当前Sprint有哪些成功的经验，有什么地方去要改进。在回顾会议的最后，Scrum团队应该确定将要在下个Sprint中实现的改进方法。
回顾是scrum中非常重要的事情之一，因为这是改进的最佳时机，回顾主要做一下三件事情：
- Good 如果我们可以重做同一个Sprint，那些做法是可以保留的？
- Could have done better 如果我们可以重做同一个Sprint，哪些做法需要改变？
- Improvements 有关将来如何改进的具体想法？
五、 Scrum的挑战
Scrum不是流程－而是提供给团队可视性的框架，并且容许他们相应的"检验和适应"的技巧。Scrum试图让许多存在于开发团队中的问题显现出来。比如，大多数的开发团队并不擅长于估算在固定期间内完成的工作量，因此在第一个Sprint结束时不可能交付他们预计完成的工作。
对于开发团队来说，这个是工作的失败。事实上，这个经验正是能更好预计工作量所需的第一步，并促使其对承诺的任务更加负责。这种模式－Scrum可以使机能失调更易显现出来，让团队切实可以解决问题－是使用基础的技巧产生出最有意义的收益，是团队使用Scrum的经验之一。
一个开发团队普遍犯的错误是，当他们在Scrum实践中遇到挑战，他们会改变实践方法，而不是改变自身的问题。比如，开发团队有困难完成Sprint任务时，会延长Sprint的周期，这样他们就会有充足的时间完成任务——在流程中，确保自身不用提高工作预测的技能和更好的管理时间。这样，在没有经验丰富的Scrum培训师的指导下，开发团队只会将Scrum作为自身弱点和机能失调的映射，并破坏了Scrum真正的意义：使优点和缺点都显现出来，给开发团队自我的提高提供机会。
另一个普遍存在的错误是，人们以为某一实践方法是被禁止或不提倡的，只是因为Scrum没有明确的提出此方法。比如，Scrum并不特别要求产品所有者 (Product Owner)对于他或她的产品作出长远的目标计划；也没有要求工程师请教更有经验的人员关于比较复杂的技术问题。Scrum将这些问题留给个人作出正确的处理；在很多情况下，以上两个方法（和其他许多的方法）会被建议。做个正确的比喻："因为Scrum没有提到早餐的问题，并不意味着你就得挨饿！"另一个需要留意的问题是有时经理会强制开发团队使用Scrum；Scrum是为开发团队提供自我组织的空间和工具，由上层强加于开发团队恐怕不是取得成功的良方。 比较好的方法是让开发团队从同事或经理处了解到Scrum，并通过专业系统的培训，在开发团队实验此方法（比如90天）后作出决定；在实验周期后，开发团队通过经验的总结来决定是否继续采用此方法。
参考文献:
［1］ Henric Kniberg．硝烟中的Scrum和XP-我们如何实施Scrum．清华大学出版社，2011.1．
［2］ Pete Deemer，Gabrielle Benefield．SCRUM 简介-使用Scrum的Agile（敏捷）项目管理介绍