Scrum敏捷项目管理入门_scrum敏捷项目中的燃尽图表现的是冲刺列表还是待办事项列表的工作量

Scrum开发

1. 定义

​ 用于开发和维护复杂产品的框架 ，是一个增量的、迭代的开发过程。整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。

​ Scrum原始含义是指英式橄榄球次要犯规时在犯规地点对阵争球。传统的“接力式”的开发模式已经不能满足快速灵活的市场需求，而整体或“橄榄球式”的方法——团队作为一个整体前进，在团队的内部传球并保持前进，这也许可以更好的满足当前激烈的市场竞争。

SCRUM框架包括3个角色、3个工件、5个事件、5个价值

• 3个角色

  1. 产品负责人（Product Owner）
  2. Scrum Master
  3. 开发团队

• 3个工件

  1. 产品Backlog（Product Backlog）
  2. SprintBacklog
  3. 产品增量（Increment）

• 5个事件

  1. Sprint（Sprint本身是一个事件，包括了如下4个事件）

  2. Sprint计划会议（Sprint Planning Meeting） （检验发布目标的进展，做出调整）

  3. 每日站会（Daily Scrum Meeting） （检验Sprint目标的进展，做出调整，从而优化次日的工作价值）

     开发团队至少在每日例会时追踪所有的剩余工作

  4. Sprint评审会议（Sprint Review Meeting） （检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值）

  5. Sprint回顾会议（Sprint Retrospective Meeting） （回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。）

• 5个价值

  1. 承诺 – 愿意对目标做出承诺
  2. 专注– 把你的心思和能力都用到你承诺的工作上去
  3. 开放– Scrum 把项目中的一切开放给每个人看
  4. 尊重– 每个人都有他独特的背景和经验
  5. 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重

2. 基本术语

Agile： 敏捷

Lean： 精益

Iterative：迭代式的

Iteration：迭代

Agile Manifesto： 敏捷宣言

Empirical： 经验性的

Empirical Process：经验性过程

Transparency： 透明性

Inspect and Adapt： 检视与调整

Sprint：原意为冲刺，Scrum中的Sprint无对应中文翻译，指一个迭代

Sprint Goal：Sprint目标

Product Owner ：产品负责人 简称PO

Scrum Master ：简称SM, 一般不翻译

Development Team ： Scrum开发团队

Scrum Team：指PO,SM和开发团队

Scrum Roles：Scrum角色，指PO,SM和开发团队

Emergent ：涌现的

Product Backlog：产品待办列表，指需求清单

Sprint Backlog：Sprint待办列表，指Sprint任务清单

Sprint Burn-down Chart：Sprint燃尽图，团队用于做Sprint内的进展跟踪

Release Burn-down Chart: 发布燃尽图，产品负责人做发布进展跟踪

Sprint Planning Meeting: Sprint计划会议

Daily Scrum Meeting：每日站会

Sprint Review Meeting：Sprint评审会议

Sprint Retrospective Meeting: Sprint回顾会议

Product Backlog Refinement: 产品待办列表梳理

Product Backlog Item: 产品待办清单条目，简称PBI

User Story: 用户故事，指一条需求

Story Point：衡量用户故事的工作量大小的计量单位

Velocity: 团队速度

Sprint Task: 实现一条需求需要做的一个技术任务

Definition of Done: DoD，完成的定义

Stakeholders： 干系人

Backlog： 待办列表

Artifact ：工件

Estimation ：估算

Collaboration： 协作

Scaling Scrum：大规模Scrum

3. 经验性过程

过程控制通常

• 第一种方式是预定义的过程。

  使用已知的方法解决已知的问题。制造业的生产线就是典型的预定义过程，例如生产饼干、啤酒、汽车的生产线等。预定义的过程的特点是给予固定的输入，得到固定的输出，过程可重复。它的优势在于可以大规模批量生产。预定义过程的缺点在于一旦过程定义出现错误，或产品设计上存在瑕疵，会造成比较大的损失。

• 第二种方式是经验性过程。 （===> 不断迭代 进行适应和调整）

  问题比较复杂，并且存在着较大的不确定性的时候，我们需要使用经验性过程。结果是不可预知的，生产过程是不可重复的。比如研究一项新技术，下一盘棋，踢一场球赛，在过程运行当中，我们需要通过不断的获得真实的反馈，然后进行适应和调整，使得过程能够产出我们需要的结果。

Scrum以 经验性过程控制理论 做为理论基础的过程。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。

Scrum过程框架的基石包括如下三个方面：

第一：透明性（Transparency）

透明度是指，在软件开发过程的各个环节保持高度的可见性，影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面，而且必须理解他们看到的内容。也就是说，当某个人在检验一个过程，并确信某一个任务已经完成时，这个完成必须等同于他们对完成的定义。

第二：检验（Inspection）

开发过程中的各方面必须做到足够频繁地检验，确保能够及时发现过程中的重大偏差。在确定检验频率时，需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度，那么就会出现问题。幸运的是，软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。

第三：适应（Adaptation）

如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准，并且最终产品是不合格的，那么便需要对过程或是材料进行调整。调整工作必须尽快实施，以减少进一步的偏差。

4. Scrum 三个角色

Scrum团队中包括三个角色，他们分别是产品负责人、开发团队和 Scrum Master。

Scrum 团队是自组织、跨职能的完整团队。自组织团队决定如何最好地完成他们的工作,而不是由团队外的其他人来指挥他们。

跨职能的团队拥有完成工作所需要的全部技能,不需要依赖团队外部的人。Scrum 团队模式的目的是最大限度地优化适应性、创造性和生产力。

Scrum 团队通过迭代和增量交付产品功能的方法最大化反馈的机会。增量交付潜在可交付的产品增量保证了 每个迭代都有潜在可发布的版本。

• Scrum角色之：产品负责人 （管理产品待办事项列表）

产品负责人负责最大化产品以及开发团队工作的价值。实现这一点的方式会随着组 织、Scrum 团队以及单个团队成员的不同而不同。

产品负责人是管理产品待办事项列表的唯一责任人。产品待办事项列表的管理包括:

• 清晰地表达产品待办事项列表条目
• 对产品待办事项列表中的条目进行排序,最好地实现目标和使命
• 确保开发团队所执行工作的价值
• 确保产品待办事项列表对所有人可见、透明、清晰,并且显示 Scrum 团队的下一步工作
• 确保开发团队对产品待办事项列表中的条目达到一定程度的理解

产品负责人可以亲自完成上述工作,也可以让开发团队来完成。然而,产品负责人是 负责任者。

产品负责人是一个人,而不是一个委员会。产品负责人可能会在产品待办事项列表中体现一个委员会的需求,但要想改变某条目的优先级必须先说服产品负责人。

为保证产品负责人的工作取得成功,组织中的所有人员都必须尊重他的决定。产品负责人所作的决定在产品待办事项列表的内容和排序中要清晰可见。任何人都不得要求开发团队按照另一套需求开展工作,开发团队也不允许听从任何其他人的指令。

• Scrum角色之：开发团队（包含完整流程的开发人员）

开发团队包含了专业人员,负责在每个 Sprint 的结尾交付潜在可发布的“完成”产 品增量。只有开发团队的成员才能创造增量。

