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

作者：Rick Freedman

翻译：Renee

3Cs

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

(图片来自网络)

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

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

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

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

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