关于用户故事这件事

用户故事以前也是在书上看到过.自己没有用过.
前几天帮忙设计一个网站.想好久都找不到合适的方法来表达需求.
于是虚构了一个人物,把这个人物在网站上的全部行为一步步的列了出来.也没有使用任何图表,纯粹的文字描述而已.
但是操作流程和网站所需要提供的功能出奇的清楚.用这种方法很自然的把前面忽略掉的内容全部都补上去了.(写故事之前,我已经先列出了网页,网站结构和功能表)
同时这个故事也提供了一个清晰的测试过程. 这些都是在编写用户故事之前没有想到的意外所得.
市场人员和其他非技术人员同样用这种方法来编写他们的所想的.

用户故事是提纲

用户故事体现用户和购买方的价值

用户故事不体现对开发人员有价值的功能

大用户故事epic可以包含小用户故事

用户故事三要素：故事描述、通过交谈丰富内容、验证测试确认故事已完成

对于需要特别注意的地方可以注明

客户团队包括测试员、产品经理、实际用户、交互设计员

客户团队使用业务语言来写用户故事，这样就能划分优先级规划迭代和发布了，另外客户团队是描绘产品前景的最佳视角

用户故事可以在项目的任何时间写,最初的故事可以从一次集体讨论中得到

通过协商，客户团队和开发人员确定迭代的长度，很可能是1到4周

在迭代结束，开发人员提交完全可用的部分产品

在迭代中，客户团队同开发人员交谈，确认开发人员确实理解了需求，同时客户团队还会指定测试，同开发人员协作运行测试，测试可以是自动运行的，另外客户团队需要确认开发是朝着待开发产品的方向前进的

迭代周期一旦确定开发人员就可以估计一个迭代能完成多少工作了

用户故事按照优先级，根据迭代分堆排列，在迭代开始时可以根据实际开发的速度调整这些分堆

一个发布由一到多个迭代构成

从下面几个方面考虑优先级
  大多数人涉及的特性
  少部分人涉及但很重要的特性
  故事之间的关联性

开发人员可以根据技术因素就用户故事优先级发表看法，客户团队聆听这些，但最终故事优先级还是以是否给目标组织带来最大化利益作为考量

故事在评估代价之前，不能划分优先级，所以对故事进行评估是划分优先级的要素之一，开发人员负责评估开发成本。每个故事使用故事点来量化，表明它的复杂性。故事点使用时间长度作为度量

开发人员声明自己的开发速度，一个迭代能完成多少个故事点，客户团队据此分配故事，累计的故事点，必须小于开发人员能够完成的故事点

尽可能早的找出验证测试，这样会对开发人员带来帮助

为什么要使用用户故事？
   用户故事强调口头上的交流，而不是文档化的
   客户团队和开发人员都能理解用户故事
   用户故事的大小适合于制定计划
   用户故事为迭代开发工作
   用户故事鼓励推迟细化，直到你完全理解你真实的需要（使用了 精益过程 推荐的工具）
   用户故事是在经常性的运行自动化验证测试后取得的，没有基于文档可能出现的二义性的问题

如果一个用户故事不能在一个迭代里完成，就需要把它分解

还有用户故事既然叫“用户故事”，那么它至少是用户能看得懂的故事。
也就是说对开发人员有用的故事，被排除在外。

你可能是将传统的需求分析套在用户故事上了。
实质上我认为用户故事编写过程中恐怕现场客户也要学点新名词，换句话说传统中的设计部分在用户故事中也有体现。

嗯，俺还没碰到过这样“好学习”的客户，会打探设计的咚咚。最多也只是带
有敬意的打听一下，不会像你说的这样强势。基本来说开发过程还是我们控制。
对于这种“畸形”的开发方式，确实很难保证用户故事里面没有设计。