04.用户故事与敏捷方法--搜集故事笔记

00.用户并不知道所有的需求，所以不能单纯依靠引出（elicitation）

 

01.不同大小的网用来捕获不同大小的需求。第一遍，我们可以用大网眼的渔网捞一遍需求池，一次得到所有的大需求。通过这些大需求，形成对软件的整体感觉。接下来，用网眼稍微小一些的渔网得到中等大小的需求，暂时还不用顾忌那些小需求。

 

02.拖网表达了另一个含义：需求会想鱼一样，会成长，也可能会死亡。今天渔网可能会漏掉一个需求，因为这个需求对于系统来说不重要。但是，根据每轮迭代的反馈，系统会朝着事先不可预知的方向发展，有些需求会变得越来越重要。同样，有些曾经被认为是重要的需求，重要性可能会降低，有时甚至降低到我们认为这些需求已经无效。

 

03.我们承认无法为一个项目编写出所有的故事，我们还是应该在早期尝试编写我们可以编写的故事，即便许多故事还只能停留在十分笼统的阶段。使用故事的好处之一就是可以用不同的详尽程度来编写。

 

04.我们使用的技巧必须是足够轻量的，并且不戳戳逼人，可以持续地、或多或少地应用于故事搜集：用户访谈、问卷调查、观察、故事编写工作坊。

 

05.仅仅因为这些问题是由用户提出就认为只是用户才有资格提出解决方案，这种观点是不对的。

 

06.如果有机会观察用户使用软件的情况，千万不要错过。这种机会可以让你快速直接地从用户哪里获得反馈，从而可以更早、更频繁地发布软件。

 

07.扔掉原型

　　在画好简单原型后几天内，一定要仍掉或擦掉它。原型并不是开发流程中的一个长期工件，因为长期留着可能会导致不必要的困惑。如果觉得在故事编写工作坊中还没有发现所有故事，可以把原型保留几天，在看看是否还能写出一些漏掉的故事，然后在考虑扔掉它。

　　*用户接下来最有可能做什么？用户会在这里犯什么错误？在这里，用户会有什么困惑？用户需要什么额外的信息？

 

08.如果一个故事是多余的或者能被更好的故事替换，就扔掉这个故事。

 

09.留意在故事编写工作坊中谁的贡献更多。有时，有些参与者在大部分或者整个工作坊期间都保持沉默。如果有这样的情况出现，在中间休息时去和这个参与者谈谈，确定他并不是不适用这个过程。有些参与者不愿意在同时或上司面前说出自己的想法，因此不要在整个过程中评价某个故事好或坏。一旦参与者觉得大家只是在记录而不是评价故事，会更乐意参与。

 

10.我再次重申故事编写工作坊中的讨论应在较高层面上。我们的目的是在短时间内写出更多故事。这不是设计界面或者解决问题的时候。