开发团队由组织构建并授权,来组织和管理他们的工作。所产生的协同工作能最大化 开发团队的整体效率和效力。开发团队有以下几个特点:

• 他们是自组织的,没有人(即使是 Scrum Master 都不可以)告诉开发团队如何把产品待办事项列表变成潜在可发布的功能。
• 开发团队是跨职能的,团队作为一个整体拥有创造产品增量所需要的全部技能。
• Scrum 不认可开发团队成员的头衔,无论承担哪种工作他们都是开发者。此规则无一例外。
• 开发团队中的每个成员可以有特长和专注领域,但是责任归属于整个开发团队
• 开发团队 不包含如测试或业务分析等 负责特定领域的子团队。

开发团队的规模

开发团队最佳规模是小到足以保持敏捷性,大到足以完成重要工作。少于 3 人的开发团队没有足够的交互,因而所获得的生产力增长也不会很大。小团队在 Sprint 中可能会受到技能限制,从而导致无法交付可发布的产品增量。大于 9 人的团队需要过多的协调沟通工作。大型团队会产生太多复杂性,不便于经验过程管理。产品负责人和 Scrum Master 的角色不包含在此数字中,除非他们也参与执行 Sprint 代表事项列表中的工作。

• Scrum角色之：Scrum Master （服务于其他两者）

Scrum Master 负责确保 Scrum 被理解并实施。为了达到这个目的,Scrum Master要确保 Scrum 团队遵循 Scrum 的理论、实践和规则。Scrum Master是Scrum团队中的服务式领导。

Scrum Master 帮助 Scrum 团队外的人员了解他们如何与 Scrum 团队交互是有益的。 Scrum Master 通过改变这些交互来最大化 Scrum 团队所创造的价值。

Scrum Master 服务于产品负责人

• 找到有效管理产品待办事项列表的技巧

• 清晰地和开发团队沟通愿景、目标和产品待办事项列表条目

• 教导开发团队创建清晰简明的产品待办事项列表条目

• 在经验主义环境中理解长期的产品规划

• 理解并实践敏捷

• 按需推动Scrum活动

Scrum Master 服务于开发团队

• 指导开发团队自组织和跨职能
• 教导并领导开发团队创造高价值的产品
• 移除开发团队进展过程中的障碍
• 按需推动Scrum活动
• 在 Scrum 还未完全被采纳和理解的组织环境下指导开发团队

Scrum Master 服务于组织

• 领导并指导组织采用 Scrum
• 在组织范围内计划 Scrum 的实施
• 帮助员工及干系人理解并实施 Scrum 和经验性产品开发
• 发起能提升Scrum 团队生产力的变革
• 与其他 Scrum Master 一起工作,帮助组织更有效的应用Scrum

5. Scrum的三个工件

Scrum 的工件以不同的方式展现工作和价值,可以用来提供透明性以及检验和适应的机会。Scrum 中所定义的工件能最大化关键信息的透明性, 来保证 Scrum 团队成功地交付完成的增量。

• 工件一：PRODUCT BACKLOG – 产品待办事项列表

产品待办事项列表是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。

产品待办事项列表是一个持续完善的清单, 最初的版本只列出最初始的和众所周知的需求。 产品待办事项列表根据产品和开发环境的变化而演进。待办事项列表是动态的,它经常发生变化以识别使产品合理、有竞争力和有用所必需的东西。只要产品存在,产品待办事项列表就存在。

产品待办事项列表列出了所有的特性、功能、需求、改进方法和缺陷修复等对未来发布产品进行的改变。产品待办事项列表条目包含描述、次序和估算的特征。

产品待办事项列表通常以价值、风险、优先级和必须性排序。它是一个按照优先级由高到低排列的一个序列，每个条目有唯一的顺序。排在顶部的产品待办事项列表条目需要立即进行开发。排序越高,产品待办事项列表条目越紧急,就越需要仔细斟酌,并且对其价值的意见越一致。

排序越高的产品待办事项列表条目比排序低的更清晰、更具体。根据更清晰的内容和 更详尽的信息就能做出更准确的估算。优先级越低,细节信息越少。开发团队在接下来的 Sprint 中将要进行开发的产品待办事项列表条目是细粒度的,已经被分解过,因此,任何 一个条目在 Sprint 的时间盒内都可以被“完成”。开发团队在一个 Sprint 中可以“完 成”的产品待办事项列表条目被认为是“准备好的”或者“可执行的”,能在 Sprint 计 划会议中被选择。

随着产品的使用、价值的获取以及市场的反馈,产品待办事项列表变成了更大、更详 尽的列表。因为需求永远不会停止改变,所以产品待办事项列表是个不断更新的工件。业 务需求、市场形势和技术的变化都会引起产品待办事项列表的变化。

若干个 Scrum 团队常常会一起开发某个产品。但描述下一步产品开发工作的产品待办事项列表只能有一个。那么这就需要使用对产品待办事项列表条目进行分组的属性。

通过产品Backlog地梳理来增添细节、估算和排序。这是一个持续不断 的过程,产品负责人和开发团队协作讨论产品代表事项列表条目的细节。在产品待办事项列表梳理的时候,条目会被评审和修改。然而, 产品负责人可以随时更新产品代办事项列表条目或酌情决定。

梳理在 Sprint 中是一项兼职活动,在产品负责人和开发团队之间展开。通常,开发 团队有自行优化的领域知识。然而,何时如何完成优化是 Scrum 团队的决定。优化通常占用不超过开发团队 10%的时间。

开发团队负责所有的估算工作。产品负责人可以通过协助团队权衡取舍来影响他们的 决定。但是,最后的估算是由执行工作的人来决定的。

监控向目标前进的进度

在任何时间,达成目标的剩余工作量是可以被累计的。产品负责人至少在每个 Sprint 评审的时候追踪剩余工作总量。产品负责人把这个数量与之前 Sprint 评审时的剩余工作 量做比较,来评估在希望的时间点完成预计工作达成目标的进度。这份信息对所有的干系人都透明。

Scrum 不考虑已经花在产品代办事项列表条目上的工作时间。我们只关心剩余工作和日期这两个变量。

各种趋势燃尽图、燃烧图和其他计划实践都能用来预测进度。它们已经被证实有用。 然而,这并不能代替经验主义的重要性。在复杂的环境下,将要发生的东西是未知的,只有已经发生的事情才能用来做前瞻式的决策。

• 工件二：SPRINT BACKLOG

Sprint 代办事项列表是一组为当前 Sprint 选出的产品代办事项列表条目,外加交付 产品增量和实现 Sprint 目标的计划。Sprint 代办事项列表是开发团队对于哪些功能要包 含在下个增量中,以及交付那些功能所需工作的预计。

Sprint 代办事项列表定义了开发团队把产品代办事项列表条目转换成“完成”的增量 所需要执行的工作。Sprint 代办事项列表使开发团队确定的、达到 Sprint 目标所需的工 作清晰可见。

Sprint 代办事项列表是一份足够具体的计划,使得进度上的改变能在每日例会中得到 理解。开发团队在整个 Sprint 中都会修改 Sprint 代办事项列表,Sprint 代办事项列表也 会在 Sprint 的进程中慢慢显现,比如开发团队按照计划工作并对完成 Sprint 目标所需的 工作有更多的了解。

