用户故事——需求的占位符

要点

• 用户故事设置每个工件的边界范围。
• 敏捷的需求分析贯穿交付物的整个生命周期。
• 团队就接收标准、建议的解决方案和完成每个故事的工作量评估达成一致意见。
• 团队成员和他们的管理者必须为计划会预计的每个故事做准备。
• 你将在他们的计划会上对你的团队有更多的了解，得到的信息比曾经提供的所有报告的总和都多。

敏捷团队对业务分析负责，把用户故事详细阐述为需求就是成员们的工作

不管你遵循（或假装遵循）什么方法论，敏捷 Scrum、极限编程、统一过程还是瀑布法，缺乏需求对一个项目的伤害将永远大于其他任何单独的缺点。你只能不得不去检查文献看它是否真的贯穿了软件的开发过程。

用户故事是引用这些需求并排出优先级的一种简便方式，但你你不要让它们的双重目的误导了，你需要了解什么时候去详细描述以及要挖掘多深。太多则留给交付的时间就会不足，太少则无法做出可行的交付计划。

瀑布法是“业务分析师预先写个大需求”，而敏捷实践是准备“刚够”的需求且由整个团队负责，要完成这种转变是很难的。在敏捷中成功的秘诀是无情的范围管理。

计划会都是关于范围的

对于需求来说，Scrum 的迭代计划会（以及它的各种项目等价物）可是个关键时刻。这个会议实际上是一个交互边界，业务人员在此把高阶的需求移交给解决问题的团队。它是问题领域和解决方案领域的交叉点。

在会上，开发团队和产品负责人通过详细描述什么在范围内什么在范围外（紧接下个迭代的工作开始之前）形成交付契约。到计划会结束时，应该就不再有关于需求、解决方案或接收标准的隐藏假定和潜在的误解了。

我们看到许多敏捷团队的管理者投入时间去参加他们团队的计划会，他们的确应该这么做，但他们应该为这个会带来些什么呢？什么迹象能表明这是个有效的计划呢，又有什么表示接下来的迭代可能要做出让步呢？

大多数事情看起来都是一样的，召开一次高效的计划会也需要预先做大量的工作。针对这次会议做好准备以便产品负责人做出“放进来还是拿出去”的决定，这是每个团队成员的职责。为准备本次会议的团队提供支持是管理者的职责。

在最近的一次教练辅导中，我有幸和几支不同的 Scrum 团队、他们的管理者和执行发起人一起工作。所有人了解了 Scrum 的秘诀，所有人都乐于成为实践者。团队之间绩效发生了巨变，但几个因素也立即显现了出来。

• 在计划（和评审）会期间管理者的行为会对团队绩效产生直接影响。当管理者了解正在讨论的主题时，他们能够为讨论增加价值，团队因为他们的介入可以做得更好。
• 可以运用流程的机制、角色和职责把人、流程和约束组成一个别具一格的结合体，如果管理者和团队成员未对它们达成共识，那么结果会令所有人大失所望。
• 大多数成功的团队都拥有关注团队整体成功的管理者、产品负责人和 Scrum Masters。

一位高级管理者收到一个部署故事已经完成的通知时，大家就向一个团队演示的每个故事到底包含和不包含什么达成共识，并顺便询问这个故事是否已经包括所有事务的六种模式。了解到只部署了两种模式，因为计划会期间明确要求的就是这些，把庆祝的一个潜在原因变成了一个可预知的失败。这种经历使团队形成非常具体的故事范围。

业务分析角色

在《业务分析知识体系指南》 (BABOK®Guide) 中国际业务分析协会说“业务分析是负责引导干系人的实际需要……促进组织部门间的交流……使业务部门的需要和信息技术的交付能力达成一致，可以充当这些组织间的‘翻译’”。

在每个人理解需求重要性的同时，敏捷团队中的未冠名的角色有责任把它们写下来，在实践中，开发人员、测试人员、业务分析师、领域专家和项目经理必须使用任何可以完成业务分析这项工作的方法。

在敏捷中你应该何时进行需求分析？

团队成员经常问：“在 Scrum 中何时合适做需求分析呢？”这个问题的答案即无法令人满意也没什么帮助，因为它是“从你写下用户故事标题的那一刻起，一直到你按照团队当前的完成定义宣称这个故事’完成了’”。

