User Stories Applied读书笔记（第四章）

Elicitation and Capture Should Be Illicit，需求并不像有些书本上描述的那样，本身就已经存在于某地，我们只需要简单的“捕获”这些需求，也就是说并不像我们之前预料的那样：用户其实明白所有的需求，可怜的项目组长或者开发人员只要想办法从用户口里“套”出来就ok了。
Robertson介绍了一种叫做“拖网”的模型来描述获得需求过程。这个暗喻从几个不同方面给我们启示。1）用不同网孔的网可以捕获不同尺寸的鱼，我们做需求分析的时候与此类似，先用大网孔的“网”捕获较大块的需求，然后再用小网孔的网铺货细节的部分；2）需求就像是鱼一样，也是有生命的，会成长，会死亡，伴随着一次次迭代的进行，有些一开始我们认为不重要的需求也许渐渐会变成我们需要解决的重要的需求，而有些一开始我们认为是重要的需求会慢慢的不再重要，或者，我们认为它已经死亡；3）就像你没法捕干净一个区域所有的鱼一样，你同样无法获得所有的需求，而且，就像捞鱼时会偶尔捞到一些无价值的垃圾一样，我们做需求分析的时候一样会收集到一些无用的部分；4）有经验的捕捞者知道在哪里可以捕获更多的鱼，有经验的需求分析师一样。

A Little Is Enough, or Is It?传统软件工程中对于需求，要求尽可能早的获得所有需求并且将需求文档化。敏捷方法中，我们知道没有一种网能够打捞起海中所有的鱼，而且我们没有足够的时间来完成所有的user stories，我们只能根据时间，在每次迭代中加入适当的user story。但是，虽然我们知道没办法识别出所有的user story，我们还是应该尽量多识别一些，哪怕很多story只是很抽象的描述几句。因为user story可以用不同的层次来描述，可以很抽象，也可以很具体，所以先用很抽象的描述来作为占位符，等到实际可以使用的时候，再将抽象的story进行细分，具体化。story识别的时候要知道适可而止，六个月的项目不要用三个月去识别user story，很多优先级不高的story只需要简单的描述。类似的，在启动一个项目之前，最好对项目的大小有一个大概的估计，以及项目大概会由多少个什么样的story构成。

四种重要的收集需求的手段：

• User interviews

• Questionnaires

• Observation

• Story-Writing workshops