当出现新工作时,开发团队需要将其追加到 Sprint 待办事项列表中去。随着任务进 行或者被完成,需要更新每项任务的估算剩余工作量。如果计划中某个部分失去开发的意 义,就可以将其除去。在 Sprint 内只有开发团队可以对 Sprint 待办事项列表进行修改。 Sprint 待办事项列表是高度可见的,是对团队计划在当前 Sprint 内完成工作的实时反 映,并且,该列表只属于开发团队。

Product Backlog 功能点被放到Sprint的固定周期中，Sprint Backlog 会因为如下原因发生变化:

1. 随着时间的变化，开发团队对于需求有了更好理解，有可能发现需要增加一些新的任务到Sprint Backlog中。

2. 程序缺陷做为新的任务加进来，这个都做为承诺提交任务中未完成的工作。

Product Owner也许会和Scrum team一起工作，以帮助team更好的理解Sprint的目标，ScrumMaster和team也许会觉得小的调整不会影响sprint的进度，但会给客户带来更多商业价值。

监控 Sprint 进度

在 Sprint 中的任意时间点,Sprint 待办事项列表的所有剩余工作总和都可以被计算。开发团队至少在每日例会时追踪所有的剩余工作。开发团队每天追踪剩余总和并预测 达成 Sprint 目标的可能性。通过在 Sprint 中不断追踪剩余工作,开发团队可以管理自己 的进度。

Scrum 不考虑已经花在 Sprint 待办事项列表上的工作时间。我们只关心剩余工作和日期这两个变量。

通过燃尽图（Burn-down Chart)跟进进展

Sprint燃尽图（Sprint Burn-down Chart)

Sprint Burndown Chart 显示了Sprint中累积剩余的工作量，它是一个反映工作量完成状况的趋势图。 图中Y轴代表的是剩余工作量，X轴代表的是Sprint的工作日。

在Sprint开始的时候，Scrum Team会标示和估计在这个Sprint需要完成的详细的任务。所有这个Sprint中需要完成，但没有完成的任务的工作量是累积工作量，团队会根据进展情况每天更新累积工作量，如果在Sprint结束时，累积工作量降低到0，Sprint就成功结束。

由于在Sprint的刚开始的时候，增加的任务工作量可能大于完成的任务工作量，所以燃尽图有可能略微呈上升趋势。

发布燃尽图（Release Burn-down Chart）

在Scrum项目中，团队通过每个Sprint结束时更新的发布燃尽图来跟踪整个发布计划的进展。发布燃尽图记录了在一段时间内产品Backlog的总剩余估算工作量的变化趋势。X轴代表的项目周期，以Sprint为单位， Y轴代表的是剩余工作量，通常以用户故事点、理想人天或者team-days为单位。

• 工件三：产品增量（PRODUCT INCREMENT）

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

6. Scrum的五个事件

Scrum 使用固定的事件来产生规律性，以此来减少 Scrum 之外的其它会议的必要。所有事 件都是有时间盒限定的事件，也就是说每一个事件限制在最长的时间范围内。一旦 Sprint 开始，它的持续时间是固定的，不能缩短或者延长。而其他事件则可以在该事件的目标达成之后可以立即终止，如此确保时间被适当地使用而不会造成过程中的浪费。

Sprint 除了本身作为一个事件以外，它还是其他所有事件的容器，在 Scrum中的每个事件都是用来进行检视和适应的正式机会。这些事件都是被特别设计用来确保达成透明和检视。如果 Sprint不能成功地包含这些事件中的任何一个事件，导致透明化的降低，同时也会丧失进行检视与适应的机会。

• 事件一：Sprint

Sprint 是 Scrum 的核心，其长度(持续时间)为一个月或更短时间的限时，在这段时间内 构建一个“完成的”、可用的和潜在可发布的产品增量。在整个开发过程期间，Sprint 的长 度通常保持一致。前一个 Sprint 结束后，新的下一个 Sprint 紧接着立即开始。
Sprint由 Sprint计划会议、每日Scrum 站会、开发工作、 Sprint评审会议和 Sprint回顾会议构成。

在 Sprint 期间:

• 不能做出有害于 Sprint 目标的改变;
• 不能降低质量的目标;以及,
• 随着对信息掌握的增加，产品负责人与开发团队之间对范围内要做的事可能会要澄清 和重新协商。

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

Sprint 的长度限制在一个月内。当 Sprint 的长度太长的话，对要构建什么的定义就有可能 会改变，复杂性也有可能会增加，同时风险也有可能会增加。Sprint 通过确保至少每月一 次对达成目标的进度进行检视和适应，来实现可预测性。Sprint 同时也把风险限制在一个 月的成本上。

取消 Sprint

Sprint 可以在 Sprint 时间盒结束之前取消。只有产品负责人才有取消 Sprint 的权力，虽然 他或她做这样的决定也可能受到来自利益攸关者、开发团队或是 Scrum Master 的影响。
如果 Sprint 目标过时，那么 Sprint 就会被取消。比如公司的发展方向或者市场上或技术上 的状况发生改变，这些变化都可能导致 Sprint 被取消。总的来说，如果某个 Sprint 对其所 在环境来说失去了价值和意义，那么它就应该被取消。然而，由于 Sprint 的时间都很短， 所以取消 Sprint 的意义不大。

当取消某个 Sprint 时，任何做完和“完成”的产品待办列表项都需要评审。假如成果的任何 部分具有潜在可发布的话，产品负责人通常会接受这个成果。所有未完成的产品待办列表 项都会被放回到产品待办列表中，并重新估算。花在它们身上的工作会很快地贬值，所以 必须经常性地重估。

取消 Sprint 会消耗资源，因为每个人都必须重新集合在另一个 Sprint 计划会议来开始另一 个 Sprint 。取消 Sprint 通常会对 Scrum 团队造成重创，这种情况非常罕见。

• 事件二：Sprint 计划会议

Sprint 中要做的工作在 Sprint 计划会议中来做计划。这份工作计划是由整个 Scrum 团队共 同协作完成的。

Sprint 计划会议是限时的，以一个月的 Sprint 来说最多 8 小时为上限。对于较短的 Sprint， 会议时间通常会缩短。Scrum Master 要确保会议顺利举行，并且每个参会者都理解会议的 目的。 Scrum Master 要教导 Scrum 团队遵守时间盒的规则。

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

1. 接下来的 Sprint 交付的增量中要包含什么内容?

2. 要如何完成交付增量所需的工作?

话题一: 这次 Sprint 能做什么?
开发团队预测在这次 Sprint 中要开发的功能。产品负责人讲解 Sprint 的目标以及达成该目 标所需完成的产品待办列表项。整个 Scrum 团队协同工作来理解 Sprint 的工作。

Sprint 会议的输入是产品待办列表、最新的产品增量、开发团队在这个 Sprint 中能力的预 测以及开发团队的以往表现。开发团队自己决定选择产品待办列表项的数量。只有开发团 队可以评估接下来的 Sprint 可以完成什么工作。

