用户故事:敏捷开发的起点

翻译
2017-03-17 10:53:59
滕菲
3863
来源:

作者:Rick Freedman

翻译:Renee


3Cs

想象一下这样一个用户故事,“作为一名求职者,我可以找工作。”大多数的开发人员都会认为这种描述太笼统了,无法在这个基础上进行系统搭建。 敏捷开发宣言的署名者之一Ron Jeffries在 极限编程关键:卡片(Card)、对话(Conversation)和确认(Confirmation)一文中提出了一个很好的用户故事描述说明指导。

Image result for 3c of user stories

(图片来自网络)


简单描述一个用户的功能性需求(例如:“作为一名求职者,我可以找工作”)可以用一张索引卡片(Card)表述出来,这张卡片并不是需求描述;还需要对话(Conversation)和确认(Confirmation)是描述变得完整。在敏捷方法中,开发人员和用户的互动至关重要。用途描述是需求对话的开始,而不是结束。没有描述,记录在卡片上的句子就毫无意义。


使用敏捷方法是为了避免传统开发方法中的错误和陷阱,其中最臭名昭著的一个陷阱就是“随意丢给你”的需求。这种需求临时交给开发团队,强制他们“去开发这个”。敏捷开发人员认为,成功的开发工作最重要的一个因素就是用户与其合作,这种合作最好是就系统的外观、体验和功能与开发人员持续的不断地对话、交流。正是在这种持续的交流中,更多的细节(譬如,“一个求职者可以以自己的特长来找工作”或“一个求职者可以以游客的身份登录,也可注册成为会员”),才会被涉及,一个可行的系统才能被创造出来。


通过不断增加细节,开发团队和用户可以决定哪些细节是原始需求的详尽阐述,哪些细节可能需要单独作为一个需求来写。例如,会员制是一个终端产品的关键要素(如用户在网站哪里可以付款进入职位发布),会员故事有更多的细节描述,可能需要作为一个单独的需求,有自己的一些列的开篇、对话和确认。对话产生的细节通常可以以文档记录下来。


确认这一环节说明用户是那些定义如何测试系统功能的人。实际操作中,顾客协同确认环节也是很多细节被商榷的环节。如果项目内容是建一个会员制的网站,在这个网站上,求职者可以付费获得浏览表单的权限。那么有个显而易见的问题,那就是会员怎么付费呢?这个问题就要考虑测试可以接受哪些信用卡付款,贝宝、支票、借记卡或其它会员可能会使用的转账方式。


和客户不断的对话可以引导客户细化他们的需求,这是敏捷开发的艺术所在。敏捷开发是为了 避免开发中先前出现错误,其中一个错误就是程序员创造的测试。开发人员通常会指定系统通过的测试,这只是为了检测系统会不会在使用中崩溃。这并不是因为开发人员想要和系统玩个游戏。这样做是因为程序员要测试其编写的功能,而这些功能可能和用户预期的用例并不符合。

发表评论
评论通过审核后显示。