需求的描述问题

软件开发中，程序员的工作一般由需求来定义。不同的需求描述方式，可能会对程序员理解需求产生影响。很多公司开发模式基于功能列表，这个列表里面的规定了产品功能，各开发组从产品经理那里领开发列表，然后“照单抓药”进行开发。但通常这个功能列表只是一些简单的描述，不能看到全局。

很多时候，程序员都只知道要开发的功能是什么，但这个功能是谁在什么样的场景下使用，却不清楚。因为这种功能列表的方式，是将一个完整的需求分割成诸多碎片，每个程序员只负责其中一部分功能，只见树木，不见森林。

还有一些新的需求描述方式，比如：用户故事（User Story）。它是站在用户角度来描述用户希望得到的功能，关注用户在系统中完成一个动作需要经过怎样的路径。以一个完成的场景来讲述功能。User Story包含以下部分：

• 标题

简要说明用户故事的主要内容

• 概述

简要描述用户故事的内容，格式如:As a (Role),I want to (Activity),so that(Business Value).

• 详述

详细描述用户故事的完整流程

• 验收标准

描述一个正常的使用流程，以及各种异常流程系统是如何给出响应的

你的角色

你可能会想，如果产品经理使用User Story将需求实现细节都描述的非常清晰明了，那程序员的发挥空间在哪里，验收标准中给出的实现细节应该是业务上的，程序员在这种问题上思考才是真正浪费时间，我们的发挥空间应该是在技术实现上。

实际工作中，你会发现功能开发会有很多“丢三落四”的问题。很重要的一个原因，在开发特性的时候，因为一些环节的缺失，我们不得不扮演很多角色，比如产品经理。有的公司可能没有专门的产品经理的职位，有的可能是其他角色兼任，如SE。有时你拿到的用户故事可能比较粗糙，这时你要分析需求，审视当前用户故事是否合理，是否修改补充。