Scrum开发初探

Scum定义

什么是Scum呢，其实说白了就是一种软件开发框架，和瀑布模型，螺旋模型同属软件开发方法，但相比于传统的以产品经理为主导的软件开发框架有所区别，他是面向开发团队的，团队决定开发任务。
以下文章的展开都依赖于这个图：

Scrum理论

Scrum 基于经验过程控制理论，或称之为经验主义。经验主义主张知识源自实际经验以及
当前已知情况下做出的决定所获得。Scrum 采纳一种迭代和增量式的方法来优化对未来的
预测和控制风险。
透明、检视和适应是经验过程控制的三大支柱，支撑起每一个经验过程的实施。

透明

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

• 所有参与者谈及过程时都必须使用统一的术语。
• 负责完成工作和检视结果增量的人必须对“完成”的定义，有一致的理解。

检视

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

适应

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

价值观

• 承诺
• 勇气
• 专注
• 开放
• 尊重

Scum团队

产品负责任人

产品负责人的职责是将开发团队开发的产品价值最大化。如何实现这一点的方式会随着跨
组织、Scrum 团队和团队成员个体的不同而有所不同。
产品负责人是负责管理产品待办列表的唯一负责人。产品待办列表的管理包括：

• 清晰地表述产品待办列表项；
• 对产品待办列表项进行排序，使其最好地实现目标和使命；
• 优化开发团队所执行工作的价值；
• 确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做
  的工作；
• 确保开发团队对产品待办列表项有足够深的了解。

产品负责人可以亲自完成上述工作，或者也可以让开发团队来完成。然而无论何者，产品
负责人是负最终责任的人。

产品负责人是一个人，而不是一个委员会。产品负责人可能会通过产品待办列表展现一个
委员会的期望要求，但是想要改变产品待办列表项的优先级都必须经过产品负责人。

为保证产品负责人的工作取得成功，组织中的所有人员都必须尊重他/她的决定。产品负
责人对产品待办列表的内容和排序的决定必须是可见的。没有人可以强迫开发团队按照另
一套需求开展工作。

开发团队

开发团队具有下列特点：

• 他们是自组织的。没有人（即使是 Scrum Master）有权告诉开发团队应该如何把产品
  待办列表变成潜在可发布的功能增量；
• 开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能；
• Scrum 不认可开发团队成员的任何头衔，不管其承担何种工作（他们都叫开发人
  员）。
• Scrum 不认可开发团队中所谓的“子团队”，无论其需要处理的领域是诸如测试、架
  构、运维或业务分析；
• 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。

注：开发团队人数应该控制在3-9人

Scum master

Scrum Master 负责根据 Scrum 指南中的定义来促进和支持 Scrum。Scrum Master 通过帮助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。

Scrum Master 对 Scrum 团队而言，他/她是一位服务型领导。Scrum Master 帮助 Scrum
团队之外的人了解他/她如何与 Scrum 团队交互是有益的，通过改变他/她们与 Scrum 团
队的互动方式来最大化 Scrum 团队所创造的价值。

说白了就是工具人

Scrum Master 服务于产品负责人

Scrum Master 以各种方式服务于产品负责人，包括：

• 确保 Scrum 团队中的每个人都尽可能地理解目标、范围和产品域；
• 找到有效管理产品待办列表的技巧；
• 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项；
• 理解在经验主义的环境中的产品规划；
• 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值；
• 理解并实践敏捷性；
• 当被请求或需要时，引导 Scrum 事件。

Scrum Master 服务于开发团队

Scrum Master 以各种方式服务于开发团队，包括：

• 作为教练在自组织和跨职能方面给予开发团队以指导；
• 帮助开发团队创造高价值的产品；
• 移除开发团队工作进展中的障碍；
• 按被请求或需要时，引导 Scrum 事件；以及，
• 在 Scrum 还未完全采纳和理解的组织环境中，作为教练指导开发团队。

Scrum Master 服务于组织

Scrum Master 以各种方式服务于组织，包括：

• 带领并作为教练指导组织采纳 Scrum；
• 在组织范围内规划 Scrum 的实施；
• 帮助员工和利益攸关者理解并实施 Scrum 和经验导向的产品开发；
• 引发能够提升 Scrum 团队生产率的改变；以及，
• 与其他 Scrum Master 一起工作，增强组织中 Scrum 应用的有效性。

Scum事件

Sprint

每个 Sprint 都可以被视为一个项目，为期不超过一个月。就如同项目一样，Sprint 被用
于完成某些事情。每个 Sprint 都会有一个要构建什么的目标，还有一份设计过和灵活的
计划用来指导如何做这些事、工作内容和最终产品增量。

Sprint计划会议

以一个月的 Sprint 来说最长为 8 小时。对于较短的Sprint，会议时间通常会缩短。

Sprint 计划会议回答以下问题：

• 接下来的 Sprint 交付的增量中要包含什么内容？
• 要如何完成交付增量所需的工作？

每日Scum站会

每日 Scrum 站会是开发团队的一个时间盒限定为 15 分钟的事件。每日 Scrum 站会在
Sprint 的每一天都举行。在每日 Scrum 站会上，开发团队为接下来的 24 小时的工作制
定计划。通过检视上次每日 Scrum 站会以来的工作和预测即将到来的 Sprint 工作来优化
团队协作和效能。每日 Scrum 站会在同一时间同一地点举行，以便降低复杂性。

开发工作

coding

Sprint评审会议

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

Sprint 评审会议包含以下内容：

• 参会者包括 Scrum 团队和产品负责人邀请的主要利益攸关者；
• 产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”；
• 开发团队讨论在 Sprint 期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决
  的；
• 开发团队演示“完成”的工作并解答关于所交付增量的问题；
• 产品负责人讨论当前的产品待办列表的情况。他／她根据到目前为止的进度来预测可
  能的目标交付日期（如果有需要的话）；
• 参会的所有人就下一步的工作进行探讨，这样， Sprint 评审会议就能够为接下了的
  Sprint 计划会议提供有价值的输入信息；
• 评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变； 同
  时，（流量为王，产品依靠于流量）
• 为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。

Sprint回顾会议

回顾会议发生在 Sprint 评审会议结束之后，下个 Sprint 计划会议之前。对于长度为一个
月的 Sprint 来说，回顾会议时间最长不超过 3 小时。对于较短的 Sprint 来说，会议时
间通常会缩短。Scrum Master 要确保会议举行，并且每个参会者都明白会议的目的。

Sprint 回顾会议的目的在于：

• 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何；
• 找出并加以排序做得好的和潜在需要改进的主要方面； 同时，
• 制定改进 Scrum 团队工作方式的计划。

Scum工件

产品代办列表

Sprint代办列表（即上一个列表的一组，加上交付产品增量和实现Sprint目标的计划）

Sprint 待办列表是开发团队对于下一个产品增量所需的那些功能以及交付那些功能到“完成”的增量中所需工作的预测。
Sprint 产品待办列表是拥有足够细节的计划，任何进度的变化可以在每日 Scrum 站会中
清晰地看到。

增量

增量是一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增
量的价值总和。在 Sprint 的最后，新的增量必须是“完成”的，这意味着它必须可用并
且达到了 Scrum 团队“完成”的定义的标准。增量是在 Sprint 结束时支持经验主义的、
可检视的和已完成的产品组成部分。增量是迈向愿景或目标的一步。无论产品负责人是否
决定发布它，增量必须可用。

结语

这篇文档主要跟着官方文档走的，Scrum通常被称为敏捷开发，小团队，短期开发等特点。其中我们只需要把握几个大点，三个工件，四个活动，以及三个角色