在开发团队预测完这个 Sprint 中可交付的产品待办列表项之后，Scrum 团队草拟一个 Sprint 目标。Sprint 目标是在这个 Sprint 通过实现产品待办列表要达到的目的，同时它也为 开发团队提供指引，使得开发团队明确开发增量的目的。

话题二: 如何完成所选的工作?

在设定了 Sprint 目标并选出这个 Sprint 要完成的产品待办列表项之后，开发团队将决定如 何在 Sprint 中把这些功能构建成“完成”的产品增量。这个 Sprint 中所选出的产品待办列表 项加上交付它们的计划称之为 Sprint 待办列表。

开发团队通常从设计整个系统开始，到如何将产品待办列表转换成可工作的产品增量所需 要的工作。工作有不同的大小，或者不同的预估工作量。然而，在 Sprint 计划会议中，开 发团队已经挑选出足够量的工作，以此来预估他们在即将到来的 Sprint 中能够完成。在 Sprint 计划会议的最后，开发团队规划出在 Sprint 最初几天内所要做的工作，通常以一天 或更少为一个单位。开发团队自组织地领取 Sprint 待办产品列表中的工作，领取工作在 Sprint 计划会议和 Sprint 期间按需进行。

产品负责人能够帮助解释清楚所选定的产品待办列表项，并作出权衡。如果开发团队认为 工作过多或过少，他们可以与产品负责人重新协商所选的产品待办列表项。开发团队也可 以邀请其他人员参加会议，以获得技术或领域知识方面的建议。

在 Sprint 计划会议结束时，开发团队应该能够向产品负责人和 Scrum Master 解释他们将如 何以自组织团队的形式完成 Sprint 目标并开发出预期的产品增量。

Sprint目标

Sprint 目标是在当前 Sprint 通过实现产品待办列表要达到的目的。它为开发团队提供指 引，使得团队明确为什么要构建增量。Sprint 目标在 Sprint 计划会议中确定。Sprint 目标为 开发团队在 Sprint 中所实现的功能留有一定的弹性。所选定的产品待办列表项会提供一个 连贯一致的功能，也即是 Sprint 目标。Sprint 目标可以是任何其他的连贯性来促使开发团 队一起工作而不是分开独自做。

开发团队必须在工作中时刻谨记 Sprint 目标。为了达成 Sprint 目标，需要实现相应的功能 和实施所需的技术。如果所需工作和预期的不同，开发团队需要与产品负责人沟通协商 Sprint 待办列表的范围。

• 事件三：每日Scrum站会

每日 Scrum 站会是一个以 15 分钟为限的事件，它让开发团队同步开发活动，并为接下了

的 24 小时制定计划。这需要检视上次每日站会以来的工作和预测下次每日站会之前所能 够完成的工作。

每日 Scrum 站会在同一时间同一地点举行，以便降低复杂性。在会议上，每一个开发团队 成员都需要说明:

• 昨天，我为帮助开发团队达成 Sprint 目标做了什么?
• 今天，我为帮助开发团队达成 Sprint 目标准备做什么?
• 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标?

开发团队借由每日 Scrum 站会来检视完成 Sprint 目标的进度，并检视完成 Sprint 待办列表 的工作进度趋势。每日 Scrum 站会优化了开发团队达成 Sprint 目标的可能性。每天，开发 团队应该知道如何以自组织团队来协同工作以达成 Sprint 目标，并在 Sprint 结束时开发出 预期中的增量。开发团队或者开发团队成员通常会在每日 Scrum 站会后立即聚到一起进行 更详细的讨论，或者为 Sprint 中剩余的工作进行调整或重新计划。

Scrum Master 确保开发团队每日站会如期举行，但开发团队自己负责召开会议。Scrum Master 教导开发团队将每日 Scrum 会议时间控制在 15 分钟内。

Scrum Master 强制执行每日 Scrum 站会规则——只有开发团队成员才能参加。
每日 Scrum 站会增进交流沟通、减少其他会议、发现开发过程中需要移除的障碍、突显并

促进快速地做决策、提高开发团队的认知程度。这是一个进行检视与适应的关键会议。

事件四：Sprint 评审会议

Sprint 评审会议在 Sprint 快结束时举行 ，用以检视所交付的产品增量并按需调整产品待办 列表。在 Sprint 评审会议中，Scrum 团队和利益攸关者协同讨论在这次 Sprint 中所完成的 工作。根据完成情况和 Sprint 期间产品待办列表的变化，所有参会人员协同讨论接下来可 能要做的事情来优化价值。这是一个非正式会议，并不是一个进度汇报会议，演示增量的 目的是为了获取反馈并促进合作。

对于长度为一个月的 Sprint 来说，评审会议的限时为 4 小时。对于较短的 Sprint 来说，会 议的时间会有所缩短。Scrum Master 要确保会议举行，并且每个参会者都明白会议的目 的。Scrum Master 教导大家遵守时间盒的规则。

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

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

Sprint 评审会议的结果是一份修订后的产品待办列表，阐明很可能进入下个 Sprint 的产品 待办列表项。产品待办列表也有可能为了迎接新的机会而进行全局性地调整。

事件五：Sprint 回顾会议

Sprint 回顾会议是 Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。

Sprint 回顾会议发生在 Sprint 评审会议结束之后，下个 Sprint 计划会议之前。对于长度为 一个月的 Sprint 来说，会议的限时为 3 小时。对于较短的 Sprint 来说，会议时间通常会缩 短。Scrum Master 要确保会议举行，并且每个参会者都明白会议的目的。Scrum Master 教 导大家遵守时间盒的规则。Scrum Master 作为 Scrum 过程的责任者，作为团队的一员参加 该会议。

Sprint 回顾会议的目的在于:

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

Scrum Master 鼓励 Scrum 团队在 Scrum 的过程框架内改进开发过程和实践，使得他们能在 下个 Sprint 中更高效更愉快。在每个 Sprint 回顾会议中，Scrum 团队通过适当地调整“完 成”的定义的方式来计划提高产品质量。

在 Sprint 回顾会议结束时，Scrum 团队应该明确接下来的 Sprint 中需要实施的改进。在下 一个 Sprint 中实施这些改进是基于 Scrum 团队对自身的检视而做出的适当调整。虽然改进 可以在任何时间执行，Sprint 回顾会议提供了一个专注于检视和适应的正式机会。

7. SCRUM的五个价值观

1. 承诺 – 愿意对目标做出承诺
2. 专注– 把你的心思和能力都用到你承诺的工作上去
3. 开放– Scrum 把项目中的一切开放给每个人看
4. 尊重– 每个人都有他独特的背景和经验
5. 勇气– 有勇气做出承诺，履行承诺，接受别人的尊重

8. SCRUM的四大支柱

迭代开发

在Scrum的开发模式下，我们将开发周期分成多个1-4周的迭代，每个迭代都交付一些增量的可工作的功能。迭代的长度是固定的，如果我们选择了1周的迭代，那么保持它的长度不要发生变化，在整个产品开发周期内每个迭代都是1周的长度。这里需要强调的是在每个迭代必须产出可工作的增量功能，而不是第一个迭代做需求、第二个迭代做设计、第三个迭代做代码。

增量交付

