Scrum知多少：深入解析敏捷开发的核心框架

篇首语：本文由编程笔记#小编为大家整理，主要介绍了Scrum，你真的了解吗？相关的知识，希望对你有一定的参考价值。

似乎每个世纪都有它的“时代特征”。文艺复兴从哲学角度一直被称为冒险时代；十七世纪的理性时代过去之后，启蒙时代随之而来；十九世纪和二十世纪则分别是意识形态和分析时代；至于二十一世纪，显而易见，它的全球时代特征为复杂性。

‍敏捷是利用快速反馈来破解复杂性和不确定性，提升用低成本改变决策的适应能力，持续的交付最高客户价值。

Scrum是一个解决复杂问题的框架，让我们以迭代和增量的方式，在最短的时间内交付最大价值的产品。

Scrum是基于经验过程控制理论，或称之为经验主义。经验主义主张知识源自实际经验以及当前已知情况下做出的决定所获得。

‍透明‍、检视和‍适应是经验过程控制的三大支柱，支撑起每一个经验过程的实施。

透明

过程中的关键环节对于那些对产出负责的人必须是显而易见的。要拥有透明，就要为这些环节制定统一的标准，这样所有留意这些环节的人都会对观察到的事物有统一的理解。

例如：

• 所有参与者谈及过程时都必须使用统一的术语。




• 负责完成工作和检视结果增量的人必须对“完成”的定义，有一致的理解。

检视

‍Scrum的使用着必须经常检视Scrum的工件和完成sprint目标的进展，以便发现不必要的差异。检视不应该过于频繁而阻碍工作本身。当检视是由技能娴熟的检视者在工作中勤勉的执行时，效果最佳。

适应

如果检视者发现过程中的一个或多个方面偏离可接受范围以外，并且将会导致产品不可接受时，就必须对过程或过程化的内容加以调整。调整工作必须尽快执行才能最小化偏离。

‍‍Scrum框架是‍由Scrum团队以及与之相关的角色、事件、工件和价值观组成。框架中的每个部分都有其特定的目的，其对于Scrum的成功与使用是至关重要的。

‍‍Scrum价值观把角色、事件和工件组织在一起，管理它们之间的关系和交互。

‍‍

Scrum角色

Scrum团队是由一名Product Owner、开发团队和一名Scrum Master组成。它是跨职能的自组织团队。

‍‍1、Product Owner 的职责是将开发团队开发的产品价值最大化

• 描述愿景




• 最理想是产品的客户




• 管理产品的“Backlog”




• 获得授权去做决策




• 决定产品发布的日期和内容




• “一个”人




• 接受或退回成果




• 需要时能被团队找到




• ROI（投资回报）




• 那个“可以掐的”脖子

‍‍‍‍2、Scrum Master 通过帮助每个人理解Scrum理论、实践、规则和价值来促进和支持Scrum

• 没有权利




• 确保Scrum被理解和遵循




• 确保Scrum价值观、原则和规则被彰显




• 影响力




• 公仆式的领导者




• 保护团队




• 好的聆听者




• Scrum价值观的典范




• 教导/培训/辅导




• 引导




• 变革的代言人




• 移除障碍




• 确保Scrum运用的有效性




• 苏格拉底式的提问者

3、开发团队包括各种专业人员，负责在每个sprint结束时交付潜在可发布并且“完成”的产品增量

• 跨职能




• 自组织




• 通用的专才




• 7+-2（6+-3）




• 在同一个场所




• 没有职称（理想情况）




• 没有子团队




• 潜在可交付的产品增量




• 专注（理想情况）




• 所有需要的技能（来交付一个产品）

‍Scrum工件

Scrum工件以不同的方式表现工作任务和价值，可以用来提供透明以及检视和适应的机会。

‍‍1、Product Backlog（产品待办清单）是一份动态的有序列表，包含了符合产品愿景的各种功能，以及其他为用户带来价值的工作，它是产品需求变动的唯一来源。

• 一个健康就绪的Product Backlog应当符合DEEP原则：






• D –足够详细的描述




• E –经过估算的




• E –随着产品深入、动态调整




• P –按优先级排列






• ‍Product Backlog Item通常采用User Story实践，并且应该符合INVEST原则：






• ‍I –独立性，降低User Story之间的依赖




• N –可协商性，不应包含过多细节，具体细节应在沟通阶段产出




• V –有价值，每个User Story应具有客户/市场价值




• E –可估算性，团队可以进行估算，以安排计划




• S –足够短小，足够聚焦




• T –可测试性，用以确定是否符合验收标准






• ‍User Story：即用户故事，是使用简单的书面描述，定义一小片用户可以评估、验证的功能。

‍‍2、Sprint Backlog（Sprint待办清单）是一组为当前sprint选出的产品待办清单，同时加上交付产品增量和实现sprint目标的计划。

