用户故事与敏捷方法课件.pptx

1、用户故事与敏捷方法演讲人2020-09-29010-什么是用户故事 0-什么是用户故事 有关故事的对话用于具体化故事细节一份书面的故事描述用来做计划和作为提示 测试用于表达和编档故事细节且可用于确定故事何时完成021-规划发布和迭代1-规划发布和迭代小部分重要用户和客户对特定特性的渴望程度故事之间的关系。例如：某些故事优先级不高单与高优先级故事产生不可忽略的联系大部分用户和客户对特定特性的渴望程度032-收集编写用户故事原则特点（INVEST）DCBA独立的可讨论的对用户或客户有价值的可估计的E小的F可测试的独立的uIndependent原则特点（INVEST）可讨论的uNegotiable原

2、则特点（INVEST）对用户或客户有价值的uValuable to Purchaser or User原则特点（INVEST）可估计的uEstimatable原则特点（INVEST）小的uSmall原则特点（INVEST）可测试的uTestable原则特点（INVEST）043-用户角色建模3-用户角色建模用户角色建模步骤提炼极有代表的角色构建虚拟人物提炼极端用户角色DCAB3-用户角色建模建模步骤脑暴-列出初始用户集合整理初始用户提炼角色整合角色一个角色，一个用户原则，不用笼统的例如“公司可以”必须是用户级的建模步骤脑暴-列出初始用户集合建模步骤整理初始用户合并重叠角色区分不完全重叠角色单独

3、考量系统级角色区分完全不重叠角色建模步骤整合角色ABC合并需求相同的角色归纳特殊需求角色排除不重要的角色整理角色权重，为用户角色分级角色特征角度 用户使用软件的频率用户在相关领域的知识水平用户使用计算机和软件的总体水平用户对当前正在开发的软件的熟悉程度用户使用该软件的总体目标。有些用户注重使用的便捷性，有些更关注丰富的用户体验，等提炼角色提炼极有代表的角色构建虚拟人物u用于构建核心用户场景，产品形态原则3-用户角色建模用于构建核心用户场景，产品形态原则提炼极有代表的角色构建虚拟人物提炼极端用户角色u用于收敛产品用户边际3-用户角色建模用于收敛产品用户边际u优先服务核心用户的原则提炼极端用户角色

4、054-搜集用户故事4-搜集用户故事方向方法4-搜集用户故事方向0201广撒网-“大量的用户需求框定基本形态”引蛇出洞-“需求已经存在了，只要用户描述解释出来就可以了”引蛇出洞-“需求已经存在了，只要用户描述解释出来就可以了”弱点-其实很多需求用户并不知道，所以不能完全依据广撒网-“大量的用户需求框定基本形态”弱点-用户对未知的需求操作参考了大量的已知形态，但不代表是正确的解决方案，也没有优劣比较可言，更有可能让需求膨胀方向4-搜集用户故事方法用户访谈问卷调查故事编写工作坊观察方法用户访谈CBA从笼统的问题开始提问问题没有喜好或暗含喜好和引导越深入越需要具体的问题用户群体庞大，用于已知故事优先

5、级筛选u弱点-单向沟通，时间迟滞，不利于跟进问卷调查观察u用户很多情况不能描述清楚，无论直接观察操作，还是收集用户操作数据更能真实的还原真正的需求（包括数据打点）方法故事编写工作坊 工作坊的方式可以与用户一起快速大量的构建原型，整理有效的用户故事，收集不同角色需求 弱点是成本较高065-与代表用户的人群合作项目经理u让5-与代表用户的人群合作研发经理u避5-与代表用户的人群合作销售人员u聊5-与代表用户的人群合作领域专家u减5-与代表用户的人群合作市场营销u弱5-与代表用户的人群合作曾经的用户u好5-与代表用户的人群合作参客户-有购买决定权的人 优培训和技术支持（部署安装、售前解答）分析师u尊

