在敏捷实践体系中，迭代交付模式是敏捷开发的核心要素。

敏捷开发方法有很多，Scrum提供了迭代管理和持续改进的框架，如图1所示。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。

Scrum敏捷开发流程步骤

图1 Scrum敏捷开发流程

Scrum是一个包括了一系列的实践和预定义角色的过程骨架（是一种流程、计划、模式，用于有效率地开发软件）。

Scrum的最大特色是灵活和增量交付，要求团队之间有开放的沟通和协作。首先是由产品经理收集和整理需求，然后和开发团队确定开发列表，接着进入开发冲刺状态，后面就是日常开会、后期改善。在实际应用中，我们通常将其分为以下5个步骤。

步骤1：创建用户需求列表

一个产品的需求可能来自客户、团队或者产品经理的想法，这些需求的描述必须符合：作为，我希望，以完成__。这样的好处是让整个团队更容易理解需求，达成共识，图2 所示为一个实例。

图2 用户需求列表（产品功能需求）

步骤2：召开计划会议和制定开发计划（计划版）

Scrum Master负责组织召开计划会议，产品经理和团队一起根据需求的重要性、开发量来确定开发优先级，做工作量预估，制定迭代开发计划（从需求列表中挑选出高优先级 Story（用户需求）作为本次迭代完成的目标。

这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog（迭代代办事项））。

开发团队一旦接受这些开发任务，就应该准时完成，不得修改交付标准。

步骤3：执行迭代计划（任务板）

首先，你需要确定每次Sprint（开发冲刺）的周期，短的周期可以更频繁地发布产品版本，因此可以从客户那里更迅速地收到反馈，修正错误。

这个周期一般为1~4周。当然，你可以根据团队成熟程度或迭代任务确定一个合适的迭代周期，比如2周，这样可以让开发人员更投入地工作。

所谓Sprint，就是在一定时间内全身心投入开发。这个阶段通常用看板来管理需求，每个卡片就是一个开发任务，工作完成后，可以将卡片移到下一个阶段，用看板管理需求。

如图3 所示：你也可以使用专门的软件来管理看板，例如国外的Jira、国内的明道。

图3 敏捷开发项目管理看板

在冲刺中，每一天都会举行项目状况会议，被称为“每日站会”。会议在固定地点和每天的同一时间举行，对于迟到者团队常常会制定惩罚措施（例如罚款、做俯卧撑、在脖子上挂橡胶鸡玩具）。

不论团队规模大小，会议被限制在15分钟。所有出席者都应站立，每个人都必须发言。

会议的目标是讨论当前的任务的状态，一个推荐的汇报形式是：我昨天已经做了什么？我接下来准备做什么？现在遇到什么阻碍和问题？

注意在会议中团队成员不必要针对每个问题进行探讨，只是作为一个重要信息的反馈通道，具体问题相关成员在会后私下当面沟通解决，这样更加高效，避免浪费问题无关成员的时间。

步骤4：产品测试和演示

因为每次的Sprint目标就是交付一个可以用的产品特性，所以测试工作非常重要。

有不少方法可以减少测试周期，比如，你可以减少需求数量，或者让开发参与测试。

当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成。这时，我们要进行演示会议，也称为评审会议。

产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum团队的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）。

步骤5：回顾会议和下一个Sprint计划

每一个冲刺完成后，都会举行一次冲刺回顾会议。

回顾会议也称为总结会议，会议的时间限制在4小时，以轮流发言方式进行，每个人都要发言，哪里做得好、哪里不好都可以提出，总结并讨论改进的地方，放入下一轮Sprint计划。

Sprint冲刺会议

冲刺（Sprint）计划是Scrum中的事件。Sprint计划的目的是定义在Sprint中可以交付什么，以及如何实现该工作。

Sprint计划是由整个Scrum团队协作完成的。与体育界不同的是，Scrum鼓励总是全速前进，这样就可以在不断学习和改进的同时交付可用的软件。

在Scrum中，Sprint冲刺是完成所有工作的固定时间段，即一个迭代周期。在采取行动之前，必须设置冲刺时间，需要确定时间间隔将是多长时间，冲刺目标以及开始的位置。

冲刺计划会议通过设置议程和重点来开始冲刺。如果做得正确，它还将为团队创造动力，提供取得成功的环境。不良的冲刺计划可能会因设定不切实际的期望而使团队脱轨。

为了确保冲刺的顺利进行，在冲洗计划中要包含若干会议为冲刺过程提供支持，如图4 所示。

图4 冲刺计划包含会议

运行一个伟大的Sprint计划事件需要一些纪律。产品负责人必须做好准备，结合之前Sprint评审的经验教训、涉众的反馈以及他们对产品的愿景，从而为Sprint做好准备。

为了增加透明度，产品待办事项列表应该是最新的和细化的，以提供清晰的信息。

Backlog细分在Scrum中是一个可选的事件，因为有些Backlog不需要它。然而，对于大多数团队来说，最好是在Sprint计划之前让团队一起检查和细化Backlog。

输入Sprint计划的一个很好的起点是产品Backlog，因为它提供了一个“东西”的列表，这些“东西”可能是当前Sprint的一部分。团队还应该查看在增量中完成的现有工作，并查看容量。