编码明确界定了以冲刺为始以“完成”为终，与之相比需求分析的范围似乎有着难以置信的伸缩性，自分析师形成对业务的理解直至应用生命周期的终结。因此在每个故事的需求之旅中就接收标准达成共识具有非凡的意义。

界定不清的原因是和人交流时需求随时都能涌现出来。国际业务分析协作使用术语“引导”和“需求分析”去表达理解干系人的实际需要和逐步的细化、定义和验证解决方案。很显然，为了对问题及解决方案达成共识既需要与干系人（用户、消费者、产品负责人）花时间面对面交流，也需要与开发团队的其他角色面对面交流。所谓敏捷，就是按产品负责人排定的优先级“及时地”完成工作，他必须清楚待办列表中诸事项的相关业务价值。

因为敏捷需求是涌现出来的，那“开发团队需要在下个冲刺完成什么业务分析工作？”就是个好问题了，这个问题很有价值，因为它能保证分析工作投入到当前优先级最高的故事上，而业务价值不高和优先级较低的故事会保留在待办列表中。

所有特性都很重要，但一个团队一次只能交付一个特性，所以业务部门需要在特性 A 和特性 B 或工作流 X、Y 和 Z 中做出选择。很显然，为了识别 A、B、X、Y 和 Z 必须要提前做一些分析，迭代开发因此呈现出涌现的本质。

有个例子可以说明实际中的工作方式。

用户故事的生命周期

大多数故事都起自于特别宏大的构想，比如“变得敏捷”，但要在一个冲刺中达成这种“宏大的构想”太粗了，所以必须得把它分割或“分解”成较小的故事，包括：编写用户故事、按月交付、快速失败等等。这些较小的故事（只是在这里这么叫它）遵循了敏捷的本质，因为它们可以组织成可行动的、有优先次序的工作事项。这一点很重要。

把它们作为标题尽可能长时间地保留是完全可接受的，但因为待办事项顶端的故事即下次计划会的主题，所以最好随它们的地位上升添加细节。我们选一个把它写成以下格式吧：

作为 < 用户类型 >，我出于 < 某些原因 > 想要达成 < 某些目标 >。

故事是对功能的简单陈述，通常写成如下形式：

由于有人参与软件开发，我要写用户故事，以便每个人都清楚要完成什么

这种格式最初是由英国教练 Rachel Davies 提出的，后来由 Mike Cohn 在 Scrum 中推广流行，他还就此主题写了一本书。这种格式为：

• [主要参考者、用户角色或“人物角色”]
• 一个单独的 [参与者希望发生的行为或功能]
• 这个参考者做这件事的主要原因，或者预期的收益

大多数团队遵循了第一部分，但我发现有些人不愿意在“以便”部分增加原因。他们说那不重要，但这关系到业务的需要，它问答了“为什么我们出钱让你去开发这个功能？”这个问题。

按 Bill Wake 所说的，我们在写故事时应遵循 INVEST 的原则。每个故事都应该是：（I）独立的、（N）可协商的、（V）可评估的、（S）具体的和（T）可测试的。实际证明，INVEST 是极好的故事检查表，它与 the IEEE 针对（传统的）需求规格说明书所推荐的实践相得益彰，它们是 a）正确的、b）明确的、c）完整的、d）一致的、e）按重要性和 / 或稳定性排序的、f）可验证的、g）可修改的、h）可跟踪的。

按照 INVEST 的标准，上文中的故事还没有“足够好”，因为它即不具体也不可测试。另外它还很模糊，有待进一步解释。谁，精确点说是“每个人”吗？它包括同一屋檐下的所有人，还是仅指开发团队？亦或游离在开发团队之外仅仅关注预算目标进展的项目经理？

此外，如何度量“理解力”？

以及，“预期要完成”的精确定义是什么？

所以我们必须通过编写特定故事的接收标准对故事进行扩展，这么做能帮你找出大多数显而易见的问题的答案，即使我们没掌握所有答案必须得去请教其他人。

用接收标准详细阐述用户故事

通过编写接收标准，团队能够识别故事里的各种路径，类似于传统的流程图里记载的用例能展现各种不同的路径。第一个故事可能优先级最高，描述的是成功路径，有时被称为“愉快”路径。

接收标准的格式是：“（当……时就完成了）This Will Be Done When”，你可能更喜欢缩写成 TWBDW。回到上文中的故事：