6、5-与代表用户的人群合作076-用户故事验收测试理想状态在组织用户故事时候就开始记录和明确细节，根据用户故事写出测试6-用户故事验收测试在开发之前写测试客户定义测试u客户+程序+测试一起创建测试6-用户故事验收测试以用户角度出发做测试，程序通过验证不代表使用通过验证，产品经理和测试共同负责详细的测试。产品=目标、测试=怀疑，形成完整测试6-用户故事验收测试测试是过程的一部分持续测试6-用户故事验收测试集成测试框架u使用 FIT 表格类的文档6-用户故事验收测试测试类型确保交互组件如期工作用户交互测试50%确保好用可用性测试71%在超负荷极限值情况下的情况压力测试60%测量在各种负荷下工作状态性

7、能测试62%087-优秀用户故事准则大型软件角色众多，最好的办法是考虑每种角色的使用目的7-优秀用户故事准则从目标开始例：-求职者可以发布简历 1、求职者可以提交简历，简历上只包括诸如名字、地址和教育背景这样的基本信息 2、求职者可以提交简历，简历上可以包括雇主想看的所有信息。分割大故事大的用户故事应切割成几个较小的故事编写封闭的故事u是指那种一个有意义的目标实现而结束的故事7-优秀用户故事准则标注为约束的卡片帮助确定一些边际，同时可以帮助测试7-优秀用户故事准则卡片约束根据实现时间来确定故事规模7-优秀用户故事准则不要过早涉及用户界面7-优秀用户故事准则有些需求不是故事7-优秀用户故事准则在

8、故事中包含用户角色u我作为（角色），想要（功能），以此（商业价值）7-优秀用户故事准则只为一个用户编写7-优秀用户故事准则以主动语态编写u求职者可以发布简历7-优秀用户故事准则由客户编写u理想情况由客户编写故事，并且排列优先级（权重）7-优秀用户故事准则不要编号7-优秀用户故事准则不要脱离目的u故事卡的主要目的是用来提醒开发以及客户团队对功能进行讨论，仅作为提醒，尽量保持简洁，加入少量细节即可7-优秀用户故事准则098-估算用户故事8-估算用户故事特点01无论什么时候获得有关故事的新信息，都允许我们改变之前的想法02故事无论长短都适用03为工作进展和剩余工作提供有用信息04不太精准的估算也不会

9、有问题05可以他用来制定发布计划以故事点为单位时间估算，故事点数量x单位时间=粗略估算8-估算用户故事故事点以团队估算u团队根据故事点给出时间段，团队估算更有意义8-估算用户故事估算8-估算用户故事u使用卡片团队中每个人都给出估算时间，并发表估算意见，相互激发想法和解决方案对时间估算更有帮助就是把对应时间单位的故事点放在一起，看看相同时间的估算是否一致三角测量用来验证故事点的颗粒度使用故事点8-估算用户故事n如果项目一共有300个故事点，每周计划完成30个故事点，那需要10周（10个迭代）才能完成开发 如果第一轮迭代（第一周）完成了50个故事点，那他们需要6轮迭代才能完成项目，那就应该把开发速

10、率调整为50个故事点，6论迭代完成项目，反之亦然 n尽量对齐颗粒度，减少开发速率的起伏n第一轮故事点保持独立，不受用户界面细节的影响如果用结对编程u不会对速率产生影响8-估算用户故事8-估算用户故事提醒不同团队对相同故事点的估算不同01大故事分解成小故事后，小故事的故事点总和不需要和大故事的相同02类似小故事里的任务同理03109-发布计划9-发布计划发布时间包含功能排列故事优先级根据架构需要安排优先级高风险故事混合优先级9-发布计划选择迭代周期根据故事点预计工期初始速率创建发布计划DCAB发布时间u一个时间范围，而不是时间点9-发布计划一个时间范围，而不是时间点但确定的时间点会提高效率和成功