• Team按照优先级顺序将PBI放入Sprint




• 不能超过Team所能接受的规模




• Team对PBI进行分解，形成SBI




• 为确保持续改进，还应包括至少一条在上个回顾会议中识别出的最高优先级的过程改进项




• 一个可视化的工具让团队在sprint内部自我管理

‍‍

3、Product Increment（产品增量）是一个sprint完成的所有产品待办清单的总和，以及之前所有sprint所产生的增量的价值总和。

• 必须是有价值的可交付的产品




• 当前Sprint所完成的PBI，以及之前所有Sprint的增量价值之和




• 符合事先设定的交付标准




• PO负责评定

‍

Scrum事件

Scrum使用固定的事件来产生规律性，以此来减少Scrum之外的其他会议的必要。

1、‍Sprint借鉴了极限编程中的“迭代”，不超过1个月的时间，建议1-2周，从而限制变化和风险。通常是定长的，有利于产生更好的交付节奏。一旦时间盒到期，sprint就立即结束。根据DoD定义，产品增量工作在每个sprint内完成。

注意：

• 不去改变已承诺的Sprint目标，但范围有商讨余地




• ‍不改变当前运行中的Sprint的长度‍不改变当前运行中的Sprint长度




• 不牺牲质量




‍

2、Sprint Planning（迭代计划会议）

Sprint中要做的工作在sprint计划会议中来做计划。这份计划是由整个srcum团队共同协作来完成的。Sprint计划会议是限时的，以一个月的sprint来说，最多8小时为上限。对于较短的sprint，会议时间通常会缩短。Scrum Master要确保会议顺利进行，并且每个参会者都理解会议的目的。

通常可分为上下半场来进行：

上半场：

• 定义Sprint目标




• 团队选择可以承诺完成的Sprint待办事项




• PO对备选PBI进行详细描述，并与Team沟通细节

下半场：

• 决定如何实现Sprint目标




• Team对PBI进行拆分，形成SBI并完成估算




• 大家对Sprint目标和计划达成共识

‍

3、Daily Scrum（每日站立会）

每日站立会增进交流沟通、减少其他会议、发现开发过程中需要移除的障碍、突显并促进快速的做决策、提高开发团队的认知程度。这是一个进行检视和适应的关键会议。

• 参数






• 每日




• 同一时间同一地点




• 15分钟




• 站立




• 参与者：Team，其他角色可选






• 主要内容






• 昨天完成了什么？




• 今天将要完成什么？




• 遇到什么困难 / 风险？






• 认领任务




• 更新燃尽图

‍4、Sprint Review（Sprint评审）

‍Sprint评审会议在Sprint快结束时举行，用以检视所交付的产品增量并按需调整产品待办清单。

• 演示可运行的工作产品




• PO表明哪些“完成”的工作被接受了，哪些“未完成”的工作被退回了




• 全员参与，SM要确保Sprint Review正常进行，并协调PO与Team的矛盾




• PO可以分享有关市场、预算、时间表、使用情况等信息。

‍

5、Sprint Retrospective（Sprint回顾）

‍Sprint回顾会议是Scrum团队检视自身并创建下一个Sprint改进计划的机会。它发生在sprint评审会议结束之后，下个sprint计划会议之前。

• 对我们如何工作（人、关系、过程、工具等）进行检视和调整




• 在安全的环境中进行




• 下一个Sprint的改进行动计划

‍

‍‍另外，在下一个Sprint开始前，可以由团队、客户/干系人一起进行Product Backlog Refinement（产品待办清单梳理活动）：

• 促进开发团队更好的理解业务




• 使PBI准备好以便完成，避免返工

Scrum价值观

‍当承诺、勇气、专注、开放和尊重五大价值观为Scrum团队所践行与内化时，Scrum的透明、检视和适应三大支柱成为现实，并且在每个人之间构建信任。Scrum团队成员通过Scrum的角色、事件和工件来学习和探索这些价值观。

Scrum的成功应用取决于人们变得更为精通践行五项价值观。人们致力于实现Scrum团队的目标。Scrum团队成员有勇气去做正确的事并处理那些棘手的问题。每个人专注于Sprint工作和Scrum团队的目标。Scrum团队及其利益相关者同意将所有工作和执行工作上的挑战进行公开。Scrum团队成员相互尊重，彼此是有能力和独立的人。

写在最后

‍Scrum的角色、事件、工件和价值观是不可改变的。虽然只实施部分的Scrum是可能的，但这样就不是Scrum了。Scrum只以整体形式而存在，唯其如此才能作为其他技术、方法和实践的容器运作良好。

东软敏捷创新社区

东软敏捷创新社区由东软集团过程改善中心发起，旨在东软集团范围内传播精益/敏捷思想和价值观，推广精益/敏捷方法和实践，支持并推动组织敏捷转型