PO和BA必读——《用户故事与敏捷方法》

《用户故事与敏捷方法》是一本关于敏捷开发方法内容的较早出版的书籍了。对于PO和业务分析师的新手，它是一本可以快速上手的读物。当然，此书出版之时，内容更多来自于企业应用开发，而非互联网产品。

这种技术的缺点是：它并不仅仅是一项个人技能，需要全团队都理解和支持才有可能实施。

实施结果的好坏，不取决于团队中的某个人，而取决于整个团队。

—— 乔梁，《持续交付 2.0》

以下为 慕樱sir @知乎《用户故事与敏捷方法》的读书笔记正文。

什么是用户故事

用户故事（User story）是作为产品的构想者（也就是用户），描述使用产品的场景。

它是一份书面的故事描述,可以用来做计划或者作为提示。开发人员可以根据用户故事开发软件的功能，一个故事对应一个功能。客户团队可以排列故事的优先级，放入迭代和发布。

用户故事是一个获取信息的过程，对开发软件起着积极高效的作用。

软件的需求通过沟通来体现，开发软件的人需要与使用软件的人交流，以获取信息。用户故事描述了对用户有价值的故事。从产品构想者的角度，描述使用产品的场景。可以用来做计划或者作为提示。开发人员可以根据用户故事开发软件的功能， 客户团队可以排列故事的优先级，将其放入迭代和发布。

每一个用户故事代表一个独立的功能，代表在一个单一环境中可能做的事，可以在迭代中逐步改进、完善、推敲细节。

用户故事的三要素（3C）

1- Card

卡片是用户故事最明显的表现，用传统的手写方式将用户故事写在卡片上，包含故事的文字描述，格式为：我作为（角色），想要（功能），以此实现（商业价值）。卡片背面可以书写完成用户故事的验收测试和完成标准。

格式为：Given<前置条件>…When<操作/数据>…Then<结果>...

2. 交谈-Conversation

需求的细节要在交流过程中获得，客户团队与软件开发团队之间的充分沟通交流可以确保双方对故事的理解准确。

3. 确认-Confirmation

用户的期望最好以验收测试的形式记录下来，通过验收测试确认用户故事被正确完成。

用户故事的编写准则

Independent—独立的：用户故事之间需要保持独立性便于更改，并且不影响整体。

Negotiable—可协商的：用户故事的内容需要可协商，更多的细节会在沟通中产出。

Valuable—有价值的：用户故事应该清晰地体现对用户和客户地价值。

Estimable—可评估的: 估算用户故事的大小，开发团队可以从而衡量工作量。

Small—小的：用户故事要简短，可以将复杂的故事拆分成小的故事。

Testable—可测试的: 故事必须是可测试的，通过测试可以证明开发人员正确实现了故事。

在编写故事前，识别用户角色有很多好处。为了避免从单一用户的角度编写所有故事，要识别与软件交互的不同角色。使用软件的用户有着不同的背景，并且持有不同的使用目标，我们可以将这些用户分组，把每一类作为一种用户角色（User Role），刻画一群人的特征与属性，以及这群人与系统之间可能的交互。学习用户角色、角色建模、角色映射和虚构任务，可以编写更好的故事，开发更好的软件。

• 角色建模的步骤->>

1. 头脑风暴列出初始用户角色集合：团队成员聚集在一起，在卡片上写下能够想到的所有的角色名称，直到没有新的进展。这一步骤可以帮助快速找到所有用户角色。

2. 整理最初的角色集合：移动卡片的位置，表明角色之间的关系，将相似的角色卡片归为一组或者直接重叠到一起。

3. 整合角色：在角色分组完成后，可以从重叠的卡片入手，试着整合并且浓缩角色。

4. 提炼角色：一旦整合好角色，对角色之间的关系有了基本的了解，就可以给每个角色定义一些特征来建立角色的模型。

• 如何搜集和整理用户故事

Robertson引入了拖网（Trawling）这个词描述收集需求的过程，指像用渔网一样搜集需求。开始时可以用粗网眼的渔网捕捞需求池，以得到所有的大需求，通过大需求形成软件的整体感觉。接下来用细网眼的渔网得到中等大小的需求。在这个比喻中，需求的大小可以代表商业价值的高低或者必要性的程度。