增量是一个 Sprint 及以前所有 Sprint 中完成的所有产品代办事项列表条目的总和。 在 Sprint 的结尾,新的增量必须“完成”,这意味着它必须可用并且达到了 Scrum 团队 “完成”的定义的标准。无论产品负责人是否决定真正发布它,增量必须可用。增量是从用户的角度来描述的，它意味着从用户的角度可工作。

自组织团队 （团队内自我决定/分工）

Scrum团队是一个自组织的团队，*传统的命令与控制式的团队只有执行任务的权利，而自组织团队有权进行设计、计划和执行任务*，自组织团队还需要自己监督和管理他们的工程过程和进度，自组织团队自己决定团队内如何开展工作，决定谁来做什么，即分工协作的方式。

高优先级的需求驱动

在Scrum中，我们使用Product Backlog来管理需求，Product Backlog是一个需求的清单，Product Backlog中的需求是渐进明细的，Backlog当中的条目必须按照商业价值的高低排序。Scrum团队在开发需求的时候，从Backlog最上层的高优先级的需求开始开发。在Scrum中，只要有足够1-2个Sprint开发的细化了的高优先级的需求，我们就可以启动Sprint了，而不必等到所有的需求都细化之后。我们可以在开发期间通过Backlog的梳理来逐步的细化需求。

9. SCRUM团队

在传统的工作方式下，开发团队会有很多不同的角色，比如项目经理、产品经理、架构师、设计师、用户体验设计师，程序员，测试人员，DBA等等。但是，在Scrum的工作方式下，总共只有三个角色， 这三个角色分别是产品负责人（PO）,Scrum Master和开发团队。

我们通常可以以划龙舟的团队角色来类比Scrum的角色，划龙舟通常有舵手、鼓手、划桨团队三个角色。Scrum中的PO就是舵手的角色，他对产品的方向负责，对产品的Why和What负责，对产品的愿景，产品包括哪些主要的特性负责。Scrum中的Scrum Master鼓手的角色，他帮助团队保持高昂的士气，并进行良好的协作，他是一个Scrum的专家，团队的教练，团队的服务式领导。Scrum中的开发团队，对应到龙舟赛的划桨团队，开发团队必须协调一致，作为一个整体前进，在这样的环境下单打独斗，各自为政没有任何胜算。

Scrum的开发团队对实现Sprint目标需要做的所有事情负责，包括技术方案和决策，团队分工（谁做什么），执行Sprint开发任务等，而且作为自组织的团队，他们也对他们的工作进度的跟踪和管理负责。Scrum开发团队的主要职责包括如下五个方面：

• 执行Sprint
• 梳理产品Backlog
• 做Sprint计划
• 每天跟进工作进展，并对他们的工作做检查和调整
• 每个迭代对产品和团队的工作过程做检查和调整

开发团队有如下10方面的特征：

• 自组织
• 多元化、跨职能的完整团队
• 团队成员符合T型技能，即一专多长
• 持续改进
• 最大限制的沟通
• 透明沟通
• 2个披萨的团队大小（5-9人）
• 专注、投入
• 按照可持续的节奏工作
• 团队长期存在，人员稳定

10. 自组织团队

什么是自组织团队？

自组织团队是敏捷软件开发的基本观念 。敏捷宣言的原则中提到 :“最好的架构、需求和设计出于自组织团队 ”。自组织团队也叫做自管理团队、或者被授权的团队。团队被授权自己管理他们的工作过程和进度、并且团队决定如何完成工作。

自组织团队和经理领导的团队的区别

对于经理领导的团队来说，团队成员被分配任务，团队成员只有执行任务的权利。

对于经理领导的团队来说，管理者除了要确定目标、方向，团队的上下文（组织结构、团队结构、团队组成），还需要监督和管理团队的过程和进度，分配任务即确定谁做什么。这种团队的管理方式，更多的是命令与控制，以及微观管理。

对于自组织团队来说，他们拥有如下权利：

• 团队决定谁做什么，即任务的分配
• 团队决定如何做，如何实现目标，即团队做技术决策
• 团队需要在确保目标的前提下制定团队内的行为准则
• 团队有义务保持过程的透明性
• 团队监督和管理他们的过程和进度

在自组织团队的环境下，管理层关注在如下几个方面：

• 确定团队目标和愿景
• 确定团队上下文，组织结构、团队结构、团队组成
• 提供环境和支持（安全感、良好的团队空间、氛围，技能辅导等）
• 授权团队
• 训练协作

对于自组织团队的普遍误解：

• 误解1：团队自己决定目标是什么 ； 纠正：管理层决定团队目标
• 误解2：团队自己决定谁进入团队； 纠正：管理层决定团队上下文
• 误解3：团队自己设计团队结构； 纠正：管理层决定团队上下文
• 误解4：自组织团队不需要管理者； 纠正：管理者从微观管理转向目标驱动、授权团队的管理方式
• 误解5：自组织团队需要员工更加主动； 纠正：自组织让团队更加主动，每个人都不喜欢被命令和控制，每个人期望有成就感、期望被认可
• 误解6：自组织团队想干什么就干什么； 纠正：管理层决定团队目标，团队决定如何实现目标

一个自组织的团队通常由不同职能专业、思考方式和行为模式的成员组成，也就是说它是跨职能的团队。

自组织的团队不是与生俱来的，打造一个团队需要一个过程，打造一个组织团队也是一样。打造自组织团队，首先要让团队需要完全自主； 其次，有了自主，管理者需要引导团队持续改进，帮助团队持续地挑战更高的目标；第三，给团队提供环境和支持，引导团队往正确地方向迈进。

11. 特性团队

如果我们的产品开发团队只有在10人以内，我们使用一个跨职能的Scrum团队，可以很容易地按照scrum和敏捷的方式开发产品。 但是，如果产品团队规模较大，比如是几十人，甚至几百人的开发团队的时候，我们就需要考虑团队的结构和组织方式。

在一个大的开发组织中，Scrum会把大的开发团队划分成多个5-9人的小团队，那么我们应该按照什么方式来划分呢？

在传统的开发模式下，我们习惯于按照系统的架构模块，或者系统分层组织团队，也有的团队按照系统需求、开发、测试结合系统架构混合组织的方式。这种团队组织的方式，我们称之为组件团队，是指每个团队只是完成系统功能的某一个部件，而不是一个端到端用户可见的功能。

组件团队看起来像这个样子：

按照Scrum和敏捷的交付模式，组件团队有如下一些限制：

第一：按照组件来组织团队，很难避免团队之间的依赖，跨团队的协调和依赖管理更加复杂，不利于跨组件或者各个层之间的沟通。

第二：每个团队专注在自己的模块，由于各模块、或分层需求工作量的不同，很容易产生等待，并且容易产生低价值的交付。

第三：由于职责单一，限制了学习，使得专业更加单一化

第四：Sprint结束的时候无法提交可交付的增量产品功能，延迟价值交付

按照Scrum和敏捷的交付模式，以用户为中心，按照用户场景作为边界来组织团队是比较推荐的做法。这种以用户为中心的团队叫做特性团队。

特性团队的特点：

• 长期稳定的团队，逐个端到端完成客户特性
• 以客户为中心的特性驱动
• 跨职能、完整团队
• 共享代码库，统一的持续集成
• 拥有通用型专家