11、率，会折损发布内容包含功能uDSDM9-发布计划MoSCoW（莫斯科规则）必须有-Must have基本功能2014应该有-Should have短期替代功能2015可以有-Could have没时间就不考虑2016这次不会有-Wont have this time客户期望有-后续版本加2017排列故事优先级9-发布计划2014不能如期完成的（例如有预期性能特点或全新算法的）2016故事对广泛用户或客户的重要性2018故事与其他故事的相关性（连接性）（比如放大是高优先级，同时缩小并不是高优先级，但他们是同时存在的）2015推迟实现一个故事时对其他故事的影响2017故事对少部分重要用户或客户的重

12、要性2019成本会改变优先级同一个故事里会有细节的优先级不同，可以按照混合优先级排列9-发布计划混合优先级本着优先支持最有价值的部分，但是根据用户期望的高优先级也会包含高风险的故事9-发布计划高风险故事根据架构需要安排优先级u基础或非功能的需求会因为架构的约束而影响9-发布计划9-发布计划创建发布计划输出详情给需要了解细节的利益相关人员可以用甘特图给不需要了解细节的利益相关人员对于记录在电子表格重的故事，根据迭代进行排序，并分割每论迭代故事卡钉墙上（公开）用于展示迭代11更多人把用户故事理解为用户需求更多人把用户故事理解为用户需求12大故事大故事小故事任务任务2任务3任务n小故事2 小故事3

13、小故事n 1310-迭代计划 迭代计划会10-迭代计划10-迭代计划迭代计划会开发人员承担每个任务的职责03讨论所有故事，接受任务后，开发单独估计各自承担的任务，确保不做过于乐观的承诺04讨论故事01从故事中分解出任务02提问u分解任务从高优先级开始1411-测量并监控速率11-测量并监控速率测量速率计划速率与实际速率迭代燃尽图1512-故事不是什么与用例、IEEE830、交互设计场景的区别12-故事不是什么12-故事不是什么与用例、IEEE830、交互设计场景的区别与IEEE830（software requirements specification）区别与 用例（user case）区别

14、交互设计场景（interaction design scennario）010203与IEEE830（software requirements specification）区别 侧重于需求清单（check list），而不是用户目标，用例案例 使用案例标题：为招聘信息付费 主要演员：招聘人员 水平：演员目标 前提是：工作信息已经输入，但无法查看。最低限度的保证：无 成功保证：职位发布；招聘人员的信用卡被扣款。主要成功场景：1.招聘者提交信用卡号、日期、认证信息。2.系统验证信用卡。3.系统全额收取信用卡费用。4.求职者可查看招聘信息。5.招聘者会得到一个唯一的确认号码。扩展：2a:该卡不是系

15、统接受的类型。2a1:系统通知用户使用不同的卡。2b:该卡已过期。2b1:2b1:系统通知用户使用另一张卡.2c：该卡已过期：2c1：系统通知用户使用不同的卡。2c1：系统通知用户使用其他卡。3a：该卡可用额度不足，无法发布广告。3a1：系统对当前信用卡尽量收费。3a2：告诉用户这个问题，并要求用户输入第二张信用卡来支付剩余的费用。该用例在步骤2中继续进行。用户故事不是用例用户故事不是用例 最明显的区别是是范围不同-用例更大，并伴有文本，更关注软件实现，会有很多界面设计细节，而不关注商业目标，目的是记录客户和开发团队之间的协议，用户故事是为了方便发布计划和迭代计划，用来获取用户具体需求目的不同

16、 用例的每条路径称之为场景，每个用例可能会有多个场景，并且有条件约束 用例是分析结果的记录，而用户故事是与用户沟通用户故事不是场景 人际交互设计师使用场景（scenario），场景是用户与计算机交互的详细描述，事实上交互设计场景比用例场景更大更全面 应用环境 使用者 目标或目的 行动和事件1613-用户故事的优势13-用户故事的优势人人可以理解用户故事用户故事适合与迭代开发用户故事支持随机应变的开发用户故事强调口头沟通用户故事的大小适合做计划用户故事鼓励延迟细节13-用户故事的优势用户故事传播隐性知识用户故事鼓励参与性设计用户故事的不足用户故事强调口头沟通u一份共享的文档并不是已经达成共识13

