敏捷开发过程指导

这是我之前整理的一篇敏捷过程指导书，当时是给一家企业内部做敏捷分享之用，他们当时面临从传统瀑布开发模式向敏捷开发模式的转变。

1.概述

1.1敏捷简介

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的软件开发方法论，是一种软件开发的流程，它指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发。

敏捷开发以人为核心。我们知道瀑布开发模型是以文档为驱动的，在整个开发生命周期当中，要写大量的文档，开发人员根据文档进行开发，一切以文档为依据；敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，强调以人为核心。

Scrum可以理解为Agile Development的一个具体实践框架。运用此框架人们可以高效并创造性地交付最高价值的产品。

1.2 Scrum理论基础

Scrum以经验性过程控制理论（经验主义）做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。

Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum的三大支柱如下：

第一：透明性（Transparency）

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

第二：检验（Inspection）

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

第三：适应（Adaptation）

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

Scrum中通过三个活动进行检验和适应：每日例会检验Sprint目标的进展，做出调整，从而优化次日的工作价值；Sprint评审和计划会议检验发布目标的进展，做出调整，从而优化下一个Sprint的工作价值；Sprint回顾会议是用来回顾已经完成的Sprint，并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意，并且工作更快乐。

2.流程规范指导

2.1 Scrum关键字

Sprint(冲刺)：Sprint是指一个1周－4周的迭代，它是一个时间盒。Sprint的长度一旦确定，保持不变。Sprint的产出是“完成”的、可用的、潜在可发布的产品增量。

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

Product Burn-down Chart（燃尽图）: 显示了Sprint中累积剩余的工作量，它是一个反映工作量完成状况的趋势图。 图中Y轴代表的是剩余工作量，X轴代表的是Sprint的工作日。

Daily Scrum Meeting（每日scrum站会）: 每日 Scrum 站会是一个以 15 分钟为限的事件，它让开发团队同步开发活动，并为接下了的 24 小时制定计划。

Done（完成）: 指同时完成了两方面的工作。一方面用户故事的需求列表被完成；另外一方面针对需求故事的测试用例被测试通过。

Increment（增量）: 指当前冲刺中及以前所有冲刺中完成的用户故事总和，这些都是可以被执行的软件。

Sprint Backlog（冲刺代办事项）: 指一个冲刺中团队必须完成的用户故事列表。

Story Point(故事点)：故事点代表了开发用户故事所需要的全部工作量，它并不是时间，而是一个抽象的数字，通常我们用斐波那契数列(1、1、2、3、5、8..)来表示。团队估算故事点通常需要考虑：

1） 要开展的工作的数量

2） 工作的复杂度

3） 要开展的工作存在的任何风险或不确定性

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

Sprint Review Meeting（评审会议）: Sprint 评审会议用以检视所交付的产品增量并按需调整产品待办列表。在Sprint快结束时举行，评审会议中Scrum 团队和利益攸关者协同讨论在这次 Sprint 中所完成的 工作。

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

2.2 Scrum流程图

Scrum流程图详解步骤

项目启动阶段

Step 1. 项目立项评审。完成项目立项评审会议，需要确认项目的功能列表、项目开始结束日期、项目的实现团队、立项合同等。

项目需求阶段

Step 2. 需求分析设计。主要完成需求分析设计工作。产生用户需求说明书、概要设计文档（物理架构、逻辑架构以及采用技术等）、原形设计图、测试计划等。

Step 3. 整理输出项目(产品)待办列表。Product Owner 收集来自客户、市场、领导等渠道的信息，从业务角度和市场价值编制一份按优先级排序的、明确的、可度量的、合理的产品需求列表。需要注意的是，PO收集需求是一个持续的过程。待办列表也可以来自于评审会议的新的改进意见。

冲刺计划阶段

Step 4. 冲刺计划会议。Product Owner召集团队及Scrum Master甚至其他利益相关者召开冲刺计划会议。确定冲刺长度、冲刺目标和冲刺故事单并分解任务。

冲刺实现阶段

Step 5. 每日站立会议。每天规定时间、确定地点，开发队伍都要面对面的开一个最长15分钟的例会。每人回答三个问题：昨天做了什么，遇到什么问题，今天要做什么？

