系统故事 --- 让系统讲故事

  用户故事自最早1998年诞生以来,由于其突出的优点,到现在得到了广泛的应用。一般而言,用户故事里面的用户是人类用户,用户故事在表达人类用户与系统的交互方面已经证明了其有效性。

  那么当处理系统之间交互时,我们能不能参照用户故事来说明系统交互的需求? 让系统来讲讲故事?
这样的故事不妨称之为系统故事。
微博上有朋友形象的说这是瓦力和伊娃之间的故事。

在另外一篇文章中已经分析了用户故事的新扩展,见此链接,答案是肯定的。本文具体来说明系统故事。

  下面是按照故事经典句型给出的2个例子。
* 作为ATM系统,我要发送客户卡号给银行中央系统,这样可以获得客户的余额。
* 作为ATM系统,我要把客户取款成功的信息送给银行中央系统,这样可以记账

什么情况下需要识别系统故事?

  最典型的情况是两个系统分属不同部门或者团队在开发维护。采用故事的表达方式有利于跨部门或者团队来快速沟通。

  另外的情况是不同组件(或者叫子系统)之间的交互。利用系统故事来更清晰的说明,某种程度而言,这算属于设计的范畴。当然,这是为了让编程者更快的工作,属于什么范畴并不重要。

谁来识别系统故事?

   对于用户故事,一般是PO或者PO的助手来识别用户故事。而对于系统故事,也是相同道理,对于担当中间系统的PO来说,可以假设PO是知道系统之间业务意义上的交互的,了解系统交互是应当的。 当然了解系统交互的其他工程师同样可以担当系统故事的识别。而如果系统多数交互是与人类用户交互,而只有少数是与后台系统交互,那么PO可能并不了解与后台的交互,那么应当有其他了解后台交互的工程师来协助。

如何识别系统故事?

  从系统交互中识别系统故事,提议将有业务意义的最少交互可以识别为一个系统故事。
比如:
* 两个系统的时钟同步只是技术意义上的交互,不是系统故事
* 但凡传递业务信息,那么属于系统故事,比如ATM机向银行中央系统提交银行卡卡号和密码来签权

在这么多表示系统交互的图形中,推荐使用泳道图来绘制交互,在穿越泳道的地方来识别系统故事。

试图利用Wiki的表格来绘制泳道图,由于无法绘制箭头,活动顺序是在表格中从左到右,再从上到下。
分析对象是ATM机,大场景是取款。

储户ATM银行中央系统银联系统
插卡登录登录储户卡校验用户身份,如果非本行用户,提交银联校验校验用户身份
显示登录成功欢迎页
取款核对储户余额[[查询用户余额]],如果非本行用户,提交银联校验用户余额
吐钱
获得现钞校验取款结果记账,非本行用户,提交银联记账记账

银联系统放在上表中只为扩充理解。

系统故事有哪些好处?

  • 以故事形态进入的Backlog,与其它形态故事放在一起,可视化效果好
  • 容易让编程者理解,方便配套验收条件和自动化测试
  • 以故事的方式来进行接口设计,帮助进行架构演进

系统故事识别的优先级?

   如果能够识别覆盖系统故事的用户故事,并且该用户故事也方便进入迭代处理,那么优先识别用户故事,不必识别系统故事。
   虽然站在编程者角度的赋能故事(enabler story)也能表达系统故事的内容,但是系统故事的识别优先级高于赋能故事,因为系统故事对比赋能故事有更好的表现力,系统故事本身着眼于描述系统行为。
在用户故事、系统故事和赋能故事中,赋能故事的识别优先级最低,因为赋能故事描述的是赋能者(包括编程者、测试者)的行为,灵活多变,并不是描述系统的行为。

而一旦识别了系统故事,那么实现系统故事的编程者行为就不必再识别为赋能故事。

这与用户故事是一样的道理,没有必要把实现用户故事的行为作为赋能故事另外再识别出来。

如何描述系统故事?

   如同用户故事一样,采用讲故事的方式来描述系统故事。 如下推荐一种参考自用例规约的写法。
  首先给系统故事起标题,由于考虑到直观显示到看板,因此要尽量缩短标题,又能保持意思。
  其次概述这个故事,推荐采用故事描述经典句型:作为XX角色,我要做XXXXX,这样可以XXXXXX
  故事主体采用情景描述方法,先描述成功情景,也有基本流、主成功场景等另外的说法,再补充描述异常/失败情景,也有异常流、扩展场景等另外的说法。
  最后说明验收条件,设定类内容可以写在验收条件里面。由于以上的情景描述本身就是验收要点,因此有时候验收条件可以不用写。 比如如下例子中的条件如果已经写在了总体验收条件中,那么没有必要在故事内再重复说明。

如果有必要可以添加其它说明。

如下是示例:

标题:ATM查询客户人民币余额
概述:作为ATM系统,我要发送客户卡号给银行中央系统,这样可以获得客户的人民币余额。
成功情景:
1. ATM发送客户卡号到银行中央系统
2. 银行中央系统返回该卡的人民币余额

异常情景:
* 2a 无法链接到银行中央系统
* 2b 该卡不在可处理范围之内
* 2c 该卡已经被冻结
* 2d 该卡余额超出可处理范围

验收条件:
1. 响应时间小于10秒
2. 银行卡可处理范围是中国银联支持的银行卡
3. ATM可处理余额最大范围是99999999元

为系统故事添加测试

  根据系统故事的描述,配套编写相应的自动化测试。成功情景与异常情景几乎与测试用例等价类划分直接对应,从中设计测试用例相对容易。

小结

  • 采用讲故事的方式来说明系统之间交互是完全可行的,而且容易让编程者理解,而且也能更好的关联到需求和业务。
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页