(1)--在人机交互中找到价值流

昨天中午的BA交流讨论会上，小裴讲了一下在某项目收集需求，捕捉用户故事（Story）的过程，很是值得深思。其关键在于INVEST原则中的V（Valuable）。该项目是一个有很多分析图表的改造项目，需要保持当前的数据，并修改或增加一些图表。例如：

那么，对于这类分析图表如何写用户故事（Story）呢？

最初，是根据图表的区域来划分用户故事（Story）。即左边的折线图是第一个Story，右边的表格是第二个Story，而下边的文本框是第三个Story。看起来还不错，但当与开发人员讨论并估算工作量时出了状况。开发人员问了很多问题，而这些问题的根源在于“这三个Story的价值在哪里”。的确，这三个Story放在Story列表里似乎互不相干啦，而事实却恰恰相反，三个Story是数据紧耦合的。

通过分析这个报表，最后发现，用户是按照一定的顺序来浏览这个图表的，而且会根据图表上的数据不同，而做出不同的选择。也就是说，这个顺序和不同的选择实际上就是该功能的价值流（业务流或数据流）。

最终，这个图表被抽取成大约10个Story，并可以清晰地看出业务数据流向。

(2)--story&process/Themes mapping

在Cruise项目使用了Story&Process/Themes Mapping的方法来检查Story list是否有遗漏。操作起来也非常简单。其步骤是：

一、将所有 业务流程画在一个大白板上；（画不下的话，找更大、或更多的白板。自己想办法吧）

二、将所有的Themes分栏放在桌面上。

三、将所有 的Story打印在小卡片上（两份）。

四、根据业务流程的相关性，将小卡片贴在相应的区域中。

五、根据Themes的相关性，将小卡片放在桌面相应的Theme中。

六、概观白板上小卡片的分布情况，以及桌面上每个Theme中卡片的数量。

七、通过对比，并问如下类似问题：

• 为什么这个区域或Theme中的卡片少，而其它区域却很多？
• 是否有遗忘的？
• 流程图中的某个连线上没有卡片，是为什么呢？
• ……

如果团队认为这种分布是合理的，那么可能就差不多啦。:D