理解用户故事的本质

2020-11-01 本文已影响0人 Bruce_Talk

我们为什么要使用用户故事来交流需求？你的用户故事写的对吗？为什么用户故事是三段式格式？今天想分享一下在传统研发团队向敏捷研发团队转型过程中，用户故事理解的不同视角，分享一下我理解的用户故事的本质是什么。

什么是用户故事

用户故事(User Story)是一种需求分析和交流的方法和方式，在软件开发领域应用很广泛。最早提出用户故事是在敏捷开发方法——极限编程(XP)中。由于它的高效和实用，现在甚至在传统瀑布方式的开发项目中也会应用用户故事来组织需求。

一般用户故事的表达方式是三段式：As a sb(Role), I want to do sth, so that I can achieve some needs.
用户故事对话采用3C方式：
1. Card: 每个用户故事要能够写到一张卡片上，不用太多，能够描述清楚就好。
2. Conversation: 拿着卡片，需求双方展开对话来彼此探讨用户需求。
3. Confirmation: 结合对话(Conversation)需求双方达成对用户需求的最终理解确认。
用户故事的描述符合INVEST原则:
1. Independent: 独立的。尽可能避免故事间的相互依赖。
2. Negotiable: 可讨论的。故事不是合同，它只是需求的简短描述，它的细节是客户和开发团队之间讨论产出的。
3. Valuable: 有价值的。用户故事是对用户来说有价值的功能，而不是对开发团队有价值的。
4. Estimable: 可估计的。能够进行评估的，开发人员具有相应的领域知识，开发人员也有相应的技术实现知识。
5. Small: 小的。故事足够小，开发可以将它安排到迭代中进行开发。
6. Testable: 可测试的。用户故事是能够被开发同时可以被测试来验证已经实现需求了的。

最近我在教练一个从传统向敏捷转型的团队，观察他们从传统的用户功能说明文档——Feature Specification(FS)到用户故事的思维转变过程。传统团队有如下的惯性思维：

害怕变化，需求要固定，越细节越好。
习惯了传统的FS形式需求文档。和用户在前期一次性商定完所有需求，任何后续改动都要进行合同谈判，走Change Request(CR)流程来单独收费，从而控制后期的需求改变。
将业务流程横向切分，分段完成。
每一个用户故事对用户都是有价值的一个实际需求，传统团队习惯将用户流程进行切分，因为传统的思维方式是将复杂问题分解之后进行局部优化，从而解决复杂问题。这种分解往往会切断业务流程的完整性。让开发团队在实现过程中失去需求的整体视角。
按照功能来谈论需求
传统研发团队习惯谈论功能实现，用功能描述来代替需求描述，甚至套用用户故事的三段式描述来描述功能。例如：作为系统管理员，我想要一个下载按钮，从而我就能实现下载功能。这个需求描述并没有表达用户的实际需求，而仅仅描述了实现功能到底是什么样的。

用户故事的本质是要将用户需求通过一种形式尽可能不失真的保留下来，并且方便进行传递，同时在传递过程中保持高保真。人类上千年的文明，很多知识的传递都是通过故事传递。足见的故事作为信息载体的强大能力。我们来看看用户故事的三段式如何对应需求元素(3W)的：

可以看出来针对特定用户画像的用户，我们更要关注的是Why的部分，因为这是用户的原始想法，而What是从用户的角度他认为能够实现Why的具体实现方式。而传统开发团队往往更加关注What部分，他们会把这部分映射为FS的需求描述。从而忽略了关键的Why。

用户故事是用来交流实际需求的，侧重和用户进行大量的对话、讨论。
用故事来讲解需求更方便记忆与交流，讲故事一直是人类千百年来传承和交流的重要手段。
用户故事是为了方便描述用户的需求，而不是开发团队更容易实现的功能。
转型过程中的团队要转变思维方式，相信客户是业务领域的专家，而团队是需求实现的专家。理解好客户需求后，最合理的实现方式是团队设计的而不是客户设计的。
【欢迎关注我的个人博客】