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