Step 6. 设计、开发、部署、测试。这是一个完整的实现冲刺故事的一系列开发测试任务，最终交付可运行的软件功能（增量交付）。

冲刺评审回顾阶段

Step 7. 冲刺评审会议。开发团队召开冲刺评审会议，邀请Product Owner、客户代表参加，由Product Owner来决定是否满足需求目标。一般会议控制在1小时以内，打开禅道故事列表，由团队成员一个故事一个故事的演示，PO决定pass与否。PO可以提出问题然后记录Product Backlog作为项目完善的需求。

Step 8. 冲刺回顾会议。Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会，产生改进意见或最佳实践列表。这份改进计划由Scrum Master记录并跟进实施在后续的冲刺当中。

重复Step 4~Step 8，直到所有列入本规划的故事清单都完成。

集成测试阶段

Step 9.系统集成测试。通常在项目最终交付用户做验收之前，需要做一轮系统集成测试，产生系统测试报告。

注意：step 3~ step 8是整个scrum开发流程的核心。

2.3 三个角色

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

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

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

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

Scrum角色之：产品负责人

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

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

· 清晰地表达产品待办事项列表条目

· 对产品待办事项列表中的条目进行排序,最好地实现目标和使命

· 确保开发团队所执行工作的价值

· 确保产品待办事项列表对所有人可见、透明、清晰,并且显示 Scrum 团队的下一步工作

· 确保开发团队对产品待办事项列表中的条目达到一定程度的理解

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

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

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

Scrum角色之：开发团队

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

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

· 他们是自组织的,没有人(即使是 Scrum Master 都不可以)告诉开发团队如何把产品待办事项列表变成潜在可发布的功能。

· 开发团队是跨职能的,团队作为一个整体拥有创造产品增量所需要的全部技能。

· Scrum 不认可开发团队成员的头衔,无论承担哪种工作他们都是开发者。此规则无一例外。

· 开发团队中的每个成员可以有特长和专注领域,但是责任归属于整个开发团队

· 开发团队不包含如测试或业务分析等负责特定领域的子团队。

Scrum角色之：Scrum Master

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

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

Scrum Master 服务于产品负责人

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

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

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

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

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

· 理解并实践敏捷

· 按需推动Scrum活动

Scrum Master 服务于开发团队

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

· 指导开发团队自组织和跨职能

· 教导并领导开发团队创造高价值的产品

· 移除开发团队进展过程中的障碍

· 按需推动Scrum活动

· 在Scrum还未完全被采纳和理解的组织环境下指导开发团队

Scrum Master服务于组织

Scrum Master以各种方式服务于组织,包括:

· 领导并指导组织采用Scrum

· 在组织范围内计划Scrum的实施

· 帮助员工及干系人理解并实施 Scrum 和经验性产品开发

· 发起能提升Scrum 团队生产力的变革

· 与其他Scrum Master一起工作,帮助组织更有效的应用Scrum

2.4 三个工件

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

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

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

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

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

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

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

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

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

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

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

工件二：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的目标，Scrum Master和team也许会觉得小的调整不会影响sprint的进度，但会给客户带来更多商业价值。

工件三：PRODUCT INCREMENT - 产品增量

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

2.5 四个会议

会议一：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 目标并开发出预期的产品增量。

会议二：每日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 回顾会议提供了一个专注于检视和适应的正式机会。

3.Scrum Master检查单

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

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

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

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

Product Owner干得怎么样？

· 你可以通过帮助Product Owner维护产品待办事列表和发布计划来提高他的效率。（需要注意的是只有Product Owner才能给待办事列表里面的项目排列优先级。）

· 产品待办事列表里面的项目已经根据Product Owner的最新想法排好优先级了吗？是不是所有来自股东的需求都已经被待办事列表中的项目涵盖了？要记得待办事列表是涌现的。

· 产品待办事列表的大小是否还能够维护呢？为了使列表更容易维护，应该将细粒度的项目放在靠前的位置，而把粗粒度的项目放在底部。但是要注意的是如果在分析需求上面花费过多的时间，效果只会适得其反，因为你的需求会在团队和客户/股东的持续谈话中发生变化。