输出Sprint计划会议最重要的结果是团队可以描述Sprint的目标，以及他们将如何开始朝着这个目标工作。这在Sprint Backlog中是可见的。

冲刺计划应该限制在每周冲刺不超过两小时。因此，例如，为期两周的Sprint计划会议将不会超过两个小时。这被称为“时间限制”，或者为团队完成一项任务设置最大时间量，在本例中是规划Sprint。

Scrum Master（敏捷教练）负责确保会议的时间安排被理解。如果团队在时间框内完成之前感到高兴，那么事件就结束了。时间框是允许的最大时间，没有最小时间限制。

在制定冲刺计划的过程中，很容易陷入“困境”，专注于哪个任务应该先做，谁应该做，以及需要多长时间。

对于复杂的工作，您在开始时所知道的信息水平可能很低，而且大部分信息都是基于假设的。Scrum是一个经验主义的过程，这意味着你不能预先计划，而是在实践中学习。

Sprint计划需要一定程度的评估。团队需要定义在Sprint中可以做什么，不可以做什么：估算工作量和团队能够承受的容量。

良好的评估需要一个基于信任的环境，在这个环境中，信息可以自由提供，并且在过程中讨论假设。如果评估中使用负面的，对抗性的方式完成工作,那么很有可能估算的工作量将很大，会造成不必要的资源浪费。

我们很容易陷入冲刺计划的细节，忘记冲刺计划的重点是为下一个冲刺建立一个“刚刚好”的计划。这个计划不应该成为团队背后的捣乱者，相反，它应该将团队的注意力集中在有价值的结果上，并为组织提供保护。

Scrum的一个关键原则是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。

同样，Scrum采用了经验方法——承认需求无法完全理解或定义，因此关注如何使得开发团队快速响应不断出现的需求。

Bocklog用户故事

Sprint目标在高层次上描述了Sprint的目标，但是也可以在编写Backlog用户故事条目时体现。

为了切身了解客户的需求，有些产品设计的市场和研发团队尝试运用基于客户情形，透过观察客户、叙说故事、编写剧本、再现客户情境和体验，从而沟通传达客户需求的剧本导引设计法，利用人类内心思考、言词表达的编故事、说故事的基本能力，将设计者及产品开发有关人员带入产品使用时的情境，透过这种情境故事，让设计者将与产品设计有关之信息自我内化吸收，转换对团队沟通。

用户故事是从客户的角度描述工作的一种很好的方式，如图5 所示。用户描述将缺陷、问题和改进重新集中于客户所寻求的结果，而不是所观察到的问题。通过向用户故事中添加清晰的、可度量的结果，你可以此评估什么时候能完成。

图5 用户故事示例

项目里不同的参与者有不同的需求，产品经理想跟踪进度，开发人员想实现，产品经理想功能，产品老大有更高的视角，而用户想要一个可用的系统，在这些充满冲突的视角中，想要做出一个人人都支持、皆大欢喜的决定，并且持续保持平衡是很困难的事情。

整个项目组就像一个四驱车，一个角色的强势就相当于一个轮子转得过快，这对产品都是损失，导致车子的方向偏移。

我们通过大家一起建立产品全景图的方式，让项目组所有人包括用户站在高空俯视产品，这种同一空间多点对多点的共识就自然地完成了。

我们通过这种一目了然、格式一致的故事地图，让项目组所有人都获得足够的信息，让项目有一个明朗的开发流程，如图6 所示。

用户故事地图作为一种有效的需求工具，可以做到多角色、多视角。

以合作沟通的方式来全面理解用户需求，涉及的主题包括怎么以故事地图的方式来讲用户需求，如何分解和优化需求。如果通过团队协同工作的方式来积极吸取经验教训，从中洞察用户的需求，开发真正有价值的、小而美的产品和服务。

图6 用户故事地图示例

用户故事地图是一个吸引用户参与设计他们所需产品的便捷手段。我们原型设计阶段的所有内容来源于用户故事地图，因为故事地图是用户全程参与的，所以在我们整个设计过程中都有用户的身影。

与参与性设计对立的是经验性设计。

在进行新产品设计时，经验性设计高度依赖前期的用户调研，包括用户访谈和用户观察，但是用户不会成为产品设计的真正参与者，后面的阶段基本是靠设计师经验，几乎没有用户身影。

但参与性设计“用户故事地图”通过简洁明了、场景还原的方式让用户参与其中，每个用户故事都做到站在用户的角度，使大家快速知道用户想要什么，为什么要这个。

用户故事易读、易懂，我们边聊故事的同时进行页面框架绘制，因此能激发用户的积极性，成为产品设计的参与者。

同时，随着用户渐渐掌握如何口头表达故事来描绘他们的需求，项目组成员与用户间的关系变得更加亲密主动，这种良性的循环使所有人员都获益良多。

思考：以往我们共识用户/产品需求的方式有两种，一种是文档，翻开一看，那些格式化的语言就变成了世界上最好的催眠曲。读尚且如此，写的人会怎么样？写文档的产品经理脑子里一定会回响一个问题：“这东西写了有人认真看么？”

有文档看还是好的，还有些产品经理会直接拉上团队成员聊，撰写用户故事地图，就算交接需求了，这两种方式你认为哪种更加敏捷有效？这里的共识是点对点的，或者单点对多点的，信息传递也会带来信息内容的损耗，甚至错误的信息。