敏捷的开发方法有很多，比如极限编程（XP）、Scrum、水晶方法（Crystal Methods）、自适应软件开发（ASD）、特性驱动开发（FDD）、动态系统开发（DSDM）、轻量级RUP、测试驱动开发（TDD）等等。而在众多的敏捷开发方法中，尤以Scrum比较流行。

一、什么是Scrum

Scrum 是一个用于开发和维护复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog按照实现的优先级进行排序，以商业价值作为排序的主要原则，产品backlog的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprintbacklog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。

二、Scrum流程图

三、Scrum的实施步骤

（一）、确定Productowner(即PO)

在有些公司PO可能是一个角色，也可能是一个组织，如果将PO作为一个组织运行，在这一个组织中也必须选出一个Owner。作为owner必须具有大局观；深刻了解行业信息与走向；能够把握产品的方向，担负起产品短期以及中长期的规划与管理；能够根据公司战略要求，进行用户研究和产品功能规划，深度跟踪、分析、挖掘不断变化的需求，不断进行产品创新。另外，如果将PO作为一个组织，在软件开发项目中，PO小组可能包括的成员有产品经理、业务方、视觉、交互以及架构师等，在多数情况下由产品经理担任Owner。

（二）、组建开发团队

开发团队是产品蓝图的真正实施者，开发团队必须能够落实PO对产品的设想。开发团队的规模宜小不宜大，一般5~9人较为合适。在敏捷开发中倡导的是开发人员的“全栈”能力，但目前在大多数互联网公司前后端开发是分离的，实现开发人员的全栈能力可能难于落实，所以在组建开发团队时需要特别关注前后端开发人员投入的比例。

（三）、选择Scrum Master

Master为Scrum过程负责，Master必须具有高度的执行力，帮助团队聚焦交付目标和质量目标，确保团队高效交付高质量的产品；推动团队建立高效的流程，指导团队了解敏捷价值观、原则和敏捷实践；促进团队有效地、高效的组织各项Scrum仪式，包括迭代计划会、每日站立会、功能演示会、迭代回顾会等。负责培训团队其他成员，确保Scrum得到正确运用；促进团队有效的交流协作、问题管理、冲突解决，帮助团队消除一切障碍。

（四）、维护产品需求池

产品需求池是所有用户故事的集合，由PO依据公司的战略和产品愿景进行的思考。PO按照产品实现的优先级顺序对产品需求池的所有用户故事进行排序，并形成产品待办事项列表，产品待办事项列表相当于产品研发的“路线图”，要想了解产品的脉络，产品待办事项是最好的参考依据。

另外，我们每一天都面对着新的竞争者和用户新的诉求，这意味着PO必须不断地对优化自己的产品设计，并对产品待办事项列表实现的优先顺序进行调整。在这一过程中，PO应该与所有利益相关者和团队进行协商，以确保产品待办事项能够反映用户的真实诉求。

（五）、故事点评估

相对精确的评估工作一般都是在冲刺计划会上进行，并由负责实际开发及测试工作的团队对产品待办事项做出评估。在实践过程中为了让冲刺计划会更高效，在冲刺计划会之前PO与Scrum Master会作出一个粗略的评估。看看冲刺计划是否切实可行？要完成这些事项，现有的信息是否足够？用户故事拆分是否合理？在开发团队进行评估时，建议摒弃传统的“人天”评估法，采用故事点的方式，用斐波那契数列的数字（1，2，3，5，8，13，21……）的形式去评估。

六）、冲刺计划会

这是第一场真正意义上的Scrum会议。Team团队（前后端开发及测试人员）、Scrum Master、PO以及视觉交互人员坐到一起，规划冲刺的内容。冲刺周期一般是固定的，大部分是2至4周。团队要从产品待办事项列表优先级最高的用户故事着手，看看一个冲刺迭代中能完成多少。如果团队已经开展过多个冲刺迭代，通过参考前几次迭代中完成的“故事点数”，能够预知本次完成的大概故事点数。“故事点数”相当于团队的速度。Scrum Master与Team团队应努力在每一个冲刺迭代中提高这个数字。对于冲刺目标，即在这一冲刺迭代完成哪些事项，所有人都应该形成共识。在冲刺计划会上，PO需要告诉开发团队用户故事实现的优先级顺序。开发团队承诺在下一次冲刺迭代中他们能够完成多少用户故事。在冲刺的过程中，没有人能够单方面擅自变更冲刺内容。

（七）、项目看板及燃尽图

