接接触过敏捷的我们，一定对Scrum都不陌生，在最新的2020年敏捷状态报告中显示，66%的敏团队选择了Scrum（框架），及其变体仍然是最常见的敏捷方法。

我们也可以从报告中看到，采用敏捷的企业组织也是有诸多好处的， 比如报告中提到的速度和适应性相关的。scrum敏捷在加快软件交付速度和增强管理不断变化的优先级能力有显著效果。

Scrum一词来源于英式橄榄球，是争球的一种方式，Scrum框架借用这个词比喻产品开发团队是一个整体协作的团队，共同冲刺，达成团队目标。

竹内弘高和野中郁次郎在《新型的产品开发策略》首次提到将Scrum应用于产品开发，他们指出：传统的“接力式”的开发模式已经不能满足快速灵活的市场需求，而整体或“橄榄球式”的方法——团队作为一个整体前进，在团队的内部传球并保持前进，这可以更好的满足当前激烈的市场竞争。

Scrum是试验性的框架，用来解决不确定性复杂问题和开发复杂产品。“透明、检验、调整”是过程控制理论的三大支柱，也是Scrum理论的核心。

Scrum框架3(角色)3(工件)5(活动)5(价值观)

Scrum的3个角色

Scrum团队由产品经理、开发团队和交付经理组成。

产品负责人负责最大化产品价值和投资回报率，具有产品的决策权，是产品代办列表的唯一负责人，持续增加、删除、修改或细化产品代办事项，需要对产品产品代办清单的梳理、优化、优先级排序等负责。决定版本发布日期和内容，接受或退回工作成果，并且需要回答产品“why”he "what"，确保做出正确的产品。

开发团队负责在每个迭代结束时交付潜在可发布并且真正“完成”的产品增量（经过测试的、可运行的代码）。通常开发团队由5~9人组成，面对面同时办公，全职的，自组织的。

他们决定工作量和迭代容量，同时持续自我改进，回答“产品如何开发和构建”的问题。

交付经理 负责整个Scrum流程在项目中的顺利实施和进行，包括确保团队成员思维方式的转变。Scrum master是服务型领导，帮助团队排除干扰，专注迭代交付任务，清除障碍和浪费，引导团队形成迭代回顾的习惯，推动产品持续改进。

Scrum的3个工件

Scrum团队在迭代前输入的是Scrum第一个工件，即产品待办清单；迭代计划要开发的内容是Scrum的第二个工件，即迭代计划；迭代的产品效果是第三个工件，即产品增量。

产品待办列表(Product BackIog)

产品待办清单动态包含符合产品愿景的各种功能和对用户有价值的其他工作。产品待办清单就是产品的“what”，PO通过以用户视角，采用用户故事格式进行描述，让团队理解产品目标。

一个好的产品待办清单应符合DEEP原则：

• 详略得当的：列表顶部的故事将在下一个sprint中运行，其工作量小，并且足够确定和详细，而工作量大，内容粗略，放在列表中下部。
• 做过估算的：产品待办清单还是一个可用于规划的列表，未来任何一个版本的条目都需要估算，帮助产品进行排序。单位是故事点，顶部、优先级高的估算要比较准确。
• 涌现的：产品待办清单会随着各方反馈和了解的深入，用户故事会增加、减少或重新调整优先级，产品本身也在持续打磨和演进。
• 排列优先级的：待办清单应该按照条目的价值，由上至下、从高到低排序。优先级不仅仅是“高、中、低”，而是一个挨着一个排成一列。团队应该依据次序进行开发。

迭代计划

迭代计划是一组为当前迭代选出的产品待办事项/用户故事，同时加上交付产品增量和实现迭代目标的计划。

其是团队如何完成迭代的预测。任务需要被估算成理想小时，最好为一天以内，通常为2~6小时。

迭代待办清单使开发团队用来达成迭代目标的所有工作变得清晰可见。

迭代待办清单存活于当前迭代中，是团队承诺要完成的。承诺的用户故事列表在迭代期间不可以更改，但从用户故事拆分而来的具体任务，则是不断涌现的，可以增减或修改，该列表由开发团队全权负责。

产品增量

产品增量是迭代完成的所有待办事项的总和，以及之前所有迭代所产生的增量价值总和。在迭代的最后，新的增量必须是“完成的”，这意味着它必须可用并且达到了Scrum团队“完成”的定义的标准。