特性团队看起来像这个样子：

特性团队的好处：

• 团队内可以做到端到端，所以减少了等待，周期加快
• 比较容易在一个Sprint中交付可用的产品增量
• 减少了团队之间依赖，计划会更容易
• 责任范围的扩大，各种不同领域的专家在一个团队，增加了
• 个人学习和团队学习的机会

12. 用户故事

什么是用户故事？

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：

1. 角色：谁要使用这个功能。

2. 活动：需要完成什么样的功能。

3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达：

英文：As a , I want to , so that .

中文：作为一个<角色>, 我想要<活动>, 以便于<商业价值>

举例：

作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”

需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。

Ron Jeffries的3个C

关于用户故事，Ron Jeffries用3个C来描述它：

• 卡片（Card） – 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。
• 交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
• 确认（Confirmation）- 通过验收测试确认用户故事被正确完成。

用户故事的六个特性- INVEST

INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

一个好的用户故事应该遵循INVEST原则。

• 独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
• 可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
• 有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
• 可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
• 短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
• 可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。

13. 敏捷估算

无论是团队研发一款产品或者开发某一个项目，我们都需要回答“我们大概什么时间能够完成？”， 或者到某一个时间点，我们能够做到什么程度， 因此和传统的开发模式一样，我们在工作开始之前需要对我们需要做的事情进行工作量的估算。

相对与传统的工作量估算方式，敏捷估算有如下几个特点：

1. 团队集体估算

在Scrum的开发过程中，团队共担责任，集体承诺每个Sprint的工作，因此对于工作量的估算敏捷团队采用集体估算的方式。集体估算，通常采用估算扑克作为工具，团队通过玩估算游戏进行集体估算。使用估算扑克来做工作量估算是最有效，也是非常有趣的一种估算方式。估算扑克由一组类似斐波纳契数列的数字组成，这些数字包括：0，0.5,1,2,3,5,8,20,40,?,∞, 每幅扑克有四组这样的数字，可供4个人使用。

估算扑克的使用方法：

• 每个团队成员拿到一组卡片，包括0,0.5,1,2,3,5,8,13,20,40,?,∞,共计12张。
• 产品负责人或者一名团队成员扮演阅读者的角色，他负责阅读需要估算产品Backlog的条目，并且询问大家是否有疑问。
• 团队讨论这个条目。
• 当团队理解了这个条目之后，每个团队成员按照自己的想法给出估算结果，并且选择对应的扑克出牌，估算结果不能告诉其他人，出牌时数字朝下扣在桌面上。
• 所有人都出牌之后，阅读者向大家确认是否都已经确定估算结果，确认后，数”1,2,3″,大家同时展示估算结果。
• 团队评估不同的估算结果.我们是否想法一致？我们是否存在分歧？有没有什么是我没有考虑到的？讨论之后可以再估算一轮，最终团队需要达成一致。
• 回到第二步，开始估算下一个条目。

关注Scrum中文网微信公众号可以获得微信版估算扑克。

2. 估算大小，而不是估算时间周期，使用相对估算，而不是绝对估算

一瓶矿泉水，让一个3岁的小妹妹把它喝完所花的时间和一个成年人把它喝完所花的时间肯定不一样，因此同一项工作，不同能力的人完成它花费的时间显然是不一样的。如果我们要估算从家到公司的绝对距离时多少公里，您可能不一定知道，但是如果您时做地铁上班，从家里到公司有多少站，你一定很容易知道，当我们知道有多少站之后，我们就可以大概清楚路上需要花多长时间了。敏捷估算时，我们不会估算绝对时间和周期，我们估算大小，和相对值，也就是倍数。敏捷估算时，我们使用故事点作为计量单位，它是一个倍数，我们会先找一个我们认为最小的一个功能的大小作为参考基准，定义为1个故事点，把其它的故事和它做比较，如果是2倍大小，就是2个故事点，如果是5倍大小，就是5个故事点。

3. 记录每个Sprint的团队速度

团队速率是一个Scrum团队在一个Sprint中实际完成的故事点数，通过团队速率可以知道团队做的有多快。新开始的项目或产品开发，或者是新团队，没有初始速度，我们可以做1-2个Sprint测算一个速度，作为初始速度。在Sprint执行过程中，我们要记录每个Sprint的速度，为以后的计划做参考。

我们估算了产品Backlog的故事点总数，然后又知道了每个Sprint团队的平均速度，那么我们就可以推算我们大概需要多少个Sprint可以做完，这样我们就得到了周期。

14. sprint

Scrum是一种迭代和增量式的产品开发方法，Scrum通过Sprint来实现迭代。一个Sprint是指一个1周－4周的迭代，它是一个时间盒。Sprint的长度一旦确定，保持不变。Sprint的产出是“完成”的、可用 的、潜在可发布的产品增量。Sprint 在整个开发过程中的周期一致。新的 Sprint 在上一 个 Sprint 完成之后立即开始。
Sprint 包含并由 Sprint 计划会议、每日站会、开发工作、Sprint 评审会议和 Sprint 回顾会议构成。

Scrum采用迭代增量的方式，是因为需求是涌现的，我们对产品和需求的理解是渐进式的，Sprint长度越长，我们需要预测的越多，复杂度会提升、风险也会增加，所以Sprint的长度最多不超过4周。越来越多的团队使用2周的Sprint，很多市场变化快、竞争激烈的领域，比如互联网和移动互联网产品开发团队也会使用1周的迭代。

在Sprint进行过程中，如下内容不能发生变化：

• Sprint的目标
• Sprint的质量目标和验收标准
• 开发团队的组成

集中优势兵力各个击破

在Sprint执行的过程中，团队要避免一个萝卜一个坑的工作方式，团队要协作，并且要集中优势兵力各个击破。

团队按照蜂拥式（Swarming）的工作方式，团队先集中工作在少数几个需求上面，协作完成它们，然后在开始下一批需求。按照这样的方式一方面可以加强团队协作，另外也有利于及早完成一些需求，让这些需求及早验收。

取消一个 Sprint

Sprint 可以在 Sprint 时间结束之前取消。只有产品负责人才有取消 Sprint 的权力,但他做这样的决定也可能是受到利益干系人、团队或是 Scrum Master 的影响。

如果某个 Sprint 的目标过时了,那么就需要取消该 Sprint。比如公司的发展方向, 或是市场、技术等情况发生了变化,这些变化都可能导致取消 Sprint。总的来说,如果某 个 Sprint 对于其所在环境来说失去了价值和意义,那么它就应该被取消。然而,因为 Sprint 周期都较短,所以很少发生取消 Sprint 的情况。

当某个 Sprint 被取消时,任何做完和“完成”的产品待办事项列表条目都需要评审。假如有些条目已经潜在可交付,那产品负责人就会采纳它。所有未完成的条目就都要 放回到产品待办事项列表中,并重新估算。花在它们身上的工作会迅速贬值,所以需要频繁地重估。

取消 Sprint 会消耗资源,因为每个人都需要在新召开的 Sprint 计划会议中重新开始 另一个 Sprint。Sprint 终止通常会对团队造成重创,因此这种情况也非常少见。

15. 每日站会

