发表于: 2019-05-06 19:39:49
2 868
今天完成的事情:(一定要写非常细致的内容,比如说学会了盒子模型,了解了Margin) ,
1.查询了一些关于用户STORY的资料,了解了用户story的来源,定义,要素,编写原则、拆分,估算,测试,测速,优先级。
Use Case(用例) :在不展现一个系统或子系统内部结构的情况下,对系统或子系统的某个连贯的功能单元的定义和描述。
User Story(用户故事):描述对软件(或系统)用户或客户有价值的功能,只是需求描述,而 不是详细的需求规范。
什么是Epic?
Epic是史诗故事,通常需要花费多个Sprint来开发和测试,才能完成最终的交付。它通常范围比较大而细节描述较少,Epic的粒度比较大,在团队开发前通常需要拆分成多个更小的用户故事。
假如构造月度销售报表科目时,可能有这样的史诗故事:“作为销售经理,我希望能分区域看销售数据”。
什么是Theme?
Theme是指主题故事,是一组相关的用户故事的集合。Epic通常比较大,会分解出很多个小的用户故事,我们可以根据这些故事的相关性,通过Theme主题故事对其进行分组。
什么是Story?
Story是User Story的简称,用户故事是从用户的角度来描述用户渴望得到的功能。
用户故事通常按照如下的格式来表达:
英文:
As a <Role>, I want to <Activity>, so that <Business Value>.
中文:
作为一个<角色>, 我想要<活动>, 以便于<商业价值>
举例:
作为一个“网站管理员”,我想要“统计每天有多少人访问了我的网站”,以便于“我的赞助商了解我的网站会给他们带来什么收益。”
需要注意的是用户故事不能够使用技术语言来描述,要使用用户可以理解的业务语言来描述。
一个好的Story遵循INVEST原则:
独立性(Independent)— 要尽可能的让一个用户故事独立于其他的用户故事。
可协商性(Negotiable)— 一个用户故事的内容要是可以协商的,用户故事不是合同。
有价值(Valuable)— 每个故事必须对客户具有价值(无论是用户还是购买方)。
可以估算性(Estimable)—开发团队需要去估计一个用户故事以便确定优先级,工作量,安排计划。
短小(Small)— 一个好的故事在工作量上要尽量短小
可测试性(Testable)—一个用户故事要是可以测试的,以便于确认它是可以完成的。
Epic/ Theme /Story 管理示例:

一、什么是用户故事
用户故事描述了对用户、系统或软件购买者有价值的功能。一个好的用户故事包括三个要素:
1.角色:谁要使用这个功能。
2.功能:需要完成什么样的功能。
3.价值:为什么需要这个功能,这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达:
英文:As a <Role>, I want to <Activity>, so that <Business Value>.
中文:作为一个<角色>, 我想要<功能>, 以便于<商业价值>
举例:“作为招聘网站注册用户,我想要查看最近3天发布的招聘信息,以便于我看到最新的招聘信息”。
由于用户故事的描述信息以传统的手写方式写在纸质卡片上,所以Ron Jeffries(2001)对这三个方面称为3C:卡片(Card)、对话(Conversation)和确认(Confirmation)。
卡片(Card):用户故事一般在小卡片上写着故事的简短描述,工作量估算等。
交谈(Conversation):用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
确认(Confirmation):通过验收测试确认用户故事被正确完成。
二、如何编写用户故事
故事应该很清晰地体现对用户或客户的价值,最好的做法是让客户团队来编写故事。客户团队应包括能确定软件最终用户需求的人,可能包括测试者,产品管理者,真实用户和交互设计师。因为他们处于描述需求的最佳位置,也因为随后他们需要和开发者一同设计出故事细节并确定故事优先级。
为了构造好的用户故事,我们关注六个特征。一个优秀的故事应该具备以下特点:
独立的(Independent)— 我们要尽量避免故事间的相互依赖。在对故事排列优先级时,或者使用故事做计划时,故事间的相互依赖会导致工作量估算变得更加困难。通常我们可以通过两种方法来减少依赖性:1.将相互依赖的故事合并成一个大的、独立的故事;2.用一个不同的方式去分割故事。
可讨论的(Negotiable)— 故事卡是功能的简短描述,细节将在客户团队和开发团队的讨论中产生。故事卡的作用是提醒开发人员和客户进行关于需求的对话,它并不是具体的需求本事。一个用户故事卡带有了太多的细节,实际上限制了和用户的沟通。
对用户或客户有价值的(Valuable)— 用户故事应该很清晰地体现对用户或客户的价值,最好的做法是让客户编写故事。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候,他们将非常乐意写下故事。
可估算的(Estimable)—开发团队需要去估计一个用户故事以便确定优先级,工作量,安排计划。但是让开发者难以估计故事的问题来自:1.开发人员缺少领域知识;2.开发人员缺少技术知识;3.故事太大了。
小的(Small)— 一个好的故事在工作量上要尽量小,最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大,在安排计划,工作量估算等方面的风险就会越大。
可测试的(Testable)— 故事必须是可测试的。成功通过测试可以证明开发人员正确地实现了故事。如果一个用户故事不能够测试,那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子:用户必须觉得软件很好用。
拆分方法
1,可以考虑从软件--功能(feature)--子功能(sub-feature)--故事(user story)--任务(task)的拆分方法。好处是feature是传统软件范围定义的方法,比较好入手。
2,头脑风暴项目中存在哪些角色(role)。比如不同的用户,系统维护者等。并对role进行行为分析后,合并产生最终用户画像。
3,在feature层面,考虑不同role产生的user story。一般考虑系统的逻辑或流程进行分解。近期的可以细化到增、删、改、查的颗粒度。如:作为商品维护者,可以增加/删除/修改/查看一个商品的信息。
那么应该怎么拆呢?
我这里提供一个思路,大家可以揣摩一下。
大的User Story:
作为一个用户,我希望可以找到满足条件的书籍信息,以便我可以在书架上找到它。
第一个 User Story:
作为一个用户,我希望可以通过图书名称找到图书的书名、作者、馆藏状态以及索书号信息,以便我可以在书架上找到它。
第二个 User Story:
作为一个用户,我希望可以通过图书作者找到图书的书名、作者、馆藏状态以及索书号信息,以便我可以在书架上找到它。
或者这么拆:
大的User Story:
作为一个用户,我希望可以找到满足条件的书籍信息,以便我可以在书架上找到它。
第一个 User Story:
作为一个用户,我希望可以通过图书名称找到图书的书名以及索书号信息,以便我可以在书架上找到它。
第二个 User Story:
作为一个用户,我希望可以通过图书作者找到图书的书名、作者、馆藏状态以及索书号信息,以便我可以在书架上找到它。
拆分故事类型?
按工作流程:比如请假流程,可以把简单的首尾故事先切分出来,创建请假单,审批请假单,然后中间各个环节的审批流转作为独立的故事。
按功能操作:比如一般的后台报表都有增删改查的功能,可以按增删改查来切分。
按功能类型:比如接在线支付,微信、支付宝、银联可以拆分为3个故事来完成,当然每个下面还可以再切。
按内容范围:比如酒店详情页,先支持查看酒店基本信息和价格,再支持查看周边交通,地图位置等。
按用户需求层次:把性能和稳定性方面的考虑拆分成独立的新故事;
三、用户角色建模
在很多项目中,需求分析人员只是从一个角度编写用户故事,这样往往容易忽略一下需求(故事)。所以在编写用户故事前识别用户角色和虚拟人物(Persona)有很多好处。
以下是招聘网站可能出现的用户角色列表:

角色建模的步骤:
1.通过头脑风暴列出初始的用户角色集合:每个人要做的只是尽量在卡片上写出自己想到的角色。
2.整理最初的角色集合:对于有重叠的角色,把它们相应的卡片重叠在一起。
3.整合角色:在角色分组完成后,试着整合及浓缩角色。
4.提炼角色:一旦我们整合好角色,并且对角色之间的关系有了一个基本的了解,就有可能通过给每个角色定义一些特征来建立角色的模型。
虚拟人物,可以考虑一两个主要的用户角色写下虚拟人物定义,从虚拟人物的角度描述会使故事变得更加生动。 