· 需求（特别是在产品待办事列表最顶端的需求）能够以独立的、有价值的、可协商的、可估计的、可测试的小粒度用户展现出来吗？

· 你是否已经让你的Product Owner了解什么是技术债务以及如何避免吗？其中一个方法就是把自动化测试和重构这两项任务加入到每个待办事列表项目的完成的定义中。

· 待办事列表是不是能让所有股东都能够看懂？

· 如果你正在使用自动工具来管理你的待办事列表，想一下它真的能够帮助你吗？自动化的管理工具有可能成为Scrum Master了解信息的障碍。

· 你能够通过有效地把信息打印出来然后传达给其他人吗？

· 你能够通过制订可视化图表来传达足够的信息吗？

· 你有曾经帮助过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是唯一的解决方案。也可以考虑在团队中选出代表参加别的团队的每日站会。

· Scrum Master之间有互相交流吗？

· 来自公司内部的困难会在适当的时候被贴到开发总监的办公室的墙上吗？成本能够以金钱、丢失市场的份额、损失的质量或者损失的客户来量化吗？

· 你的公司的职业发展道路和你的团队的集体目标相符吗？如果以测试、自动化测试或者开发文档为代价来鼓励编程或者设计架构，那么答案就是否定的。

· 你能够帮助公司成为一个学习型企业吗？

· 你的公司已经被外界认定为最好的工作场所或者业界的领头羊了吗？

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

4.工具使用

· 项目协作管理平台工具。比如JIRA，禅道，阿里云效等。

· 燃尽图。

燃尽图是在项目完成之前，对需要完成的工作任务的一种可视化表示。它能形象地展示当前迭代中的剩余工作量和剩余工作时间的变化趋势，是反应项目进展的一个指示器。

燃尽图有一个Y轴（剩余工作量）和X轴（时间）。理想情况下，它应该是一个向下的曲线，随着日期的推进和剩余工作的完成而“烧尽”至零。 但是现实情况下，因为各种原因燃尽图往往会出现低谷或者高峰。

燃尽图规则：

（1）如果实际线在“参考线”下方，说明进展顺利

（2）如果实际线在“参考线”上方，说明任务延期

正常的燃尽图通常类似于下图：

注：实际线在参考线的上下波动且波动不大，属于正常现象

5.什么项目适用敏捷流程？

敏捷项目管理方法一般适用于中小型研发项目，追求项目管理态度、方式上的敏捷，推崇“以架构为中心，用例驱动，迭代开发”，从而达到快速交付的目的，PMBOK的理念是项目应该具备完备的可持续改进的项目计划，并时时强调项目管理计划的更新持续于项目整个生命周期。

1、产品复杂，不断有新的需求加入。

当产品的开发受市场影响较大时，业务需求的变动就十分常见了，为了不影响项目开发进度，需求管理必不可少。有些团队会一个个排需求、做需求，而敏捷开发是通过任务分解把工作拆分为半天到几天的工作量，然后制定里程碑时间点，将复杂的需求细化成一个个小任务，再根据轻重缓急梳理优先级，简单快捷地帮助开发人员化繁为简，提高效率。

2、团队庞大，沟通协作效率低。

有时一款新产品的开发，需要多部门联动协作，然而每个成员的岗位和职责不同，所以每个人关注的项目信息不一样，关注信息的频率其实也不一样，有的比较频繁，有的则可能整个项目过程就只需沟通两三次。由于每个人的习惯不同，所以他们获取信息的手段也不太一样，有些人喜欢微信、QQ，有些人喜欢邮件，还有些人喜欢以会议的形式获取信息。这就导致了团队内部沟通效率低下，许多重要的信息难以实时传递。

3、希望高效地管理开发进度。

产品经理为了掌握项目的进展，掌握各项工作的状况，就必须对项目过程进行监控和跟踪。只有这样，出现了问题，才能及时进行资源调整和进度计划调整，重新规划某一个任务开始和结束的时间，并记录实际的进度情况。

6.敏捷常见问题

· 看板任务状态忘记更新导致燃尽图不准确

· 站立会议没有准时参加

· 需求故事没有及时编写

· 任务估算与实际时间差距大

· 新故事插入当前的冲刺中

· 冲刺中测试任务没有及时跟进