每人说明：昨天完成了哪些，有没有遇到什么障碍，今天要做什么

会上不做讨论（需要讨论，记录下来，会后讨论）

每日站会的目的

在介绍如何开每日站会前， 让我们先了解一下召开每天的站会的目的和意义是什么？敏捷宣言强调个体交互重于过程和工具，敏捷原则阐述了面对面的沟通和自组织的团队这些敏捷的核心思想。Scrum的团队是一个自组织的团队，团队每天进行每日站会是团队面对面沟通和团队自组织的体现。Scrum的理论基础是通过保持过程透明性让参与过程的所有人了解真实状况，然后进行检查和调整，每日站会是Scrum过程进行每天的检查和调整的环节。

每日站会是团队自己的会

• 团队商量决定谁做什么（不能有领导任务指派），为当天排一个计划
• 团队沟通状态，了解现状，发现障碍
• 团队回顾昨天的工作，做调整，持续改进

什么时候、在什么地点开每日站会？

Scrum定义了开展每日站会的一些基本的规则。每日站会必须每天在同一时间、同一地点召开，最好的方式是在团队的可视化的任务板前面召开。 任务板上可以看到当前Sprint的燃尽图（Burn Down Chart）和Sprint中每个任务的状态。

在每日站会开始之前，团队需要在任务板上更新任务的状态。这样的好处是在开会的时候，每个人都可以看到当前的进展情况。

每日站会是Scrum团队每天的第一件事情，这样可以让每个人在每天一开始就清楚的了解他一天的安排。对于跨国界的团队，存在时间差的情况，可以根据实际情况做调整。

每日站会的纪律

会议时间最多不超过15分钟。所有的团队成员自觉按时到场，因为会议很短，按时召开按时结束是很重要的。团队需要建立他们的工作协议来确保团队成员按时出席，并且遵守站会纪律，比如团队可以商量对于迟到的人员要有一些让他们改进的措施，比如适当的给一些罚金，多少由团队共同决定，这些钱如何支配也由团队共同决定， 或者做俯卧撑、挂一个迟到的牌子等等。

每日站会一定要站着开，每个人要精神集中，不能有懒散的表现。

每个人回答三个问题：

我昨天完成了什么任务？

我今天打算做什么任务？

我遇到了哪些障碍或困难？

同一时间只能有一个人发言，会上只说和这三个问题相关的话题，任何跑题的讨论，需要被ScrumMaster制止。一些的确需要讨论的问题，可以先记录下来，会后作为专题来讨论。

为什么每日站会没有效果？

每日站会和传统的项目会议有如下几点不同：

1. 不会有ScrumMaster或者其他任何人来指派任务。

2. 团队成员不是向ScrumMaster汇报情况，每日站会是团队自己的会。

3. 团队成员不会在会上讨论或者解决问题，大家会把问题记录下来，会后找相关的人讨论或召开具体的讨论会议。

4. 任何团队之外的人不得发言或干扰会议。

Scrum的最基本原则是“Inspect and Adapt”(检视然后适应)，如果什么事情做得很好，问问自己为什么，然后寻找提升的办法。

如果每日站会没有效果，检查一下这些规则：你是不是每天在认真开每日站会？如果不是为什么？如果你改变了Scrum的一些基本的规则，你可能会面临一些风险，因为这些规则都是经过锤炼和项目考验的一些通用规则。所以第一步，你可以先按照书本上的方式来做。

如果这还不够，参考一下其他人的实践经验，比如：Martin Fowler’s 《Patterns of Daily Stand-up Meetings》

你如何知道每日站会起到了很好的效果？

一个好的每日站会有如下几个特点：

1. ScrumMaster不会逐个的问每个人问题，如果是，那么这个会议已经沦为了报告会。

2. 团队成员互相交流，不是向ScrumMaster报告。

3. 每日站会都会在15分钟以内完成。如果你遵守了规则并按照正确的方式开会，你就不需要再担心超时了。

4. 站会结束后，ScrumMaster 知道哪些问题需要帮助团队成员解决。

一个自组织的团队有一个非常明显的每天的节奏：Daily Scrum之前非常安静，每日站会之后会有一段活跃的讨论，到中餐前的时候就慢慢安静下来了。午饭之后会有另外一个阶段的活跃讨论，当下班前慢慢的安静下来。这就是一个自组织团队的脉冲。如果你能够感受到这个节奏，则说明团队是很健康的，每日站会起到了很好的效果。

16. “完成”的定义

当产品代办事项列表条目或者增量被描述为“完成”的时候,每个人都必须理解“完 成”意味着什么。虽然这在不同的 Scrum 团队之间会有巨大的差别,但是团队成员必须对 完成工作意味着什么有相同的理解,这样才能保证透明性。这就是 Scrum 团队的“完成” 定义,用来评估产品增量在什么时候完成。

这个定义也同时被用来指导开发团队了解在 Sprint 计划会议的时候他们能选择多少 产品代办事项列表条目。每个 Sprint 的目标都是交付遵循 Scrum 团队当前的“完成”定 义的潜在可交付功能增量。

开发团队在每个 Sprint 交付产品功能增量。这个增量是可用的,所以产品负责人可以选择立即发布它。每个增量都附加于之前所有增量并经过充分测试，以此保证所有的增量都能工作。

随着 Scrum 团队的成熟,我们预期“完成”的定义会扩大,包含更严厉标准来保证高质量。

需要注意的是，如果在每个迭代，我们对“完成”的标准要求过低，那么这会导致在每个迭代，我们都会遗留一些完成外的工作，完成外的工作持续累计会增加项目的风险，有可能导致产品负责人决定发布的时候，产品却因为累积了过多的完成外的工作而无法发布，以致于我们还需要一个额外的Sprint来使它稳定。

17. SCRUM MASTER检查单

一位合格的ScrumMaster通常能够同时处理2到3个团队的事务。如果你愿意把你的角色限制在**组织会议，控制时间盒以及处理团队成员提出的障碍**的话，你可以将这个角色当作成兼职来对待。在这种情况下，团队仍然有可能达到预期的目标，而且有可能不会发生什么重大事故。但是如果你展望团队能够做到你之前无法想象的事情的时候，你就成为了一位出色的ScrumMaster。

一位出色的ScrumMaster一次能够负责一个团队。

我们推荐每个7人左右的团队都有一位专职的ScrumMaster，尤其是刚开始实施Scrum的时候。

如果你还没有发现你能够做的事情的话，尝试聆听Product Owner，团队还有团队以外的公司成员的想法。下面我列出了一些ScrumMaster常忽略的东西。

Product Owner干得怎么样？

