说明：从图上也可看到，这种情况下的用例，会是比较零散的，针对故事点，具体执行时，很多时候需要重复编写用例，即重复的时间投入。。。。
备注：
很早前我写过一篇关于精简测试用例的文章，后面看了下，发现好像执行性不高，删了，没分享出来。最近今天思考了下，发现用例还是可以精简的，精简用例的出发点是“用例主要是起提醒作用”，这个观点也是隔壁公司某项目负责人交流时，她提到的。当时没怎么在意，现在想来，发现还是挺有价值的一句话。结合上面的格式说明，用例名称，模块、故事名，验证点，一般是不能少的，那可不写的是啥？答案是：步骤、预期结果。当且仅当你一看用例名称，即测试验证点，就能想到步骤和结果时(比如翻页，密码大小写验证等)，那么可省略，因为这时候，用例名已经起到了足够的“提醒”，……
9、 开发自测
开发发布前，根据测试提供的用例进行简单自测，当然，开发自测环节的可能性是基于规范成熟度、工作任务量等因素的，一开始就让他们自测，估计会要了他们的命。
备注：开发如果有看下测试给的用例，哪怕是瞄下，说不定就看到没注意的细节了，，进而可将bug于测试前修复，要是再细看下就更好了……知道大致做到什么程度，才不会让测试抓住辫子，才算完成了开发工作，，，这里体现的就是敏捷的思想。
10、内网测试
QA进行内网测试，这些测试可能包括单元测试，接口测试等等，至于能做到哪种程度，就看各方面的配合了
11、外网发布与走查
12、下一轮迭代
重复流程3~11
难点说明：
结合实际，流程3~6 要怎么做？
方案要求：
1）可执行性高
2）效率高
3) 可维护性高
工欲善其事，必先利其器，根据方案要求，选择一款合适的工具、合作平台，就变得很重要了。
参考方案
方案1）
流程3、用Mindjet Mindmanager、XMind记录用户故事,举例如下
流程4、相关人员聚在一起讨论需求细节并记录结果
参考做法：
1）准备好一台电脑，一台投影仪，大家坐成一圈，看着投影仪逐条讨论故事细节
2）专人记录，讨论期间专人记录讨论的结果
说明：这里这里形式不固定，用笔记本，投影仪啥的，主要是考虑怎么样方便大家参与进来讨论，方便快速记录
流程5、将相同版本的需求打包在一起，安排优先级
到这里，差不多形成了一份简单的需求文档了，，好了，共享吧，电子文档就是方便，大家不用可以去记忆讨论结果，不用拿相机拍照，每人一份不是神话^^
流程6、开发人员进行评估工作量
这里是在讨论会上解决，也可以会后解决，看项目复杂度，难度等因素
备注：用excel会不会好点？待定
