读书笔记1——《用户故事与敏捷方法》

读《用户故事与敏捷方法》这本书有三天了，看了差不多快四分之一。惭愧的是看完后不能像大家那样有很多总结，很快能举一反三，有自己的想法等等，大概是看的书真的太少的缘故。不过目前对自己的要求也很明确，主要还是扫盲和快速入门。

流程：搜集需求，编写用户故事放入Backlog，计划会议将故事细化、确定验收标准，计划扑克估算故事的、讲故事分成小任务、估算工作时间、将故事放入Sprint Backlog，优先级排序…

故事有三个方面因素需要考虑：故事描述、故事细节、测试故事的部分。传说中的3C.

故事的关键在于写下来的是对客户有价值的地方。

用户故事的描述要控制在合理且实际的范围。具体的故事细节可以不用在意，可以让开发团队和客户后面慢慢讨论。

客户团队的构建：测试、交互设计师、实际用户、产品经理

验收测试，在迭代开始前或中即可开始。

优秀的用户故事应当具备的几个特点：独立的、可讨论的、对用户或客户有价值的、可估计的、小的、可测试的 （INVEST）

独立的：是为了避免故事间的依赖；

可讨论的：强调了需求的对话的必要性

对用户或客户有价值的：

。。。

给故事加上注释的最好方法是给它编写测试用例。

用户角色确定的根本目的是为了使我们站在用户的角度去思考问题，以此让影响到项目成败的那些角色感到满意

角色建模：头脑风暴（开发人员及客户…）--> 整理角色集合  -->整合角色-->提炼角色（定义角色特征）

虚构角色：不只是给用户角色去个名字，二是让其做真正代表产品的目标用户

极端人物：能够搜集到被遗漏的故事

引出&捕捉式搜集需求的方式不可取，问题在于：用户并不知道所有需求，不能单纯依靠引出。

trawling拖网，根据重要性、有迭代的、不是所有的都捕捉到的方式。而使用该技能的重要要素是，知道去哪里能捕捉到需求（对人的要求）！！

传统规范过程与敏捷过程搜集需求的方式最大的区别在于，后者认为用户故事没法在单一阶段获取所有的用户故事，而是依靠迭代来不断加入用户故事。

但是另一点就是，要尽早尝试编写故事，并且故事描述较模糊也是可以容忍的，然后不断演进使其为更小的、更有用的多个故事。

搜集故事的方法：用户访谈（真实用户、不同角色用户、与用户一同寻找需求、开放式及背景无关式提问）、问卷调查（捕捞故事法中不太有效）、观察（有机会了解到用户实际子做的事情时）、故事编写工作坊（重点在于数量而非质量，结合头脑风暴及简单原型，甚至可以结合竞争对手或同类产品）

原型里的流程，需要让每个角色都重复走这个过程，所以在这之前要决定从哪种用户角色开始；可用方框代表软件的某个页面，然后写出角色在当前页面可以做什么，然后下一界面…逐步讨论

画原型的几个问题有助于找到遗漏故事：用户接下来最有可能做什么？用户会在这里犯什么错误？用户在这里会有什么困惑？用户需要什么额外的信息？

以上为读书所感。