• 你可以通过帮助Product Owner维护产品待办事列表和发布计划来提高他的效率。（需要注意的是只有Product Owner才能给待办事列表里面的项目排列优先级。）
• 产品待办事列表里面的项目已经根据Product Owner的最新想法排好优先级了吗？是不是所有来自股东的需求都已经被待办事列表中的项目涵盖了？要记得待办事列表是涌现的。
• 产品待办事列表的大小是否还能够维护呢？为了使列表更容易维护，应该将细粒度的项目放在靠前的位置，而把粗粒度的项目放在底部。但是要注意的是如果在分析需求上面花费过多的时间，效果只会适得其反，因为你的需求会在团队和客户/股东的持续谈话中发生变化。
• 需求（特别是在产品待办事列表最顶端的需求）能够以独立的、有价值的、可协商的、可估计的、可测试的小粒度用户展现出来吗？
• 你是否已经让你的Product Owner了解什么是技术债务以及如何避免吗？其中一个方法就是把自动化测试和重构这两项任务加入到每个待办事列表项目的完成的定义中。
• 待办事列表是不是能让所有股东都能够看懂？
• 如果你正在使用自动工具来管理你的待办事列表，想一下它真的能够帮助你吗？自动化的管理工具有可能成为ScrumMaster了解信息的障碍。
• 你能够通过有效地把信息打印出来然后传达给其他人吗？
• 你能够通过制订可视化图表来传达足够的信息吗？
• 你有曾经帮助过Product Owner整理待办事列表项目，然后分配到不同的版本中去吗？
• 是否所有人（包括股东和团队）都知道目前的团队速率是否能够赶上发布的计划呢？
• Product Owner有根据上次Sprint评审会议来调整发布计划吗？通常Product Owner应该至少在个Sprint之后调整发布计划，一般来说会把一些工作放到后面的版本中，原因是发现了一些更重要的工作要做。你可以在每个Sprint评审会议的时候给大家展示Mike Cohn的产品和版本燃尽图，这样就可以更早地发现当前的进度是不是能够符合预期。

团队做得怎么样？

• 团队成员是否在大多数时间里都能够进入“流”的状体？下面是这种状态的一些特征（摘录自Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi）：有清晰的目标（）；集中且专注，高度集中在某个特定的领域或事物上；失去自我意识，完全沉浸在动作和兴趣中；扭曲的时间感受，只能感受到主观世界的时间；直接和立即的反馈（无论是成功还是失败都能够马上感知到，以马上对行为进行调整）；在能力和挑战之间保持平衡；自我的控制能力；行为能够从本质上有所回报，所以感觉毫不费力。
• 团队成员之间相处得怎么样？气氛融洽吗？有为彼此的成功感到高兴吗？
• 团队成员之间会以高标准要求对方吗？会互相挑战来促进成长吗？
• 有没有一些事情团队会觉得不舒服而避免讨论的？（详见：Crucial Conversations: Tools for Talking When Stakes are High）或者引入专家来缓解不安的谈话情绪。
• 有没有试过以不同方式或者在不同地点举行Sprint回顾会议？详见：Agile Retrospectives: Making Good Teams Great (Esther Derby/Diana Larsen)
• 团队在开发过程中有没有集中在验收标准上？也许你应该在Sprint当中举行一次会议来评审当前Sprint所承诺的产品待办事列表项目的验收标准。
• Sprint待办事列表能够真正反映出团队正在做的事情吗？所有对Sprint的目标的打断和干扰都应该被视为障碍。
• 团队有保持更新任务版吗？
• 团队的任务版和燃尽图都能够很容易地被团队看见和使用吗？
• 团队成员都能够自己领取任务吗？
• 团队能够被保护得足够好而避免微管理吗？
• 用于解决技术债务的事项都能够在待办事列表里面反映出来吗？还是需要和Product Owner另外沟通呢？
• 团队成员会在团队的房间外忽略自己的职称吗？
• 是不是整个团队都将团队看作一个整体，对测试和编写文档共同担当责任呢？

工程实践进行得怎么样？

• 你们正在开发的系统有“开始测试”按钮能让每个都很容易地察觉到自己是否破坏了某些功能呢？通常这个是靠xUnit框架来实现的（JUnit，NUnit等等）。
• 你们能够在自动化端对端系统测试和自动化单元测试之间保持平衡吗？
• 团队在开发系统功能测试和单元测试的时候使用的是同一种语言吗（而不是使用团队里只有部分成员懂的脚本语言）？这个是可能的。
• 你的团队能够发现系统测试和单元测试之间的灰色地带吗？
• 你们的持续集成服务器能够在回归测试出现错误的一个小时（或者一分钟）内自动发出警报吗？
• 所有的测试都能够在CI服务器的测试结果报告中反映出来吗？
• 团队能够发现持续设计和无情的重构，而不是一开始就进行详细的设计带来的乐趣吗？重构拥有一个严格的定义：改变系统的内部结构而不改变其外部行为。重构需要在每个小时内进行多次，每当有重复代码，复杂的条件逻辑（通常表现为过量的缩进和冗长的方法），糟糕的命名，对象间的过度耦合，一个对象的职责过多等等问题出现的时候就需要进行重构。要在重构的时候有充足的信心，就要有足够的自动化测试覆盖率。测试覆盖率的漏洞和推迟的重构被称作技术债务。
• 在你的每个产品待办事列表项目的验收标准中都包含了完全自动化测试和代码重构这两项吗？如果不学习使用极限编程的工程实践，你就不可能在每个Sprint都能完成潜在可交付的产品（正如Kent Beck, Ron Jeffries等人所说的）。
• 团队成员多数时间都在结对编程吗？结对编程可以大幅度提高代码的可维护性，也可以大大降低bug出现的机率。但是有时候结对编程实在挑战大家的极限，有时候甚至会使完成任务的时间变长（如果我们更重视数量而不是质量的话）。所以，比较推荐的做法是和团队成员先讨论以选择在一周内大家愿意尝试使用结对编程的时间，而不是从一开始就强迫团队使用结对编程。然后慢慢地，部份人会开始喜欢结对编程的。

整个公司的做得怎么样？

• 团队之间有没有适当地交流合作呢？Scrum of Scrums是唯一的解决方案。也可以考虑在团队中选出代表参加别的团队的每日站会。
• ScrumMaster之间有互相交流吗？
• 来自公司内部的困难会在适当的时候被贴到开发总监的办公室的墙上吗？成本能够以金钱、丢失市场的份额、损失的质量或者损失的客户来量化吗？
• 你的公司的职业发展道路和你的团队的集体目标相符吗？如果以测试、自动化测试或者开发文档为代价来鼓励编程或者设计架构，那么答案就是否定的。
• 你能够帮助公司成为一个学习型企业吗？
• 你的公司已经被外界认定为最好的工作场所或者业界的领头羊了吗？

恐惧是你的朋友, 一旦你开始意识到你能够做些事情来改变现状，你可能会感到恐惧而退缩。然而，这正是你走上正轨的标志。

DevOps

https://www.zhihu.com/collection/715506319

测试

1. 黑盒测试/白盒测试

黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。

软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：

1、是否有不正确或遗漏的功能？

2、在接口上，输入是否能正确的接受？能否输出正确的结果？

3、是否有数据结构错误或外部信息（例如数据文件）访问错误？

4、性能上是否能够满足要求？

5、是否有初始化或终止性错误？

白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。

软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：

1、对程序模块的所有独立的执行路径至少测试一遍。

2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。

3、在循环的边界和运行的界限内执行循环体。

4、测试内部数据结构的有效性，等等。

以上事实说明，软件测试有一个致命的缺陷，即测试的不完全、不彻底性。由于任何程序只能进行少量（相对于穷举的巨大数量而言）的有限的测试，在未发现错误时，不能说明程序中没有错误