什么是 scrum

Scrum是迭代式增量软件开发过程，是敏捷方法论中的重要框架之一，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum最初只应用于软件开发，当前Scrum通常被认为是一种用于开发任何产品或管理人和工作的迭代式的，增量的过程。

一、Scrum定义

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

二、Scrum中的两种角色

“猪”角色

猪是全身投入项目和Scrum过程的人； they are the ones with “their bacon on the line.”
产品负责人代表了客户的意愿。这保证了Scrum团队在做从业务角度来说正确的事情。产品负责人编写用户故事，排出优先级，并放入产品订单。Scrum主管（或促进者）促进Scrum过程，他的主要工作是解决那些影响团队交付冲刺目标的障碍。Scrum主管并非团队的领导（由于他们是自我组织的），而是负责屏蔽外界对开发团队的干扰。Scrum主管确保Scrum过程按照初衷进行。Scrum主管是规则的执行者。开发团队是负责交付产品的团队。由5至9名具有跨职能技能的人（设计者，开发者等）组成小团队来完成实际的开发工作。

“鸡”角色

鸡角色并不是实际Scrum过程的一部分，但是必须考虑他们。使用户和利益相关者参与到过程中是敏捷方法的一个重要实践。“鸡”角色参与每一个冲刺的评审和计划，并提供反馈，对于Scrum过程来说是非常重要的。
用户软件是为用户而创建的，就像“假如森林里有一棵树倒下了，但没有人听到，那么它算发出了声音吗”，“假如软件没有被使用，那么它算是被开发出来了么？”利益所有者（客户，提供商）是影响项目成功与否的人，他们只直接参与到冲刺评审的过程中。经理是为产品开发团体架起环境的那个人。

三、Scrum术语

产品负责人 Product Owner：负责维护产品订单的人，代表利益相关者的利益。
Scrum主管 Scrum Master：为Scrum过程负责的人，确保scrum的正确使用并使得Scrum的收益最大化。一般不翻译。
开发团队 Team: 由负责自我管理开发产品的人组成的跨职能团队。
产品列表 Product Backlog：根据用户价值进行优先级排序的高层需求。
冲刺订单 Sprint Backlog：要在冲刺中完成的任务的清单。
产品增量 Increment：最终交付给客户的内容
计划会 Sprint Planning Meeting：在每个冲刺之初，由产品负责人讲解需求，并由开发团队进行估算的计划会议。
每日立会 Daily Standup Meeting：团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名。
评审会 Review Meeting：在冲刺结束前给产品负责人演示并接受评价的会议。
反思会/回顾会 Retrospective Meeting：在冲刺结束后召开的关于自我持续改进的会议。
冲刺 Sprint: 一个时间周期（通常在2周到1个月之间），开发团队会在此期间内完成所承诺的一组订单项的开发。

四、Scrum开发流程

首先产品经理(产品团队)把需要上线的产品特性做成产品需求列表（Prodcut Backlog）,由产品经理(产品团队)基于产品整体战略、目标、业务价值、实现难度等因素甄选出优先级较高的项目，交个整个团队进行讨论。
召开迭代规划会议，研发团队、产品经理和开发团队负责人（Scrum Master）讨论用户故事的优先项，且决定本次次迭代要研发的需求项。并由开发团队负责人开展可行性评估和工时评估，确定迭代的需求排期，形成迭代需求列表（Sprint Backlog）。
会议结束后，团队中的每个成员需要对每个用户故事有深刻的理解。团队负责人根据需求拆分相应的子任务，分配相应的开发成员执行，并评估相应的工时。
研发团队要在一到三周的时间里开发完成迭代需求列表中的需求，在迭代中，每日站会用于团队来交流他们做完了什么，正在做什么，以及遇到的问题，及早发现风险。
每次迭代的产出都是一个可以发布的产品版本，在迭代结束前，会进行迭代评审会（Sprint Review Meeeting），由研发团队向产品经理做案例演示并接受评价。产研团队根据整个迭代需求的完成情况和缺陷处理情况，最终决定整个产品是否上线，也可以在发布前增加新功能。确认上线后，由运维进行上线环境部署，正式上线。
在迭代结束时，产品和开发会举行迭代回顾会（Sprint Retrospective Meeeting），团队一起思考工作中可以改进的地方，制定改进措施。每次迭代都需要进行这样的会议，来不断改进产品的质量。
最后，产品团队在产品功能上线后，持续收集用户的反馈，分析数据形成新的用户故事，进入下一次迭代。

延伸阅读

优先级排序的依据

排列需求优先级的依据由所涉及的相关方商定，并在商业分析规划与监督知识领域中定义。影响优先级排序的常见因素包括：1、收益；2、惩罚；3、成本；4、风险；5、依赖关系；6、时间敏感性；7、稳定性；8、监管或政策合规。

1、收益

针对变革的宗旨和目标进行衡量的实施需求能够为相关方所带来的好处。所提供的收益可以指一项具体功能、期望质量，或是战略宗旨或业务目标。如果存在多个相关方，每个群体考察收益的方式可能不同。可能需要运用冲突化解和谈判来达成针对总体收益的共识。

2、惩罚

不实施特定需求所造成的后果。这包括为满足施加于组织的监管或政策要求而排列需求优先级，这可能比其他相关方利益更优先。惩罚也可以指不实施一项改进客户体验的需求所带来的负面后果。

3、成本

实施需求所需的工作量与资源。有关成本的信息通常来自实施团队或卖方。客户在了解成本后可能改变一项需求的优先级。成本常常与其他标准结合使用，例如成本收益分析。

4、风险

需求无法带来潜在价值，或根本无法实现的可能。这可以包括得多因素，诸如实施一项需求的难度，或是相关方不能接受一个解决方案部件的可能。如果存在解决方案技术上不可行的风险，最难实施的需求可能会被列为较高优先级，从而将了解到拟议解决方案无法交付前所花费的资源最小化。可以开发概念验证以确定高风险选择是可行的。

5、依赖关系

需求之间的关联关系，其中一项需求只有在另一项需求被实现后才有可能实现。在某些情况下，将相关需求同时进行实施可能可以达成更高效率。依赖关系也可能超越当前行动，包括(但不限于)其他团队的决定、资金投入承诺与资源可用情况。依赖关系在跟踪需求任务中进行识别。

6、时间敏感性

需求的“优异实现期限”，在此之后实施需求将丧失重要价值。这包括上市时间方案，其中某项功能如果可以先于竞争对手交付，所取得的收益将会极大增加。它也可以指仅在一年中的特定时间具有价值的季节性功能。

7、稳定性

需求将会发生改变的可能性，改变的原因可以是由于需要对它做进一步分析，或是由于相关方未就其达成共识。如果一项需求不稳定，则它的优先级可能较低，以减少无法预计的返工与工作量损失。

8、监管或政策合规

为满足施加于组织的监管或政策要求而必须实施的需求，它们可能比其他相关方利益更加优先。