在Scrum中，必须做到工作透明化，最常见的做法是实施项目看板制度。根据不同的项目团队情况，有的团队善于借助第三方工具使用电子看板，比如Redmine看板，Leangoo看板；有的团队乐于使用线下物理看板。无论使用电子看板，还是物理看板，看板的内容大致包括待办事项、进行中事项以及已完成事项三个部分。随着迭代进度的推进，由Team团队人员将事项转移到相应栏目下。

工作透明化的另一个工具是燃尽图。在这张图中，一个轴代表工作量，另一个轴代表时间。每天Scrum master都会记录待完成的剩余点数，而后画在燃尽图上。理想情况下，该图是一条向下的曲线，随着剩余工作的完成，“燃尽”至零。

（八）、每日站立会

这是Scrum的活力源泉。站立会参加人员一般包括PO、Scrum Master、开发人员及测试人员。团队每天在固定地点、固定时间进行内部沟通，时间一般为早晨，时长不超过15分钟，且站立进行，Scrum Master向团队成员提出下列问题：你昨天完成了哪些工作？你今天计划做哪些工作？目前的困难及障碍？

这样做的意义在于让整个团队清楚地知道在这一个冲刺周期内各项任务的进展。所有任务是否能够按时完成？团队的任务都不是自上而下分派的，而是自主决定、自愿申领的。当前一个任务没有完成时，不能申领下一个任务，不能同时申领2个在当天不能完成的任务。Scrum Master负责消除团队面临的障碍。

（九）、功能演示

在冲刺结束前，向PO展示成果，验证用户故事的实现场景，并接受评价。这是一场公开的会议，任何人都可以是参与者，不仅仅包括PO、Scrum Master及开发团队，还包括利益相关者、业务方与管理者，乃至客户。

团队应该只展示那些符合“完成定义”的事项，也就是全部完成，不需要再做工作就能交付的成果。这个成果或许不是完整的产品，但至少是一项完整的、可以使用的功能。

（十）、冲刺回顾会

冲刺回顾会一般在本次迭代发布之后的第二天召开，会议时间不做具体的限制。

要让这个冲刺回顾过程有效，团队需要相互信任。必须记住基于项目和技术问题的讨论和争论；对事不对人，不当和事佬，欣赏技术碰撞；不能把技术和业务讨论牵扯到人身攻击上去；不欢迎带着有色眼镜看人，不欢迎非理性的讨论；做一个成熟包容强大的工程师，勇敢接受别人的挑战，接受自己的不完美 。

冲刺回顾会要将注意力集中在流程上，认真分析以下几个问题：为什么会发生那件事？为什么我们当时忽略了？怎样才能加快工作进度？作为一个团队，大家要对自己的流程和结果负责，要集思广益，共同寻求问题解决之道。这一点是至关重要的。

与此同时，团队必须有勇气把真正的障碍摆到台面上来，这样做是为了解决问题，而不是为了指责某个成员。团队成员必须能认真探讨问题，并虚心接受他人反馈的意见和建议，以便寻求问题解决之道，而非只想着为自己辩解。

最后，团队确定一个最值得改善的地方，将其设定为下一个冲刺迭代的首要任务，当然，改善的结果必须通过“验收测试”。你如何证明自己成功地完成了改善？你需要用具体的、可操作的方式界定什么是“成功”，这样，在下一个冲刺回顾会议中才能很快判断出是否已完成改善。

上一个冲刺迭代结束之后，开始进入新的冲刺迭代。

四、Scrum的主要作用

在我看来，Scrum的主要作用包括：Scrum团队能够保证优先开发对客户具有较高价值的需求；通过实施Scrum，能够提高团队的开发效率，最大限度的发挥团队的作用，更好的满足用户的需求；Scrum能够缩短开发周期，提高项目的交付效率。

但是，也有人认为Scrum没有什么实质性的作用，然并卵。推行Scrum困难重重。可能的原因包括：项目团队对敏捷缺乏正确的认识，单纯的认为敏捷就是快，就是追赶进度，Scrum意味着自己“漫无天日”的加班，尤其对于没有接触过Scrum的程序员来说，对敏捷有一种“恐惧”感；PO不能胜任工作，无法拆分有效的用户故事，或者用户故事拆分的不合理，无法实现迭代开发；Scrum对于自组织的团队要求很高，但许多同学认为自己达不到自组织的标准；Scrum倡导工作透明化，项目实时完成情况和每个人的任务认领情况通过项目看板和项目燃尽图一览无余，许多人对此不太适应；在迭代的过程中无法及时发现问题，或者发现问题，无法有效解决问题。