软件开发是一个从捕获客户需求到编码实现的过程。在我们传统的印象中,需求是厚厚的软件 规格说明书,实现则是无穷无尽的bug产生器。需求是在实现之前写好的,客户签字确认的。实现是程序员拿着需求不断猜测这该怎么做,那该怎么做的重新发现 的过程。在需求与实现之间横亘着一个巨大的鸿沟,做需求的人和写代码的人总是互相推诿责任,到最后客户总是得不到自己想要的功能。
敏捷软件开发方法有一整套实践,来促进客户与开发团队之间的交流与反馈。而User Story则是这些实践中比较具有启发意义的一个主要实践,我认为它是承上启下的重要一环。因为在其上,它是具体用户角色完成具体目标的过程组成部分。而 在其下,它是编写验收标准(Acceptance Criteria)的具体上下文。它就像一条锁链一样,在需求与实现之间架起了一座危桥。
之所以称之为危桥,是因为一旦人们把User Story当做软件规格说明书一类的文档来看待的话,User Story很快就不能反映客户的需求,同时也无法指导实现的开发。我们必须要把它当做危桥一样来对待,经常去重新评估实现难度,根据给客户带来的价值排优 先级。当发现它所覆盖的内容不再准确或者过时了的时候,对于危桥我们就不用犹豫,该炸掉重来就炸掉重来。
不严格地说,敏捷开发从需求到实现的单向流程(反馈的路径未包括其中)大概是这样的:
这个过程没有暗示任何瀑布式的开发风格,其实这个过程是反复的,不断有反馈回顾。画出这么一个流程性的图只是为了表明User Story是如何承上启下的。
要知道它是如何承上启下,还是要知道它自身是什么样的。明确的答案是:User Story应该Small(小规模),Testable(可测试),Valuable(有价值)。
Valuable是说User Story能够给利益相关人员提供明确的商业价值。往往表现为满足了用户某方面的预期。
Testable是说User Story可以给验收标准提供明确的上下文。也就是说这个User Story能够对程序的外部行为产生影响,比如界面,日志文件等用户看得见摸得着的东西。
Small是说User Story应该足够小,在商业过程中也就一步或者相关联的几步。小的目的是更好地符合迭代式开发的风格,能够在一个迭代内完成。
这三个特性直接支撑了敏捷开发的一些核心价值:给客户提供价值(对应valuable),保证质量(对应testable)和快速响应变化(small)。
User Story与传统的Use Case有一些不同。某些Use Case的书籍中提倡写出不同层次的Use Case,有High Level的,有Medium Level的,也有Low Level的。从某种程度上来说,High Level相当于Goal,Medium Level相当于User Story,而Low Level相当于Acceptance Criteria。但是由于Use Case的写法缺乏统一的习惯和明确的指导。初学者在写Use Case的时候往往缺乏明确的目标,无法有效地把需求与实现贯穿起来。
因此,若把需求到实现看做从天空到湖底的话,User Story就恰好浮在水面上。可以说User Story是文档能够达到的最细节的层次,若在往下就陷入了实现的细节之中,与具体实现方式相关而且经常变动,维护起来非常困难。更重要的是,写出那样的 细节文档又不能执行,无法给客户带来价值,只是对代码的无味重复。
这里只是概览了User Story在整个开发过程中的位置和作用,以及其自身的的一些属性和它能提供的价值。具体使用User Story去实践敏捷开发可以参阅我同事李默所写的敏捷需求分析一文。他在文中以一个业务分析师的角度讲述了如何把User Story用在敏捷需求分析的过程中去。
User Story 概览—承上启下的重要一环
最新推荐文章于 2021-07-24 13:59:32 发布