因为有人共同参与软件开发，所以我要写用户故事，以便每个人都可以清楚理解预期要做的是什么

当……时就完成了 / TWBDW：

1. 组织内任何人想看这个用户故事都可以拿得到
2. 开发团队已经充分理解它了，能够预估为它开发解决方案所需的工作
3. 至少 10% 的需求写成用户故事
4. 所有团队有？？% 使用用户故事（这可能不是该需求的一部分，所以我们会问一下）
5. 只有团队内部的人才能增加或修改故事

你会发现第一对标准浅显易懂。它们会直接浮现到我的脑海里，写起来很容易，但随后我想到它的数量，猜测 10% 应该是“足够”了。它让我怀疑我们是否应该试图让其他团队也去用它，但有些事并不是我们所能决定的啊。最后，我意识到我们应该考虑编写的权利。

至今为止，这个工作都是一个人做的，通常是维度很单一。

如果在早期就向整个团队中提出故事，你将会发现会议很快就会变得冗长低效。很多根本问题会被提出来，其中有很多谁都回答不出来。试图和整个团队一起准备故事就是种浪费，结果也会让人大失所望，另外去找需要请教的人也不切实际，如果你发现自己陷入这种局面，最好承认还没准备好，转而去做下一个已经准备好的故事。

协作对于敏捷团队来说不可或缺

在任何团队计划会之前的上一步是与其他干系人交流，或许是产品负责人，或者是领域专家，又或者是团队中的其他成员。这在 Scrum 中称之为“待办列表梳理”，在业务分析中称之为“细化”。协作驱使人去分析和细化需求，考虑其他维度、标准和范围。两个人一起协作比一个人自己做能更好地集中注意力并输出更高质量的成果，这就是结对编程式的业务分析，我们现在很清楚协作是敏捷交付的使能器。

在与一个同事交流了几分钟之后，我加了两条新标准：

1. 团队中的每个人都应该接受用户故事培训
2. 培训不得超过两个小时
3. 编写一个用户故事不得超过 20 分钟

很好。看看其他人的思维方式有怎样的不同，我们一起协作是否更加有效？

在采用了这项技术的团队中，其中有一个更愿意把开发人员和分析人员结对以支持不同于团队成员的无职务名称的 Scrum 概念。另一个团队进一步尝试与来自不同的业务部分的人员结对，包括异地同事，只要条件允许。尽管他们各自的工作总比这种变革优先级要高，但这两个团队都很享受这样的经历。结对的另一个意外收获是有更多人参与到细化过程中，他们觉得对要准备的故事有了更高的话语权。我发现，当把故事在计划会上呈递给整个团队时，改一下提出者能为会议带来新的活力，并把压力从 Scrum Masters 的身上卸下来，他之前要呈递每个故事。

拥有一个妥善准备了的故事的冲刺计划会

我们清楚，当需求细化和编写接收标准时，两人脑力胜过一人，但故事是在计划会上向整个团队提出时会发生什么呢？

想象一下这个场景：这是个冲刺计划会，我们的故事几乎都是由请来负责设计和交付解决方案的团队分析和验证的。他们必须把这些需求消化吸收，协商和评估涉及的工作，接受或拒绝把这些故事放入下个冲刺。

冲刺计划是 Scrum 的保障机制。它驱走隐藏的假定并确保业务和开发团队间的交流。这个过程确保出资方拿出充足的时间与开发人员面对面交流。

我们知道每人团队成员都可以编写故事并呈递给团队，重要的紧随其后的交流。我们经常会遇到这样的局面：

“我们不需要新的方法，我们很开心使用用例文档”一位团队成员在听到用户故事的“故事”时说。

“我没有时间”另一个人说，看起来有些压力。

“在我曾经工作的地方，我们选了一个项目使用了敏捷，实际发现它非常容易操作”以一个人提出。

“一个故事应该有多大？”

“我们如何拆分故事？”

“我们还有必要写用例吗？”

“这些故事后续会怎样，它们将成为我们文档的一部分吗？”

我们遭遇过此类各种盘问，但这恰好是我们所希望的。团队拆分这些需求的过程，正是他们检验自己对其有效性理解的过程，正是他们试图使其贴合自己的知识和经验的过程；正是通过互相之间思想和感觉的碰撞来审视这个问题的过程。

