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

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



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


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


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


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


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


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


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

独立的:是为了避免故事间的依赖;

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

对用户或客户有价值的:

。。。


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


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


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

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

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


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

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


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

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


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


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

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


以上为读书所感。




©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页