可以创建和收集故事的一些方法是：用户访谈、问卷调查、观察。

用户访谈是许多团队来获取故事的默认方法。问卷调查也是一种有效的方法，有助于搜集已有故事的相关信息。观察用户实际使用软件情况的方法可以直接的从用户处得到反馈，从而更早、更频繁地发布软件。

• 用户故事验收测试

在掌握了创建用户故事的方法和编写方式后，如何将用户故事转变为实际可以使用的功能，那么就可以通过用户验收测试来为用户故事丰富更多的细节，同时让程序员目的更清晰的编写代码。

写测试用例要在写代码之前开始。为了让程序员尽早了解信息，测试用例应该在编写代码前开始制定。客户和开发人员讨论的许多细节可以通过验收测试用例记录下来，同时充实很多用户故事的细节。

测试的两步流程：

这些验收测试用例的流程用来确保故事可以被正确、完整的实现。

验收测试用例提供了确认故事是否被完整实现的基本标准。

有了这样的标准可以避免花太多或者太少的时间精力。在每轮迭代结束时都应该执行验收测试，测试也分为项目需要的所有不同类型，故事测试主要是功能性测试，其他类型的测试也应该考虑：

• 用户交互测试，确保所有用户交互组件如期工作

• 可用性测试，确保程序好用

• 性能测试，测量应用程序在负荷下的工作情况

• 集成测试，测试模块间的接口，同时测试一些主要业务的功能

用户故事的实践应用

对用户故事有了大体的理解后，接下来我们来对用户故事进行实际应用，我们可以通过用户故事来对软件的开发项目进行估算和计划。

• 估算与计划

开发计划的创建和发布通常需要以下步骤>>

1. 一、确定迭代的长度

a. 估算用户故事

用户故事的大小和价值可以通过故事点（story point）来衡量，故事点是故事复杂度、工作量或工期的相对估算。团队可以定义一个故事点为一个理想日的工作，也可以将一个故事点定义为一个理想周的工作。

b. 上线/发布的时间

大部分的软件项目的开发周期为2-6个月，我们可以通过两个问题来启动发布计划。

• 想在什么时候发布？

• 故事的优先级是什么?

理想情况下，开发人员可以和客户谈一个日期范围，而不是具体的日期。为了计划一个发布，客户需要排列故事的优先级，把故事分为高、中、低这三类优先级类型是很有用的。

二、排列用户故事的优先级

价值是衡量用户故事优先级最重要的标准，也就是故事对客户的重要性。DSDM（敏捷开发模型中的一种Dynamic Systems Development Method）中排列优先级的方法——MoSCow，必须有（Must have），应该有（Should have）可以有（Could have）、这次不会有（Won't have this time）。

必须有的功能指系统的基本功能，应该有的功能指重要，但短期内有替代解决方法的功能。可以有的功能指如果没时间就可以在发布中不予考虑的功能。列为“不会有的功能”指客户期望拥有，需要在后续发布中实现的功能。

我们还可以通过其他的维度来为故事排列优先级，可参考的要素如下：

• 从故事点到预计工期

• 根据成本安排优先级

• 根据架构需要安排优先级

（混合优先级，在确定故事优先级时遇到问题，可能需要分割故事，对独立的故事排列不同的优先级）

三. 迭代计划

迭代计划会议的内容如下：

• 讨论故事

• 从故事中分解出任务

• 开发人员承担每个任务中的职责

• 讨论所有故事，并且接受所有任务后，开发人员单独估计他们承担的任务

迭代计划是发布计划的进一步计划，在迭代计划中，团队讨论故事，客户负责对迭代中包含的故事排列优先级，然后开发人员从故事中分解任务，估算及确认任务大小，并承担所有故事的任务。直到最后交付任务，提供他们创造出的最大商业价值。

a. 迭代的长度

开发团队和客户会共同选择适合项目的迭代长度，通常为1-4周。在项目开发期间，尽可能坚持固定的迭代长度，这有利于团队保持固定的节奏和开发速度。

