《敏捷软件开发:用户故事实战》—1 概述
第I部分
开 始
在第I部分,我们首先介绍用户故事是什么,如何使用。接下来,我们将更详细地讨论如何编写用户故事,如何使用系统的用户类型来帮助识别故事,用户很难接触到时如何与那些充当用户角色的人一起工作,如何编写测试来验证故事已经成功实现。最后,给出用户故事编写指南。
完成这一部分的阅读之后,将掌握如何开始识别、编写和测试故事并准备好如何使用用户故事进行估算和计划(这是第II部分的内容)。
Ø 第1章 概述
Ø 第2章 编写故事
Ø 第3章 用户角色建模
Ø 第4章 收集故事
Ø 第5章 与用户代理合作
Ø 第6章 用户故事验收测试
Ø 第7章 好故事编写指南
第一章
概述
软件需求是一个沟通问题,需要新软件的人(使用或者要销售的人)必须与那些构建新软件的人进行沟通。为了取得成功,项目依赖于来自不同人群的信息:一方面是客户和用户,有时候是分析师、领域专家和其他从商业或者组织角度看待软件的人;另一方面是技术团队。
如果任何一方支配或主导了这些沟通,项目就会遭受损失。当业务方处于支配地位时,他们就会只关注实现的功能和日期,很少关注开发人员是否可以同时满足这两个目标,或者开发人员是否确切地知道什么是真实的需求;当开发人员支配了沟通时,技术术语就会取代业务语言,导致开发人员失去了通过倾听来了解什么是真实需求的机会。
我们需要的是一种协同工作的方式,这样双方都不占优势,因此将共同面对资源分配中的意气用事和政治问题。当资源分配问题完全落在一方时,项目就会失败。如果开发人员承担这个问题(通常是以“我不关心你怎么做,但必须在六月之前完成”的形式),他们可能会对其他特性进行质量交易,可能只部分实现一个特性,或者可能自行去做一些本该有客户和用户参与决策的决定。当客户和用户承担资源分配的负担时,我们通常会在项目开始时看到一系列冗长的讨论,其中的特性会逐渐从项目中移除。然后,当软件最终交付时,它的特性甚至还不及之前已识别的简化集。
到现在我们已经认识到,我们不能完美地预测一个软件开发项目。当用户看到软件的早期版本时,他们会提出新的想法,意见也会改变。由于软件的不确定性,大多数开发人员在估算事情需要花费的时间方面是众所周知的难事,由于这些和其他因素,我们不能制定一个完美的PERT(计划审查技术)[1]图表来显示项目上必须做的一切。
那么,我们该怎么办呢?
我们基于手头现有的信息来做决定,我们经常这样做。我们不是在项目的一开始就制定一个包罗万象的决定,而是在项目的整个过程中分散式决策。为了做到这一点,我们要确保我们有一个能够尽可能早、更频繁地获取信息的方法。用户故事由此产生。
什么是用户故事?
用户故事描述了对系统或软件的用户或者购买者都有价值的功能。用户故事由以下三个方面组成。
l 一份故事的书面描述,用于做计划和提示。
l 有关故事的对话,有助于充实故事的细节。
l 传递和记录故事细节的测试,用来判定故事是否完成。
由于用户故事通常用手写的纸质卡片来描述完成,荣恩(Ron Jeffries)用了3个首字母相同的单词来描述:卡片(Card)、对话(Conversation)和确认(Confirmation)[Jeffries 2001]。卡片可能是用户故事最可视化的表现形式,但它不是最重要的。瑞秋(Rachel Davies)在《敏捷教练》一书中表示,卡片“表现客户需求,而不是记录它们”。这是思考用户故事的最佳方式:尽管卡片可能包含故事的文本,但细节在对话中确认,并在确认后记录下来。
故事卡1.1是一个用户故事的例子,这是一个来自假想的BigMoneyJobs职位招聘和搜索网站的故事卡。
故事卡1.1 一个写在卡片上的用户故事雏形
为了保持一致性,这本书其余部分的示例都将取自BigMoneyJobs网站。其他关于BigMoneyJobs的例子可能包括下面几个。
l 用户可以搜索工作。
l 公司可以发布新的职位空缺。
l 用户可以限制查看到简历的人。
因为用户故事表达的功能应该对用户是有价值的,下面的例子对这个系统而言并不是一个好的用户故事。
l 该软件将用C++写。
l 该程序将通过连接池连接到数据库。
第一个例子对于BigMoneyJobs来说不是一个好的用户故事,因为它的用户不会关心使用哪种编程语言。但是,如果这是一个应用程序编程接口,那么作为系统的用户(她自己就是程序员)写的“该软件将用C++编写”是不错的。
在本例中,第二个故事也不是一个好的用户故事,因为这个系统的用户并不关心应用程序如何连接到数据库的技术细节。
也许你已经读过这些故事,并且在尖叫“但是等等——使用连接池是我系统中的一个需求!”如果是这样的话,请等一下,关键是要以能够体现客户价值的方式编写故事。有一些方法可以来表达这样的故事,我们会在第2章中看到这样的例子。
- 点赞
- 收藏
- 关注作者
评论(0)