四、如何搜集故事
用户需求并不容易得到,因为用户并不知道所有的需求,所有不能单靠用户给我们解释需求。Robertson 和 Robertson(1999)引入了拖网(trawling)这个词来描述收集需求的过程,要像“拖网渔船捕捞鱼”那样来收集需求。
首先,不同大小的网用来捕获不同大小的需求。第一遍,我们可以用大网眼的渔网捞一遍需求池,以此得到所有的大需求。通过这些大需求,形成对软件的整体感觉。接下来,用网眼稍微小一些的渔网得到中等大小的需求。
其次,需求会像鱼一样,会成长,也可能会死亡。今天渔网可能会漏掉一个需求,因为这个需求对于系统来说不重要。但是,根据每轮迭代的反馈,系统会朝着事先不可预知的方向发展,有些需求会变得越来越重要。
第三,在某一区域拖网捕鱼不可能捕获到所有的鱼,我们也不可能捕获所有需求,也可能捞到一些废弃的货物或漂浮的残,这会使需求膨胀。
最后,技能也是发现需求的一个要素,一个熟练的需求分析人员知道要到哪里去找需求。
故事会随着项目的进展而演进,所以我们可以通过用户访谈、观察用户、问卷调查和举办故事编写工作坊来发现用户故事。另外通过开放式、与背景无关的提问更容易获得有用的答案,例如:“告诉我你想怎么搜索工作?”就胜于“你要通过职位名称来搜索工作吗?”
五、与用户代理合作
对于一个项目来说,客户团队里包括一个或多个真实用户是极其重要的。但是但我们无法接触到他们时,我们就需要求助于用户代理(User Proxy),选择合适的用户代理对于项目的成功至关重要。
用户的经理:如果用户的经理不是软件的实际用户,并从中干预产品功能的开发。这种情况下,务必小心,不要得罪该用户经理,在部分围绕她的同时,想办法接触终端用户。
开发经理:让开发经理担任用户代理,是最坏的选择之一,除非你们开发的软件就是给开发经理用的。
销售人员:让销售人员充当用户代理是危险的,这会让大家对正在开发的产品没有一个全面的蓝图。然而,销售人员是非常好的中转站,应该让他们通过电话或销售拜访把你介绍给客户。
领域专家:领域专家很适合做用户代理,但要避免最终开发出来的软件仅仅针对那些与领域专家有类似水平的用户。
市场营销团队:他们可能更关注软件特性的数量而不是质量。他们可以为相关故事的优先级提供高层次的指导意见,但他们往往不具备很好的洞察力,无法给提供故事的具体细节。
以前的用户:应谨慎考虑她的目标和动机是否与实际用户的完全一致。
客户:考虑客户的期望是很重要的,因为开支票买软件的人是他们,而不是用户。
培训师和技术支持:由培训师和技术支持人员来充当用户代理看似是合乎逻辑的,不幸的是,他们做用户代理,你的系统最终将只成为一个易于培训系统或只是使得技术支持工作变得较为容易,而不是功能最大化服务于最终用户。
业务分析师或系统分析师:许多业务和系统分析师是很好的用户代理。他们唯一缺点是遇到问题喜欢空想,偶尔会在项目前期花太多时间做产品计划。
与用户代理合作时,做些什么?
1.能接触到用户但访问受限时:最好可以申请由部分用户组成一个用户顾问团队。
2.实在不能接触到用户时:必须求助于用户代理;如果有竞争产品,也可以用其做一些故事的来源。
3.避免陷入思维的误区:知道用户的想法,所以不需要或可以忽略用户代理。
六、用户故事验收测试
编写验收测试有很多好处,其一就是很多客户和开发人员讨论的细节可以通过验收测试记录下来。测试的要点记录了客户提出的一些假设,也提供了确认故事是否被完整实现的基本标准。
在写代码之前写测试
考虑每个故事,然后问类似下面的一些问题:
1.关于这个故事,程序员还需要知道什么?
2.对怎么实现这个故事,我的想法是什么?
3.有没有一些特殊情况会使这个故事有不一样的行为?
4.这个故事在什么情况会出错?
客户定义测试
客户可以和程序员与测试人员合作创建测试,但客户至少应该给我们详细指出一些测试,用以验证故事的实现是正确的。
测试是过程的一部分
测试时开发过程中的一部分,这点对使用用户故事非常重要。一般情况下,产品经理和测试人员共同负责列出详细的测试。产品经理带来驱动项目的公司目标的知识;测试人员则带来怀疑的心态。
多少测试才算多?
只要这些测试还在继续为故事增加价值和使它更加清晰,客户就应该继续写测试。同时,一个优秀的开发团队会为很多详细的用例编写单元测试。
集成测试框架
客户负责引领系统的开发。同时,在每轮迭代时都执行以往迭代的所有测试时非常重要的,开发团队应该自动化部分或全部验收测试。FIT和FitNesse是写验收测试的优秀工具。
测试类型
测试类型有很多,故事测试主要是功能性的测试,用来确定应用程序是如期运行的。
七、优秀的用户故事准则
优秀用户故事的一些准则:
1.试着让故事的大小能够在使用后让用户感到可以去喝杯咖啡休息一下;
2.不要让故事过早涉及用户界面;
3.实际编写故事时,要包括用户角色;
4.用主动语态编写故事;
5.为单个用户编写故事;
6.让客户编写故事,而不是开发人员;
7.用户故事要简短,它们只是提醒开发人员和客户进行对话;
8.不要给故事卡添加编号。
八、用户故事的估算
以故事点估算
用户故事通常用故事点来估算,故事点表明一个故事相对于其他故事的大小和复杂度。通常以理想工作日作为故事点的单位:相较于用连续时间估算,它更简单;相较于用完全模糊单位,它可使我们的估算拥有更好的依据。
以团队估算
故事估算应该由整个团队集体完成,团队大部分成员都参加估算是非常重要的。客户也可以参加,但是他不能提出他个人的估算或者在听到自己不赞成的估算时发表意见。
Wideband Delphi估算方法
与采用迭代方式进行开发软件的极限编程类似。最终目的是要为故事得到一个统一的估算值,这个迭代过程很少超过3轮。
三角测量
三角测试是帮助团队验证他们没有逐渐改变一个故事点含义的有效方法。
故事点估算
如果成熟团队,故事点估算不是问题。新团队建议用理想人天作为一个故事点的基准。这个方法同样适用于多团队并行要统一故事点基准的情况。
1、理想人天就是无干扰的情况下工作一天的工作量。定为1故事点。
2,定义一个1故事点的用户故事作为基准,其他的使用斐波纳切函数来做相对估算即可。
3,如果小于1故事点,统一为0.5故事点。
4,如果有一个用户故事很快能做完,但是担心会忘记,写下来定为0故事点。
5,开始估算团队能力的时候,可以根据团队人数、迭代时长、可用率(工作时间中的有效工作时间比率,建议50%-80%),来估计初始能力(velocity)。如:5个全职团队人员,四周(20工作日)迭代,70%的可用率,可算出初始能力为每个迭代70个故事点。
6,二到三个迭代后,团队可以按真实velocity来调整项目进度。
九、团队的速率
速率是每一轮迭代开发中能完成的工作量。一旦知道团队速率,就可以用它将理想日转换变成日历日。总故事点 / 团队的速率 = 需要的迭代次数。
初始速率
可以通过三种方法获得初始速率:
1.使用历史值
2.执行一轮初始迭代,使用那轮迭代的速率
3.猜测
测试速率
团队在在一轮迭代完成的故事点数的总和就是团队速率,不能将部分完成的故事也计算在速率中。用集中全部力量完成一个故事的方法会提高团队的意识:大家一起先完成一些故事比所有故事都只能完成一部分更有价值。