假设项目有100个故事点，若估算的速率是每轮20个故事点，那么则预计需要5轮迭代。客户和开发团队协作选择20个优先级最高的故事点，把他们放入第一轮迭代。再将次高优先级的20个故事点放入第二轮迭代，如此直到分配完所有的故事。

b. 迭代的速率

在一轮迭代中所完成的故事点就是项目的速率。为项目做计划时，可以用已知的速率，也可以设想一个速率。速率是一个有效的管理工具，在每轮迭代结束和迭代中采取一定的方式监控和保证团队合理的速率很重要。

可以通过以下三种方法获得速率：

①使用历史值

②执行一轮初始迭代，并使用该轮迭代的速率

③猜测

使用历史速率是一个很好的选择，但只适用于在团队刚做过类似项目的情况下。当团队进行过几轮迭代后，对于项目开发的工期会获得更多经验，为每轮迭代计划和实际完成的故事点画图是检测实际和计划速率的好方法。

接下来，我们来继续探讨如何在在Scrum中使用用户故事

用户故事和Scrum

团队需要逐步地完善整个系统，不断地给软件添加更多的细节，软件的功能也由此越来越完备。Scrum是敏捷方法中一种迭代递增的软件过程，实施scrum过程的项目往往采用30天为周期的迭代，称为Sprint，团队确认这个Sprint需要完成的工作，将所有任务放到成为产品Backlog的列表中，团队根据自己的经验从产品Backlog中选择下一个Sprint能够完成的任务，放到另外一个Sprint Backlog的列表中。团队每天都会有一个简单的站会称为Daily Scrum审查团队的进度，并根据需要做出调整。

• Scrum团队

一个Scrum团队通常由4~7个成员组成，Product Owner产品负责人和Scrum Master,以及Development Team开发团队

• 产品Backlog

产品Backlog是指所有待开发产品功能的列表，在项目初期不需要写出所有的功能，通常产品负责人和团队写下一些相对显而易见的功能，随着开发的不断进行，不断对产品Backlog进行调整和扩充。产品负责人负责按照优先级对产品Backlog中的条目进行排序

• Sprint计划会议

每个Sprint的开始是Sprint计划会议,团队和产品负责人一起确定整体的Sprint目标,产品负责人为产品Backlog排列优先级,团队一起决定一轮迭代完成多少故事

• Sprint评审会议

在Sprint结束时,会有一个评审会议上,团队展示在Sprint中完成的工作,大家一起评估是否达到了在计划会议上设定的目标.

• 每日Scrum简会

在每日Scrum简会中,成员需要回答三个问题: 我昨天完成了什么? 今天要做什么? 碰到了哪些问题? 成员每天能够了解项目进展,重视任务分配的情况。

用户故事的优势与不足

在了解用户故事在项目中的实施和运用之后，我们来总结一下用户故事的优势和一些存在的不良的症状：

用户故事的优势

• 用户故事容易理解

• 用户故事的大小适合做计划

• 用户故事适合于迭代开发

• 用户故事鼓励延迟细节

• 用户故事支持随机应变的开发

• 用户故事鼓励参与性设计

用户故事鼓励参与性设计，用户成为软件设计的参与者，做出有价值的贡献。用户故事促使我们重视口头交流，与依赖书面文档的需求方法不同，认为交谈有更重大的意义。

用户故事的不良症状

• 故事太小，用户故事经常需要调整和估算

• 故事之间相互依赖

• 故事中包含太多的细节

• 客户难以为故事安排优先级

总结

用户故事为软件开发的过程提供了思路，通过不断增加信息以及细节来完善软件的功能。用户故事与敏捷方法的结合，用相对更短的时间、更高效的方式完成软件开发的流程。

用户故事中高效的沟通使客户和团队成员都朝同一个方向前进，并且以更快的速度，更少的消耗来应对快速变化的需求。

作者Mike Cohn在软件开发积累的丰富经验使本书充满实用的建议，希望读者们可以运用敏捷的优势，通过用户故事向客户持续的输出商业价值。