对用户故事的理解及其他

概述

这几年一直在思考敏捷开发中的用户故事，并尝试在工作中使用用户故事。

      发现不论敏捷开发还是瀑布式开发，很多东西都是相通的（或者说一样的）。在本文的后半部分我根据对用户故事的实践和理解列出一些内容。 你会发现，这些内容与《系统分析与设计方法 第7版 》第7章 使用用例建模系统需求 P179 中的表格几乎一模一样。

理解或原则

下笔前，先列明几个理解或原则：

1： 在开发一个系统的时候，业务的成果物是开发的基础。也就是开发人员是业务人员的客户， 需要提供符合开发人员的产品。

2： 业务人员和开发人员对问题达成一致的理解，是做出优秀产品的基础。

3： 业务阶段的成果物不可能是完美的，随着工作的展开，内容逐渐细化，需要业务人员和开发人员密切合作。开发人员不能要求业务人员1️⃣开始就能提供全面的或者完美的成果物。

4： 由此可知，开发人员与业务人员之间需要有方便的沟通 渠道。

用户故事的理解

站在一个开发者的角度，期望业务能提供如下内容：

1： 产品的远景/愿景是什么： 如何激励士气，让大家朝着一个方向前进。这也是判断业务的一个标准。

2： 当前版本的目标是什么：最好能给出支撑产前目标的业务树

3： 当前功能的价值是什么：

具体可分为：

3.1 用户角色是什么， 该角色有什么特点， 最好可以有一个角色画像。

3.2 为该类用户提供什么样的价值

4： 推荐的解决方案是什么： 注意，推荐的解决方案不一定是最终的选择方案

3，4加起来就是一个用户故事

5： 应用场景的描述： 给开发者一个感性的认识

6： 根据价值，用户列出验收（满意）条件：该段内容可以形成测试用例。

根据6就可以将业务和测试，开发串联起来了。

7： 该功能的依赖，假设与限制是什么

依赖是指前置条件，后置条件

思考：非正常流程有哪些，可以放置在什么地方

8： 开放性问题：

收集开放性问题，以便于再次沟通。

不要让开发者将不确定的问题误认为已确定。

9： 优先级及依据。

10： 联系人列表

10.1 业务的提出者

10.2 用户角色代表

10.3 建议的沟通对象

 

几个问题：

1： 上面所列的项目不需要全部提供。

2： 可以落实成文字，但是文字仅仅作为备忘录使用，不要过度依赖，特别是不要成为验收或追责的依据， 否则可能会导致参与者不乐意提供。