计划速率和实际速率
计算速率是用迭代开始前分配的故事点数,实际速率是迭代中实际完成的故事点书。计划速率与实际速率可能会出现偏差。






推荐一个核心+5个基本法则:一个核心:确定产品目标;5个基本法则:
1. KANO模型;2. CFS评分;3. ROI;4. 重要紧急矩阵;5. 前置需求;- 一个核心:确定产品目标
任何故事都是围绕着目标展开的,比如微信,初期最根本的定位是做通讯工具,他会花大量的精力在提升通讯速度方面;
比如寄快递,我2季度的产品目标是订单量达到xxx,围绕着这个目标,我们梳理出可能达到目标的几个维度,针对每个维度再做一层层的故事细化;
- 基本法则1:KANO模型
KANO模型是对用户需求进行分类和优先级排序的有效工具,感兴趣的可以去wiki上查看相关介绍。KANO定义了需求的3个层次:基本需求,期望需求,惊喜需求;后来我们团队内部又有同事对此进行了细化,可查看下图:
- 基本法则2:CFS评分
这个方法是我之前做交互的时候学到的,很奇怪,网上对这个方法的介绍很少,我这里稍微延伸一下;
什么是CFS?
C:Commonality普适性。
在我们的persona中,有哪些类型的用户会使用该功能?预估用户数大概有多少?
F:Frequency频繁性。
这个功能可能被使用的频次,是天天都会用到,还是偶尔一次?
S:Severity严重不可替代性。
这个功能有没有可替代的方案,用户没有这个功能就无法正常工作了?还是无关紧要,锦上添花的功能?(这里跟KANO有共通之处)
如何使用?
CFS有一套评分规则的,依照下图规则给每个故事进行打分,然后将得出的3个分值相乘,乘积最大的优先级最高。CFS就像一个标尺,我们可以依据统一标准快速的将所有故事进行排序。
举个栗子(微信运动)
说明:T=C*F*S的总和- 基本法则3:ROI(投入产出比):
完成一个需求所要投入的成本(资源、时间等),产出哪些收益(单量、用户数、业务扩展等),说白了就是投入成本低,产出高的先做。当产品发展到一定的规模,我们是继续投入精力把现有体验从80提升到90分?还是用同样的资源,去开辟新的增量市场?举个栗子,之前收到一个需求,在我们公众号在线寄件页新增一个国际寄件的入口,评估下来这个需求大概需要2人2天完成,但当时我们的资源全部都投入在小程序的研发上,而小程序的研发是个长期的工程,那最终我们暂停小程序,优先上线了国际寄件的业务,不仅对外宣传了我们公司的业务实力,而且带动了国际件的单量增长。- 基本法则4:重要紧急矩阵法
很简单也比较通用,直接看下图;
- 基本法则5:前置需求
比如微信的微信红包和绑定银行卡2个需求。通过CFS来看,微信红包肯定比绑定银行卡得分高多了(C&F值都很高),但是用户要先能绑定银行卡,才能发红包,绑卡是发红包的预动作,因此当然绑定的需求优先级高了(此处不要钻牛角尖,当然你可以请朋友给你转账,每次通过余额来发红包)。
维护故事的工具
这个完全看个人喜好啦,个人用过的有Excel文档,jira,leangoo。
Excel是我最早使用的工具,给大家截图看下大概的模板。





2.完成了页头页尾的STOY的
3.画出草船云页头页尾的原型图
明天计划的事情:(一定要写非常细致的内容)
1.写出回家学习APP导航栏story
2.完成回家学习APP一级导航栏原型图
3.完成K12行业APP导航方案调研
遇到的问题:(遇到什么困难,怎么解决的)
首页页头页尾的规范看不明白?查询后页看不懂?
收获:(通过今天的学习,学到了什么知识)
story的大概内容,软件AXURE的基本操作,页头页尾原型图的基本绘画。
评论