UserStory本质

对Story到底是什么、Story与Use Case有什么区别，目前讨论的比较多，比较权威的解释有Mike Cohn在《User Stories Applied: For Agile Software Development》中提到的：

1、User stories are different from IEEE 830 software requirements specifications, use cases and interaction design scenarios.（User Stories与IEEE830中定义的软件需求规格、Use Case和交互设计场景都是不同的。）

2、User stories are similar to a use case scenario.（User Stories与Use Case场景很类似。）

3、user stories differ from use cases in their completeness and longevity. Use cases are much more complete than are user stories. Use cases are designed to be permanent artifacts of the development process; user stories are more transient and not intended to outlive the iteration in which they are developed.（User Stories与Use Cases在完整性和存在的长期性上是不同的。Use Cases更完整一些；Use Cases在开发过程中是长期存在的，而User Stories则只临时存在于一个迭代开发周期内。）

4、User stories and use cases are written for different purposes. Use cases are written so that developers and customers can discuss them and agree to them. User stories are written to facilitate release planning and to serve as reminders to fill in requirements details with conversations.（编写User Stories和Use Cases也有不同的目的。编写Use Cases用于开发人员与客户讨论需求并达成一致，而编写Use Stories则用来制订发布计划，并且有提醒讨论需求细节的作用。）



网络产品线刘宏业在《Story本质与划分9步法》中也持有类似的观点，并且认为“如果我们把各种敏捷实践成为一串珍珠的话，那Story方法就是穿起珍珠的那条线。”



通过上面的说明，对于Story的含义应该比较清楚了：Story的本意并非进行需求的分析和记录（当然可以做到），而是制订迭代开发计划；一个完整的Use Case（模块需求）对于编码来说还是很大的，用Story定义Use Case的各个场景，如正常流程和扩展流程最合适不过，一个Use Case可以分解为一个或多个Story在一次迭代或多次迭代中实现。下面剥香蕉的过程可以很好的比喻这种关系。