敏捷转型行动笔记：用户故事实践

用户故事实践作为敏捷转型推进过程中的关键一环，既对需求的管理和输出方式产生影响，也会对迭代方式和执行产生影响，对敏捷实践而言具有非常重要的作用，实践的效果也直接或间接地影响着敏捷实践的效果。

关于用户故事的定义，一般是这样描述：

用户故事（User
Story）是一段简单的功能描述，以用户或者使用者的角度，写下有价值的功能（Functionality／Feature）。与其说它是规格文件（Documentation），不如说它代表客户的一个需求而已。

用户故事描述了客户或用户如何使用产品，它从用户的角度进行表达。另外，用户故事特别有助于捕捉特定的功能，例如搜索产品或进行预订。

用户故事是描述对用户有价值的功能，好的用户故事应该包括角色、功能和商业价值三个要素。

用户故事通常的格式为：作为一个<角色>, 我想要<功能>, 以便于<商业价值>。

一个好的用户故事包括三个要素：
1.角色：谁要使用这个功能。
2.功能：需要完成什么样的功能。
3.价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：
英文：As a , I want to , so that .
中文：作为一个<角色>, 我想要<功能>, 以便于<商业价值>

想必不少人都知道用户故事的六个特征，即INVEST：

独立的（Independent）：我们要尽量避免故事间的相互依赖。在对故事排列优先级时，或者使用故事做计划时，故事间的相互依赖会导致工作量估算变得更加困难。通常我们可以通过两种方法来减少依赖性：1.将相互依赖的故事合并成一个大的、独立的故事；2.用一个不同的方式去分割故事。
可讨论的（Negotiable）：故事卡是功能的简短描述，细节将在客户团队和开发团队的讨论中产生。故事卡的作用是提醒开发人员和客户进行关于需求的对话，它并不是具体的需求本事。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
对用户或客户有价值的（Valuable）：用户故事应该很清晰地体现对用户或客户的价值，最好的做法是让客户编写故事。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
可估算的（Estimable）：开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：1.开发人员缺少领域知识；2.开发人员缺少技术知识；3.故事太大了。
小的（Small）：一个好的故事在工作量上要尽量小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
可测试的（Testable）：故事必须是可测试的。成功通过测试可以证明开发人员正确地实现了故事。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：用户必须觉得软件很好用。

因此，如何拆分用户故事也显得尤为重要。通常的方法有基于流程步骤的切分，基于业务操作、不同业务规则、简单/复杂、数据类型、工作量、体验质量等六种维度的切分，同时还需要考虑非功能需求-延迟优化等特殊情形。
在拆分用户故事的过程中，需要考虑优先级的确定，通常从经济价值、开发成本、获取新知识的重要性、故事之间的依赖关系、开发新功能所减少的风险等几个因素综合考虑。
此外，还需要掌握用户故事估算方法。

实际操作过程中，常用的方法可以采用规划扑克的方法进行估算。

除此之外，还有T恤尺码、点投票、水桶体系、三分法、找相似、排序方法等用户故事估算方法，具体可以根据不同团队的实际需要进行选择。