Scrum：快速迭代，拥抱变化。
敏捷开发（Agile Development）是一种以人为核心、迭代、循序渐进的开发方法。在如今全球的互联网公司里，这个概念已经广为流传，每个人都在谈敏捷开发，各个公司也都多少运用了各类敏捷开发技术来应对竞争日益激烈而不得不快速迭代的局面。
敏捷开发的方法有很多，面向产品端主导的主要有极限编程（XP）、Scrum、水晶方法（Crystal Methods）、自适应软件开发（ASD）、测试驱动开发（TDD）等。而在这么多的敏捷开发方法中，Scrum因为更好理解和实践，所以更为流行。
现在开始为大家介绍这种敏捷开发技术。
一、认识Scrum
Scrum的定义：
Scrum 是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的长度是2到4周。
在Scrum中，使用产品Backlog来管理产品的需求。产品backlog按照实现的优先级进行排序，以商业价值作为排序的主要原则。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，称它为Sprint backlog。当Scrum团队完成Sprint backlog列表中的所有任务时，本次Sprint结束，进入下一个Sprint迭代周期。
Scrum的主要作用：
Scrum能够保证优先开发对客户具有较高价值的需求，更好的满足用户的需求；
与瀑布流程下的开发方式相比较，通过实施Scrum，能够提升团队一倍的开发效率，最大限度的发挥团队的作用；
Scrum能够缩短开发周期，提高项目的交付效率。
二、实施Scrum
1. 确定PO
PO即Product owner，是一个角色，PO是管理产品待办列表的唯一责任人，在我们公司都是产品经理来担当。
作为owner，必须具有全局观；深刻了解行业信息与走向；能够把握产品的方向，担负起产品短期以及中长期的规划与管理；能够根据公司战略要求，进行用户研究和产品功能规划，深度跟踪、分析、挖掘不断变化的需求，不断进行产品创新。
另外，如果将PO作为一个组织，在软件开发项目中，PO小组可能包括的成员有产品经理、业务方、以及架构师等。
在多数情况下，由产品经理或项目经理担任Owner，例如我们公司。
2. 组建team
team是产品蓝图的真正实施者，负责在每个Sprint结束时交付潜在可发布并且“完成”的产品增量。
team主要包括开发及测试人员，team必须能够落实PO对产品的设想。
team的规模宜小不宜大，一般控制在4-8人以内较为合适，便于管理。
在敏捷开发中倡导的是团队人员的“全栈”能力，但目前在大多数互联网公司可能难于落实，比如多数互联网公司前后端开发是分离的，所以在组建team团队时需要特别关注前后端开发人员投入的比例。
3. 选择Scrum Master
Scrum Master为过程负责，服务于PO和开发团队。Scrum Master要有仪式感，能够有效地、高效的组织迭代计划会、每日站立会、功能演示会、迭代回顾会等；Scrum Master必须具有高度的执行力，并保持公信力，能够帮助团队聚焦交付目标和质量目标，确保团队高效交付高质量的产品；推动团队建立高效的流程，指导团队了解敏捷价值观、原则和敏捷实践；负责培训团队其他成员，确保Scrum得到正确运用；促进团队有效的交流协作、问题管理、冲突解决，帮助团队消除一切障碍。
4. 维护Product Backlog
Product Backlog（产品需求池）是所有用户故事的集合，由PO依据公司的战略和产品愿景进行的思考。PO按照产品实现的优先级顺序对产品需求池的所有用户故事进行排序，并形成产品待办事项列表，产品待办事项列表相当于产品研发的“路线图”，要想了解产品的脉络，产品待办事项是最好的参考依据。
我们每一天都面对着新的竞争者和用户新的诉求，这意味着PO必须不断地优化自己的产品设计，并对产品待办事项列表实现的优先顺序进行调整。
在这一过程中，PO应该与所有利益相关者和团队进行协商，以确保产品待办事项能够反映用户的真实诉求。
备注：其实我司现有的禅道产品需求列表便已是这个需求池。
5. 召开Sprint Planing Meeting
Sprint Planing Meeting（冲刺计划会），在大部分的中小公司里，这往往就等同于需求评审会，需求的评估工作一般都是在需求评审会上进行，并由负责实际开发及测试工作的团队对产品待办事项做出开发及测试成本评估。
在实践过程中为了让冲刺计划会更高效，在冲刺计划会之前PO与Scrum Master会作出一个粗略的评估。看看冲刺计划是否切实可行？要完成这些需求，现有的信息颗粒度是否足够支撑评估？用户故事拆分是否合理？在开发团队进行评估时，更加要倾听团队开发测试成员对于所给方案的改进意见，及时修改方案，让开发计划得以迅速推进。
评估时team需要首先确定一个用户故事为作为评估的参照。另外，特别注意的是当评估的单个故事点大于21的时候，用户故事需要进行再次拆分，单个用户故事点数不超过8是最理性的状态。
6.维护Sprint Backlog
Sprint Backlog 冲刺需求池，其实就是按计划时间制定了本期计划后，对本期计划内所有需求的日常维护，因为需求提出后，虽经过了评审会的评估，但仍然是中颗粒度的细化程度，在实际开发过程中仍然会遇到阻碍开发们的预期外难题，这个时候开发们会要求增加工时或另辟蹊径地用另外一种方法来解决问题，这时候往往需要变更到整体开发成本（时间、金钱）或原始需求细节，因此我们需要根据意见迅速做出判断，及时更新Sprint Backlog，让后续的测试及验收环节得以明晰这个变动。
7. 定期Daily meeting
这是Scrum的活力源泉。站立会参加人员一般包括PO、Scrum Master、team。团队每天在固定地点、固定时间进行内部沟通，时间一般为早晨，时长不超过15分钟，且站立进行，Scrum Master向team成员提出下列问题：
你昨天完成了哪些工作？
你今天计划做哪些工作？
目前的困难及障碍？
这样做的意义在于：让整个团队清楚地知道在这一个冲刺周期内各项任务的进展，所有任务是否能够按时完成。同时还能分享一些开发细节，让文档记录无习惯的劣势得以缓解。
Team的任务都不是自上而下分派的，而是自主决定、自愿申领的。如果前一个任务没有完成时，不能申领下一个任务，不能同时申领2个在当天不能完成的任务。
Scrum Master负责消除团队面临的障碍，这个过程也可以用来把控协作开发的需求细节全员知悉，确保无关键细节的遗漏知情。
但是在实际实践中，往往会出现形式化talking的问题，这个需要主持人来把控成员心理。
8. Burndown/up Charts 项目看板及燃尽图
在Scrum中，必须做到工作透明化，最常见的做法是实施项目看板制度。
有的团队善于借助第三方工具使用电子看板，比如禅道；有些创始人团队更倾向于用白板黑笔和便签贴来表达，更强调主动性一些；
无论使用电子看板，还是物理看板，看板的栏目大致包括待办事项、进行中事项以及已完成事项三个部分。随着迭代进度的推进，由Team每天及时将事项转移到对应完成板块里；
让工作透明化的另一个工具是燃尽图。在这张图中，一个轴代表工作量，另一个轴代表时间。每天Scrum Master都会记录待完成的剩余点数，而后画在燃尽图上。理想情况下，该图是一条向下的曲线，随着剩余工作的完成，“燃尽”至零。
备注：其实我们使用的禅道本身就有这个燃尽图，我们的需求迭代周期表里也有完成类似效果的“签到”模块；
9.召开Sprint Review Meeting
在《Scrum指南》中将此环节称为Sprint评审会议，书中认为Sprint评审会议应该包括开发团队演示完成的工作并解答关于所交付增量的问题、评审市场或者潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变、为下个产品版本功能或能力的发布评审时间表、预算、潜在功能和市场等多个会议主题。
会议一般在在本次迭代冲刺发布前召开。我更倾向于此次会议最重要的工作是功能和成果演示，验证用户故事的实现场景，并接受评价。
这是一场公开的会议，任何人都可以是参与者，不仅仅包括PO、Scrum Master及team，还包括利益相关者、业务方与管理者，乃至客户。
团队应该只展示那些符合“完成定义”的事项，也就是全部完成，不需要再做工作就能交付的成果。这个成果或许不是完整的产品，但至少是一项完整的、可以使用的功能。
10. 召开Sprint Retrospective Meeting
冲刺回顾会一般在本次迭代发布之后的第二天召开，会议时间最好不做具体的限制。
冲刺回顾会要认真分析以下几个问题：
发生了哪些有待改进的事；
为什么会发生那件事；
为什么我们当时忽略了；
怎样才能加快工作进度。
作为一个团队，要让这个冲刺回顾过程有效，团队需要相互信任。必须记住基于项目和技术问题的讨论和争论；对事不对人，不当和事佬，鼓励技术碰撞；不能把技术和业务讨论牵扯到人身攻击上去；抵制带着有色眼睛看人，引导大家理性讨论；勇敢接受别人的挑战，接受自己的不完美 大家要对自己的流程和结果负责，要集思广益，共同寻求问题解决之道。这一点是至关重要的。
最后，团队确定一个最值得改善的地方，将其设定为下一个冲刺迭代的首要任务，当然，改善的结果必须通过“验收测试”。你如何证明自己成功地完成了改善？你需要用具体的、可操作的方式界定什么是“成功”，这样，在下一个冲刺回顾会议中才能很快判断出是否已完成改善。
就这样Scrum了一轮又一轮迭代，永不停息，拥抱未来。