用户故事与敏捷方法演讲人2020-09-29010-什么是用户故事0-什么是用户故事一份书面的故事描述用来做计划和作为提示有关故事的对
话用于具体化故事细节测试用于表达和编档故事细节且可用于确定故事何时完成021-规划发布和迭代1-规划发布和迭代大部分用户和客户对特
定特性的渴望程度小部分重要用户和客户对特定特性的渴望程度故事之间的关系。例如：某些故事优先级不高单与高优先级故事产生不可忽略的联系
032-收集编写用户故事原则特点（INVEST）可测试的小的可估计的FE对用户或客户有价值的D可讨论的独立的CBA原则特点（INV
EST）独立的Independent原则特点（INVEST）可讨论的Negotiable原则特点（INVEST）对用户或客户有价值
的ValuabletoPurchaserorUser原则特点（INVEST）可估计的Estimatable原则特点（INV
EST）小的Small原则特点（INVEST）可测试的Testable043-用户角色建模3-用户角色建模提炼极端用户角色提炼极有
代表的角色构建虚拟人物D建模步骤C用户角色BA脑暴-列出初始用户集合整理初始用户3-用户角色建模建模步骤提炼角色整合角色建模步骤脑
暴-列出初始用户集合一个角色，一个用户原则，不用笼统的例如“公司可以···”必须是用户级的合并重叠角色区分不完全重叠角色建模步骤整
理初始用户单独考量系统级角色区分完全不重叠角色建模步骤AC合并需求相同的角色整合角色归纳特殊需求角色排除不重要的角色B提炼角色整理
角色权重，为用户角色分级角色特征角度用户使用软件的频率用户在相关领域的知识水平用户使用计算机和软件的总体水平用户对当前正在开发的
软件的熟悉程度用户使用该软件的总体目标。有些用户注重使用的便捷性，有些更关注丰富的用户体验，等3-用户角色建模提炼极有代表的角色构
建虚拟人物用于构建核心用户场景，产品形态原则提炼极有代表的角色构建虚拟人物用于构建核心用户场景，产品形态原则3-用户角色建模提炼极
端用户角色用于收敛产品用户边际提炼极端用户角色用于收敛产品用户边际优先服务核心用户的原则054-搜集用户故事4-搜集用户故事方向方
法引蛇出洞-“需求已经存在了，只要用户描述解释出来就可以了”014-搜集用户故事方向02广撒网-“大量的用户需求框定基本形态”方向
引蛇出洞-“需求已经存在了，只要用户描述解释出来就可以了”弱点-其实很多需求用户并不知道，所以不能完全依据广撒网-“大量的用户需
求框定基本形态”弱点-用户对未知的需求操作参考了大量的已知形态，但不代表是正确的解决方案，也没有优劣比较可言，更有可能让需求膨胀
用户访谈问卷调查4-搜集用户故事方法故事编写工作坊观察方法越深入越需要具体的问题问题没有喜好或暗含喜好和引导C从笼统的问题开始提问
B用户访谈A问卷调查用户群体庞大，用于已知故事优先级筛选弱点-单向沟通，时间迟滞，不利于跟进方法观察用户很多情况不能描述清楚，无论
直接观察操作，还是收集用户操作数据更能真实的还原真正的需求（包括数据打点）故事编写工作坊工作坊的方式可以与用户一起快速大量的构建
原型，整理有效的用户故事，收集不同角色需求弱点是成本较高065-与代表用户的人群合作5-与代表用户的人群合作项目经理让5-与代表
用户的人群合作研发经理避5-与代表用户的人群合作销售人员聊5-与代表用户的人群合作领域专家减5-与代表用户的人群合作市场营销弱5-
与代表用户的人群合作曾经的用户好参客户-有购买决定权的人优培训和技术支持（部署安装、售前解答）5-与代表用户的人群合作分析师尊0
76-用户故事验收测试6-用户故事验收测试在开发之前写测试理想状态在组织用户故事时候就开始记录和明确细节，根据用户故事写出测试6-
用户故事验收测试客户定义测试客户+程序+测试一起创建测试6-用户故事验收测试测试是过程的一部分以用户角度出发做测试，程序通过验证不
代表使用通过验证，产品经理和测试共同负责详细的测试。产品=目标、测试=怀疑，形成完整测试持续测试6-用户故事验收测试6-用户故事验
收测试集成测试框架使用FIT表格类的文档测试类型用户交互测试可用性测试50%71%确保交互组件如期工作确保好用性能测试压力测试
62%60%测量在各种负荷下工作状态在超负荷极限值情况下的情况087-优秀用户故事准则7-优秀用户故事准则从目标开始大型软件角色众
多，最好的办法是考虑每种角色的使用目的分割大故事大的用户故事应切割成几个较小的故事例：-求职者可以发布简历1、求职者可以提交简历
，简历上只包括诸如名字、地址和教育背景这样的基本信息2、求职者可以提交简历，简历上可以包括雇主想看的所有信息。7-优秀用户故事准
则编写封闭的故事是指那种一个有意义的目标实现而结束的故事7-优秀用户故事准则卡片约束标注为约束的卡片帮助确定一些边际，同时可以帮助
测试7-优秀用户故事准则根据实现时间来确定故事规模7-优秀用户故事准则不要过早涉及用户界面7-优秀用户故事准则有些需求不是故事7-
优秀用户故事准则在故事中包含用户角色我作为（角色），想要（功能），以此（商业价值）7-优秀用户故事准则只为一个用户编写7-优秀用户
故事准则以主动语态编写求职者可以发布简历7-优秀用户故事准则由客户编写理想情况由客户编写故事，并且排列优先级（权重）不要编号7-优
秀用户故事准则7-优秀用户故事准则不要脱离目的故事卡的主要目的是用来提醒开发以及客户团队对功能进行讨论，仅作为提醒，尽量保持简洁，
加入少量细节即可098-估算用户故事8-估算用户故事010203无论什么时候获得有关故事的新信息，都允许我们改变之前的想法故事无论
长短都适用为工作进展和剩余工作提供有用信息特点0405不太精准的估算也不会有问题可以他用来制定发布计划8-估算用户故事故事点以故事
点为单位时间估算，故事点数量x单位时间=粗略估算8-估算用户故事以团队估算团队根据故事点给出时间段，团队估算更有意义8-估算用户故
事估算使用卡片团队中每个人都给出估算时间，并发表估算意见，相互激发想法和解决方案对时间估算更有帮助三角测量用来验证故事点的颗粒度就
是把对应时间单位的故事点放在一起，看看相同时间的估算是否一致尽量对齐颗粒度，减少开发速率的起伏第一轮故事点保持独立，不受用户界面细
节的影响如果项目一共有300个故事点，每周计划完成30个故事点，那需要10周（10个迭代）才能完成开发如果第一轮迭代（第一周）完
成了50个故事点，那他们需要6轮迭代才能完成项目，那就应该把开发速率调整为50个故事点，6论迭代完成项目，反之亦然8-估算用户故
事使用故事点8-估算用户故事如果用结对编程不会对速率产生影响不同团队对相同故事点的估算不同018-估算用户故事大故事分解成小故事后
，小故事的故事点总和不需要和大故事的相同02提醒类似小故事里的任务同理03109-发布计划9-发布计划发布时间包含功能排列故事优先
级混合优先级高风险故事根据架构需要安排优先级9-发布计划创建发布计划初始速率D根据故事点预计工期C选择迭代周期BA9-发布计划发布
时间一个时间范围，而不是时间点一个时间范围，而不是时间点但确定的时间点会提高效率和成功率，会折损发布内容9-发布计划包含功能DSD
MMoSCoW（莫斯科规则）必须有-Musthave2014基本功能应该有-Shouldhave2015短期替代功能可以有-C
ouldhave2016没时间就不考虑这次不会有-Won''thavethistime2017客户期望有-后续版本加9-发布
计划不能如期完成的（例如有预期性能特点或全新算法的）2014排列故事优先级推迟实现一个故事时对其他故事的影响2015故事对广泛用户
或客户的重要性2016故事对少部分重要用户或客户的重要性2017故事与其他故事的相关性（连接性）（比如放大是高优先级，同时缩小并不
是高优先级，但他们是同时存在的）2018成本会改变优先级20199-发布计划混合优先级同一个故事里会有细节的优先级不同，可以按照混
合优先级排列9-发布计划高风险故事本着优先支持最有价值的部分，但是根据用户期望的高优先级也会包含高风险的故事9-发布计划根据架构需
要安排优先级基础或非功能的需求会因为架构的约束而影响9-发布计划对于记录在电子表格重的故事，根据迭代进行排序，并分割每论迭代可以用
甘特图给不需要了解细节的利益相关人员创建发布计划故事卡钉墙上（公开）用于展示迭代输出详情给需要了解细节的利益相关人员11更多人把用
户故事理解为用户需求更多人把用户故事理解为用户需求12大故事大故事小故事小故事2小故事··n小故事3任务任务2任务3任务···n
1310-迭代计划10-迭代计划迭代计划会0102讨论故事从故事中分解出任务10-迭代计划迭代计划会0304开发人员承担每个任
务的职责讨论所有故事，接受任务后，开发单独估计各自承担的任务，确保不做过于乐观的承诺从高优先级开始提问分解任务1411-测量并监控
速率11-测量并监控速率测量速率迭代燃尽图计划速率与实际速率1512-故事不是什么12-故事不是什么与用例、IEEE830、交互设
计场景的区别12-故事不是什么与用例（usercase）区别与用例、IEEE830、交互设计场景的区别010203与IEEE8
30（softwarerequirementsspecification）区别交互设计场景（interactiondesig
nscennario）与IEEE830（softwarerequirementsspecification）区别侧重于需求
清单（checklist），而不是用户目标，用户故事不是用例用例案例使用案例标题：为招聘信息付费主要演员：招聘人员水平：
演员目标前提是：工作信息已经输入，但无法查看。最低限度的保证：无成功保证：职位发布；招聘人员的信用卡被扣款。主要成功场景：
1.招聘者提交信用卡号、日期、认证信息。2.系统验证信用卡。3.系统全额收取信用卡费用。4.求职者可查看招聘信息。
5.招聘者会得到一个唯一的确认号码。扩展：2a:该卡不是系统接受的类型。2a1:系统通知用户使用不同的卡。2b:
该卡已过期。2b1:2b1:系统通知用户使用另一张卡.2c：该卡已过期：2c1：系统通知用户使用不同的卡。2c1：系
统通知用户使用其他卡。3a：该卡可用额度不足，无法发布广告。3a1：系统对当前信用卡尽量收费。3a2：告诉用户这个问题，并要
求用户输入第二张信用卡来支付剩余的费用。该用例在步骤2中继续进行。用户故事不是用例最明显的区别是是范围不同-用例更大，并伴有文本
，更关注软件实现，会有很多界面设计细节，而不关注商业目标，目的不同目的是记录客户和开发团队之间的协议，用户故事是为了方便发布计划
和迭代计划，用来获取用户具体需求用例的每条路径称之为场景，每个用例可能会有多个场景，并且有条件约束用例是分析结果的记录，而用户故事
是与用户沟通用户故事不是场景人际交互设计师使用场景（scenario），场景是用户与计算机交互的详细描述，事实上交互设计场景
比用例场景更大更全面应用环境使用者目标或目的行动和事件1613-用户故事的优势13-用户故事的优势用户故事强调口头沟通人人
可以理解用户故事用户故事的大小适合做计划用户故事适合与迭代开发用户故事鼓励延迟细节用户故事支持随机应变的开发13-用户故事的优势用
户故事鼓励参与性设计用户故事传播隐性知识用户故事的不足13-用户故事的优势用户故事强调口头沟通一份共享的文档并不是已经达成共识13
-用户故事的优势人人可以理解用户故事用户故事更简洁明了的让人理解和沟通，并且加强了记忆13-用户故事的优势用户故事的大小适合做计划
相对IEEE830续期列表太过细节，内容量大，而交互设计场景和用例又有些宽泛，优先级排布意义不大，用户故事可以控制大小，可以方便的
发布规划、开发、测试13-用户故事的优势用户故事适合与迭代开发IEEE830太细，但很难做到完美13-用户故事的优势用户故事鼓励
延迟细节由粗略的故事可能衍生更多的细节，非常适合敏捷开发，开发时才需要更多细节填补LOGO13-用户故事的优势用户、客户通常不会准
确的知道自己的实际需求01即便软件开发者知道所有的需求，很多随开发进展变得清晰02就算假设所有的细节可以在前面弄清楚，人们也没有
能力理解这么多的细节03用户故事支持随机应变的开发就算理解了这么多的细节，产品和项目也有可能变更04是人都会犯错05https:/
/www.wps.cn13-用户故事的优势用户故事鼓励参与性设计让用户从最初的设计就参与进来，用户故事中完全没有专业术语，完全可以
13-用户故事的优势用户故事传播隐性知识面对面的和用户沟通促进了团队的隐性知识积累，越频繁的沟通交流越有积累13-用户故事的优势用
户故事的不足大量的系复杂——尽量使用角色去淡化关系，2014大量的用户故事的大项目会使用户故事之间的关系复杂，尽量用角色来淡化故事
关系的复杂性，而且要保障用户故事不要过于细化2015开发过程中需要文档记录积累以延续，要兼顾文档的存留，使用在线文档管理以故事为骨
架，以测试文档为肉可能会解决这个问题2016超大团队的层级信息流通性，需要做好平衡20171714-用户故事不良征兆14-用户故事
不良征兆故事太小合并相同相似的故事14-用户故事不良征兆故事互相依赖划分不恰当或故事太小会产生必须做完某事再做某事的现象，，要把有
依赖关系的故事合并成一个故事镀金开发人员主观添加超过用户需求的功能自我约束减少镀金细节太多花太多时间写故事、记录，减少记录过多细节
避免过多记录，增加口头交流14-用户故事不良征兆过早考虑用户界面细节优先看用户目标，减少界面细节的定义想的太远14-用户故事不良征
兆故事划分太过频繁故事太大以至于一轮迭代完，或者客户只希望下轮迭代完成高优先级的子故事过于频繁的划分故事说明出现了问题，考虑剩
余的故事找出真正的需求客户很难为故事安排优先级安排优先级太困难可能是故事太大，很难安排优先级也可能是故事不够清晰，需要重写客户不愿意写用户故事，也不愿意为故事安排优先级14-用户故事不良征兆1815-Scrum与用户故事15-Scrum与用户故事15-Scrum与用户故事在sprint结束时，团队在sprint评审会上演示所完成的功能在极限编程里面的客户角色，在scrum中称为产品负责人61每个sprint都要完成一部分可以潜在交付的产品功能增量产品负责人给产品backlog排列优先级52在sprint的开始，团队从产品backlog中选下一个Spring要完成的任务在每日scrum简会中，每个团队成员需要回答三个问题，我昨天完成了什么，我今天要做什么？我有哪些问题？341916-其他话题16-其他话题2017-用户角色17-用户角色2118-实例与流程18-实例与流程22、19-附录-极限编程-XP、19-附录-极限编程-XP感谢聆听 |
|
