关于用户故事这件事

看到这篇文章，突然想到了前几天的一个概念。

感觉‘用户故事’或‘场景’就像一个水灵灵的葡萄，而成文的usecase就像是葡萄干虽然保留了葡萄
最重要的内容，但毕竟不是葡萄。
如果一个没有见过葡萄的人只吃吃葡萄干就去做一个葡萄，估计做出的的葡萄会千奇百怪。葡萄干的存在也是有理由的，他比葡萄好保存，易运输。这是不是和usecase的作用差不多了：）。usecase是对需的一个分析和记录。但我们为了可操作性往往只记录最关键的东西，打开usecase我们常常看到的是一些死巴巴的业务流程。而如果是用户故事了就会好很多，因为既然是故事就会用渲染，
会用人物各个方面细致的描述，会用历史背景的描述总之详尽一切让你身临其晶。

各自用途：
1、个人感觉如果是团队内部做交流或是业务培训，最好还是由业务人员给大家讲讲故事的比较好。
当然这个时候不是说usecase就没有了作用，业务人员可以用usecase作为提纲以免有什么遗漏。

2、开发人员第一次了解业务也不要只看usecase，这样的效果是很不好的。文字性的东西虽然不容易遗漏什么，
但你读文章是单向的交流。如果因此产生的歧义, 那也就没有什么机制可以及时纠正了。
还是面对面的沟通交流吧！（我也最烦email来emai去，压根就没有什么工作效率。）

3、在开发过程中开发人员可以依据usecase来开发，但此时必须保证他的大脑中用一个故事场景，
能够根据usecase中的1234还原出一个活生生的需求来。

开发团队评估模块工作量，客户评估模块优先级。哪个业务比较重要，除了客户知道还有谁知道？
“突然要一切客户说的算了”……这个，我很无语。
另外，自称XP的项目“死得很惨”的我见了不少，不过在我看来大半就是因为这个“酌情修正”。