产品增量是迈向愿景或目标的一步，所以又被称之为潜在可发布产品增量。

当产品可能要发布时，意味着一旦产品负责人根据业务需要进行业务决策后，决定将产品上线，那么这个增量就可以上线。

通常发布是和迭代解耦的，可以在迭代边界发布产品增量，也可以在迭代中间，产品负责人根据业务决策发布已经“完成”的部分迭代待办列表事项。

Scrum的5个事件

Scrum使用固定的事件来产生规律，将不可预测的、不确定的事件，变成规律性的、预定义好的事件，从而提高透明性、减少开销和提高效率。所有事都是有时间盒限定的，也就是说将每个事件限制在最长的时间范围内。时间到了，事件就结束了。

Scrum的5个经典事件包含迭代、迭代计划会议、每日站立会议、迭代评审会议、迭代回顾会议。除此之外，在时间落地过程中，还有一个产品待办事项列表梳理会议。

迭代：Scrum将迭代称为冲刺，迭代是Scrum的核心，其长度为1~3周，在这段时间内构建一个“完成”的、可用的和潜在可发布的产品增量。

迭代计划会议：Sprint计划会议在sprint一开始召开，与团队一起共同决定计划在这个sprint中完成哪些用户故事。迭代会议是限时的，一周迭代计划会议最多2小时。

Scrummaster要确保会议顺利进行，并且每个参会者理解会议目的，同时引导Scrum团队遵守时间盒的规则。

会议中需要回答“what”和“how”，即接下来迭代交付的产品增量中包含的内容和如何完成交付所需的工作。

迭代计划会的第一部分，回答“what”，产品负责人讲解迭代目标，逐个澄清产品待办事项（用户故事），开发团队及逆行估算，通常采用的是敏捷估算，它是一种相对估算的方法，即故事点的方式。

计划会议第二部分，如何完成所选工作，即“how”的部分。

开发团队通常从产品设计开始，将用户故事分解成任务。开发团队在进行估算的时候，通常采用的是理想小时方式，即某个任务在不考虑打断、依赖、障碍的时候，全身心投入完成任务所需的小时数。

会议最后，开发团队自组织地领取待办列表中的任务，领取任务在迭代计划会议和迭代期间按需进行。

每日站立会议：每日站立会议是开发团队的一个以15分钟为时间盒的事件。团队成员在会议上相互交流任务进展、计划和遇到的困难。

迭代评审会议：sprint评审会议发生在sprint将要结束的时候。团队和客户一起评审本次sprint的产出是否达到预期。

产品负责人接受或拒绝完成的成果，同时根据业务方和产品负责人对产品增量的反馈，按需调整产品待办列表。

迭代回顾会议：迭代回顾会议是Scrum团队检视自身工作方式并创建下一个迭代改进行动加护的机会。迭代回顾会议发生在迭代评审会议结束之后、下个迭代计划会议之前。

会议由Scrummaster主持召开，会中团队成员一起回顾和小结这个sprint做的好的地方以及有哪些不足。 Scrum团队能否真正敏捷起来，真正可以依赖的抓手就是迭代回顾会议。

Scrum的5个价值观

为了让Scrum团队能够高效运作，大家需要对目标承诺，有专注精神、接受挑战的勇气和开诚布公的心态。在分享的同时互相帮助、互相尊重。

承诺 ：团队在迭代开始的时候做出承诺，并在迭代期间尽全力履行承诺。一旦发现未预测到的障碍有可能影响目标的达成，团队需要立即公开透明上报升级问题。

勇气：Scrum团队有勇气去迎接各种挑战，做正确的事并处理那些棘手的问题。

专注：一段时间内之专注于少数几件事情。团队的能力是有限的，在有限能力和有限时间范围内，专注于最有价值的事情，以取得更好的结果，达成迭代目标。

开放：在团队中公开工作的进展和挑战，即可视化、透明，这样可以很容易地暴露风险问题和障碍。另外，透明也是尊重、信任的基础。

尊重：Scrum团队成员相互尊重，彼此有能力和独立的人。

参考资料： 《Scrum敏捷精髓》、 《京东—敏捷实践指南》，赵卫，王立杰著，2020。 《用户故事与敏捷方法》

阅读更多[敏捷知识]、[敏捷转型经验]、实践等…欢迎关注@敏捷_鲸舟
如果对我们的产品感兴趣，可以逛逛我们的官方网站鲸舟研发管理平台 试用了解