软件开发是一个从捕获客户需求到编码实现的过程。在我们传统的印象中,需求是厚厚的软件
规格说明书,实现则是无穷无尽的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在敏捷开发过程中的应用 在这本书中,Mike Cohn提供了一种如何编写User Stories以及如何在软件开发生命周期中运用它们的详尽蓝图。
对与敏捷开发技术,对于user story 的分析是很重要的
User Story Mapping
敏捷开发使用用户故事描述需求
A_good_example_of_user_story
vanessa-bdd-editor, 具有BDD风格的Epics和 UserStory Каталог 。githubинструкция"контрибьютору
为什么使用User Story? 什么是User Story? 好的User Story有哪些特点? User Story的生命周期是什么样的? 切分User Story的小技巧
后台管理模块 User Story.xlsx
user story在敏捷开发过程中的应用
人机交互+记事本设计+界面设计+需求设计+概念设计+userstory 逻辑设计 从User Story的描述得知用户期望的电子记事本是记事本、日历以及通讯录的综合,因此可以尝试将三者结合起来,通过超链接实现用户的需求。
对于敏捷开发来说,User Story是开发的基础,它不同于传统的瀑布式开发方式,而是把原本需求拆成最小粒度的Story,以方便拆分Task,估计开发时间,领取开发任务。1.Beingveryshort.Theyrepresentsmall ...
The concept of user stories has its roots as one of the main tenets of Extreme Programming. In simple terms, user stories represent an effective means of gathering requirements from the customer ...
用户故事介绍User Story的目标是设计和展示一个可扩展的后端基础设施,提供一个 Web 界面,允许用户以简单直观的方式请求新功能并提供反馈。 用户可以在他们的故事中附加文件来解释他们想要什么。 然后管理员可以...
用户建模方法的使用,不是很全^_^;但关键部分很明确,是很好的用户为中心的设计的指导材料
SRS -software requirement specification
用户的故事 ###我的第一个node.js项目一个基于堆栈的实时Web应用程序,允许用户创建故事并阅读它们。 用户使用jwt软件包模块注册/登录后,便会进行正确的身份验证。
user stories,mainly for agile development
involved in implementing a user story or resolving an issue. In this paper, we offer for the first time a comprehensive dataset for story points-based estimation that contains 23,313 issues from 16 ...
UserStory-FeatureTracker是一个Access数据库,用于通过易于使用的界面跟踪eXtreme Programming项目。 易于适应其他敏捷开发流程。 轨道:项目,迭代,故事/功能,问题和任务。