17、-用户故事的优势用户故事更简洁明了的让人理解和沟通，并且加强了记忆13-用户故事的优势人人可以理解用户故事相对IEEE830续期列表太过细节，内容量大，而交互设计场景和用例又有些宽泛，优先级排布意义不大，用户故事可以控制大小，可以方便的发布规划、开发、测试13-用户故事的优势用户故事的大小适合做计划用户故事适合与迭代开发uIEEE830 太细，但很难做到完美13-用户故事的优势由粗略的故事可能衍生更多的细节，非常适合敏捷开发，开发时才需要更多细节填补13-用户故事的优势用户故事鼓励延迟细节LOGOhttps:/13-用户故事的优势用户故事支持随机应变的开发01用 户、客 户 通 常 不 会 准

18、 确 的 知 道 自 己 的实 际 需 求02即 便 软 件 开 发 者 知 道 所 有 的 需 求，很 多随 开 发 进 展 变 得 清 晰 03就 算 假 设 所 有 的 细 节 可 以 在 前 面 弄 清 楚，人 们 也 没 有 能 力 理 解 这 么 多 的 细 节04就 算 理 解 了 这 么 多 的 细 节，产 品 和 项 目也 有 可 能 变 更05是 人 都 会 犯 错让用户从最初的设计就参与进来，用户故事中完全没有专业术语，完全可以13-用户故事的优势用户故事鼓励参与性设计面对面的和用户沟通促进了团队的隐性知识积累，越频繁的沟通交流越有积累13-用户故事的优势用户故事传播隐性

19、知识用户故事的不足13-用户故事的优势2014大量的系复杂尽量使用角色去淡化关系，2016开发过程中需要文档记录积累以延续，要兼顾文档的存留，使用在线文档管理以故事为骨架，以测试文档为肉可能会解决这个问题2015大量的用户故事的大项目会使用户故事之间的关系复杂，尽量用角色来淡化故事关系的复杂性，而且要保障用户故事不要过于细化2017超大团队的层级信息流通性，需要做好平衡1714-用户故事不良征兆故事太小u合并相同相似的故事14-用户故事不良征兆划分不恰当或故事太小会产生必须做完某事再做某事的现象，要把有依赖关系的故事合并成一个故事14-用户故事不良征兆故事互相依赖开发人员主观添加超过用户需求的

20、功能u自我约束减少镀金镀金花太多时间写故事、记录，减少记录过多细节u避免过多记录，增加口头交流细节太多过早考虑用户界面细节u优先看用户目标，减少界面细节的定义14-用户故事不良征兆想的太远14-用户故事不良征兆过于频繁的划分故事说明出现了问题，考虑剩余的故事找出真正的需求故事划分太过频繁故事 太大以至于一轮迭代完，或者客户只希望下轮迭代完成高优先级的子故事可能是故事太大，很难安排优先级也可能是故事不够清晰，需要重写客户很难为故事安排优先级安排优先级太困难客户不愿意写用户故事，也不愿意为故事安排优先级14-用户故事不良征兆1815-Scrum 与用户故事15-Scrum 与用户故事15-Scru

21、m 与用户故事1在极限编程里面的客户角色，在scrum中称为产品负责人2产品负责人给产品backlog 排列优先级3在sprint的开始，团队从产品backlog中选下一个Spring要完成的任务6在sprint 结束时，团队在sprint评审会上演示所完成的功能5每个sprint都要完成一部分可以潜在交付的产品功能增量4在每日scrum简会中，每个团队成员需要回答三个问题，我昨天完成了什么，我今天要做什么？我有哪些问题？1916-其他话题16-其他话题2017-用户角色17-用户角色2118-实例与流程18-实例与流程22、19-附录-极限编程-XP、19-附录-极限编程-XP感 谢 聆 听