他们适当地讨论实际上是该团队审视用户的需求。一旦完成，他们将理解用户想要什么以及为什么想要它们而不是其他。（好的，我的例子到此为止，因为团队才是故事的主题。这只是向你展示与一名团队成员一起作为主参与者写一个故事的问题！）

团队决定 4、6、7 点不属于核心故事的一部分，与其丢了它们不如将其拆分为新的故事。这使故事保持敏捷性，这样它们就可以以更精细的粒度提升或降低优先级了。在这种情况下，训练故事（6 和 7）应该首先发生，然后是主要故事。扩散到其他团队是个好主意，但可能需要很长的时间，或者永远不会发生。虽然它不会影响把它作为一个故事，但它将和其他低优先级的故事一起待在待办列表的底部。

退一步来看看现在定期会被贴满彩色便利贴的一面墙，团队的“用例先生”摘要表示他们已经设法把一个“简洁的用例”扩展为几个有优先级和范围的需求，即一些他预期自己最少一天或两天能完成的事，然后再把结果反馈给项目经理，使他在过程中更新和移动到下个阶段。这个新过程似乎是一种改进。

我们留他们参与会议的剩余部分时，很明显每个人都提出了将能马上开工的故事，他们什么都搞清楚了，对它展开了全面的讨论并理解了交付物的范围和衡量相应交付物各个方面是否成功的标准。

如何去“理解”计划会

如果你真的想要了解一个团队如何在做的，只需要观察他们的冲刺计划会并将你亲眼见到的和你认为这个过程应该怎么做进行一下对比。你不需要成为这方面的敏捷专家，只要成为对此感兴趣的人，并了解这个会是由增量的需求（可能会被称为故事）用例或产品第二轮列表驱动的。

基于对团队的观察，我开发了一些检查点以帮助管理者“理解”这个会。有些可能也适用于你的团队。

就故事细化而言：

- 故事已经分解为独立和有价值的故事了吗？

- 团队对潜在需求进行了什么程度的分析？

- 它们识别了任何外部依赖吗，如果有，计划把它们视为单独的故事处理还是视为障碍？

- 团队的分析披露额外的故事和接收标准了吗？对定义这个故事的范围有帮助吗？

- 针对故事的进展做计划的过程中，提议的解决方案对于每个人（包括你）来说“现实”吗？

- 当他们把解决方案分解成任务时，做的是这些看上去很容易中断的任务吗？

在故事评估方面：

- 每个人参与其中协作完成一个合理的评估吗？

- 他们是否就这些任务做了实际的时间评估，综合考虑了合理的冲刺比例、评估故事的价值？

- 每个人都清楚用于评估的单位吗？

关于团队互动

- 注意他人是如何看待年轻成员的。每个人充分理解需求对于全身心参与很重要吗？

- 团队准备的充分程度如何？他们的进展和最初的预期一致吗？

没有 Scrum 第一手和团队层的经验，管理者看计划时可能觉得帮团队做出向业务专家交付结果的正确决定和支持团队采用敏捷方法是不相干的。在很多情况下，为适应已有的管理、结构和运行情况而改变 Scrum 的规则（游戏）看似简单，但由于改了这些规则，就会丧失预期敏捷交付收益的权力。

结论

敏捷交付的关键在于通过故事管理的优先级。用户故事是需要浮现和扩展的需求的占位符。

成功的产品负责人及其团队会把范围限制到两或三个最高优先级的特性，这样会使团队对分析和预测更具信心，从而得到稳定的交付过程。从范围中移除的条目可以作为故事保留在待办列表中等待完成。

每个团队成员都要从事需求的收集和验证，以便他们参加计划会（或其他类似会议）时对需求有共同的理解，使彼此能够从一开始就完成有价值的工作，这将帮助团队达成一致的目标。

管理人员和领导做好使用敏捷价值和原则（有意或无意）的准备去支持他们的团队，可以预计将获得敏捷的绩效改进，包括可预测性和频繁的交付。

关于作者

Russ Lewis是一位敏捷专家和教练。他引导敏捷在高管、管理者和团队层的应用，帮助企业改进“组织级的敏捷性”。Russ 架构和领导了伦敦运输免接触车票交付系统，并将牡蛎卡推广到全国铁路，支持了 Amadeus SAS 的敏捷转型，在会议中发表了演讲并写了一篇博客。

查看英文原文： User Stories Are Placeholders for Requirements