- 用户故事和敏捷方法
- 用户故事
- WHAT
- 是什么
- 组成
- card
- 书面的故事描述，用于计划和提示
- 功能的简短描述
- conversation
- 有关故事的对话，具体化故事细节
- 获得需求细节
- confirmation
- 测试，表达、编档故事细节，确定完成时间
- 记录需求
- 注意
- 对用户有价值的功能
- 描述用户目标
- 一轮迭代完成后，该故事就不存在了
- 过多细节一般写为注释
- 不是什么
- IEEE 830——软件需求规格指南
- 功能性需求编写方法
- “系统应该…”
- 区别
- 侧重关注需求的检查清单，而不是用户目标
- 需求成本不可见
- 不会回答“如何使用以及为什么有人需要这个功能”
- 用例——use case
- 目的
- 为了记录客户和开发团队之间的协议，方便讨论达成协议
- 内容
- 对系统之间以及一个或多个用户之间交互的一般性描述
- 一般携程分析活动的结果
- 区别
- 完整性不同，用例相当于故事+测试
- 寿命
- 容易包括用户界面
- 过早关注软件实现，而不是商业目标
- 类型
- 基本用例
- 用户意图
- 系统职责
- 用力摘要
- 范围比用户故事大
- 生命周期与产品生命周期相同
- 场景
- 组成
- setting（应用环境）
- 故事发生的地方
- actor（使用者）
- 至少包含一个使用者
- goals or objective（目标或目的）
- 一个或多个目标
- actions（行动和事件）
- 故事情节
- 使用者采取的步骤用以达成他的目标或系统的响应
- 区别
- 包含更多细节
- 涵盖多个故事
- 可以由多个用例组成
- WHY
- 目的
- 为了更方便发布计划和迭代计划，充当用户具体需求的占位符
- 优势
- 强调口头沟通
- 人人都可以理解
- 大小适合做计划
- 适用于迭代开发
- 鼓励延迟细节
- 支持随机应变的开发
- 鼓励参与性设计
- 传播隐性知识
- 不足
- 拥有大量用户故事的大型项目中，故事之间的关系可能错综复杂
- 使用角色淡化此问题
- 保证不要过于细节化
- 用例的固有层级性会便于收集需求
- 无可追溯性
- 在每一轮迭代开始时，生成一份文档，列出当前迭代计划中的每一个故事和测试
- 不适用于特大规模多团队的结构
- 记录交流
- HOW
- 怎么样
- 大故事拆分成小故事
- 不需要拆分到太细的小故事
- 不需要像需求文档一样扩充
- 每个故事代表一个独立的功能
- 完成时间——用户期望——验收测试
- 测试描述可以简短、不完整
- 测试描述可以在任何时候加入或删除
- 不良征兆
- 故事太小
- 经常需要调整估算
- 故事相互依赖
- 难以做迭代计划
- 在迭代中实现了计划外的功能
- 细节太多
- 过早考虑用户界面细节
- 想的太远
- 故事划分太过频繁
- 扫描剩余故事，找出真正需要划分的故事
- 客户很难为故事安排优先级
- 可能是故事太大
- 体现不出商业价值
- 客户不愿意写用户故事，也不愿意为故事安排优先级
- 优先级
- 大部分用户和客户对特定特性的渴望程度
- 小部分重要用户和客户对特定特性的渴望程度
- 故事之间的关系
- 用户角色
- 内容
- 一组属性的集合，刻画了一群人的特征以及这群人与系统可能的交互
- 方法
- 头脑风暴，列出初始的用户角色合集
- 避免从单一用户角度编写
- 识别与软件交互的不同角色
- 整理最初的角色合集
- 整合角色
- 提炼角色
- 给每个角色定义一些特征
- 用户使用软件的频率
- 用户在相关领域的知识水平
- 用户使用计算机和软件的总体水平
- 用户对当前正在开发的软件的熟悉程度
- 用户使用该软件的总体目标
- 便捷性
- 丰富的用户体验
- 原则
- 用户角色定义的是人，而不是其他外部系统
- 两个额外技术
- 虚构人物
- 假想的用户角色代表
- 为一两个主要的用户角色写下虚构人物定义
- 极端人物
- 有助于搜集原本被遗漏的故事
- 用户代理
- 领域专家
- 建立领域模型，确定业务规则
- 实际用户
- 了解工作流以及使用方面的问题
- 用户顾问团队
- 设立客户团队
- 邀请真实用户加入，邀请每种类型的用户
- 确定一位负责人
- 确定项目必须成功的关键因素
- 搜集故事
- 用户访谈
- 捕获新故事
- 选择正确的受访者
- 开放式问题
- 与背景无关的问题
- 问卷调查
- 有助于收集已有故事的相关信息
- 收集有关故事优先级信息的好方法
- 得到大量用户关于某些具体问题的回答
- 不利于跟进后续问题
- 观察
- 快速直接地从用户那里获得反馈
- 更早、更频繁地发布软件
- 故事编写工作坊
- 参与人员
- 开发人员、用户、产品客户和其他编写故事有帮助的人
- 编写尽可能多的故事
- 头脑风暴的最佳要素和简单原型法
- 工作流程图
- 编写故事
- 六个特征
- Independent（独立性）
- 避免故事间的互相依赖
- 将相互依赖的故事合并成一个大的、独立的故事
- 用一个不同的方式去分割故事
- 交付顺序无关
- Negotiable（可讨论性的）
- 故事是可以讨论的
- 以注释的形式记录细节，但不要太多
- 一些注释用以表明在对话中亟待解决的问题
- 将细节转变为测试
- Valuable to Purchasers or Users（对用户或客户有价值的）
- 让客户编写
- 避免出现用户界面和技术方面的定义
- Estimatable（可估计的）
- 将故事变为可用代码的时间量
- Small（小的）
- 故事大小合适
- 分割故事
- 复合故事
- 由多个小故事组成
- 按照增删改的逻辑分解
- 根据数据边界分解
- 复杂故事
- 不确定性
- 分为调研故事和开发故事
- 探针试验
- 合并故事
- Testable（可测试的）
- 非功能性需求不可测试
- 易用性
- 无明确定义
- 优秀准则
- 从目标故事开始
- 了解用户使用我们软件的目的
- 分割故事——切蛋糕
- 每个故事都提供某种程度的完整的功能
- 编写封闭故事
- 随着一个有意义的目标的实现而结束的故事
- 卡片约束
- 对于任何必须要遵守而不需要直接实现的故事
- 根据实现时间来确定故事规模
- 不过早涉及用户界面
- 可以用用户故事以外的形式表达某些需求
- 在故事里包括用户角色
- 我作为（角色），想要（功能），以此（商业价值）
- 只为一个用户编写
- 以主语动态编写
- 由客户编写
- 排列优先级
- 不要用编号，可以利用标题
- 不要忘记意图
- 提醒开发人员和客户团队对功能进行讨论
- 简洁
- 不要太多细节
- 验收测试
- 提供确认故事是否被完整实现的基本标准
- 在为故事编写代码前就开始制定验收测试
- 开发人员和客户讨论故事且需要记录明确的细节时
- 在迭代开始时，在写代码前作为一项专门的任务
- 在开发中或之后的任何时候发现新的测试时
- 获得测试可以提出的问题
- 关于这个故事，程序员还需要知道些什么？
- 对怎么实现这个故事，我的想法是什么？
- 有没有一些特殊情况会使这个故事有不一样的行为？
- 这个故事在什么情况下会出错？
- 各方职责
- 客户应该更专注于那些能向开发团队说明故事意图的测试
- 开发团队应该制定更为详细的单元测试
- 测试时间
- 每轮迭代结束时应执行验收测试，包括以往的验收测试
- 自动化部分或全部验收测试
- 集成测试框架FIT
- FitNesse
- 测试类型
- 用户交互测试
- 确保所有用户交互组件如期工作
- 可用性测试
- 确保程序好用
- 性能测试
- 测量应用程序在各种负荷下的工作状况
- 压力测试
- 使应用程序在用户和事务的极限值情况或其他任何让应用程序处在压力下的情况运行
- 测试的是缺陷，而不是覆盖率
- 估算用户故事
- 估算方法
- 故事点估算（story point）
- 理想时间考虑故事
- Wideband Delphi方法
- 团队估算
- 能保持每轮迭代的估算一致性
- 估算之后
- 三角测量
- 与其他估算进行比较
- 验证团队没有逐渐改变一个故事点的含义
- 精度随故事大小增加而降低
- 团队可商定约束估算只用一些预定的值
- 速率
- 一份团队在一轮迭代中完成（或期望完成）的故事点数
- 初始速率的获得方法
- 使用历史值
- 执行一轮初始迭代，使用那轮迭代的速率
- 猜测
- 发布计划
- 问题
- 我们想在什么时候发布？
- 每个故事的优先级是什么？
- 排列优先级
- 莫斯科（MoSCoW）规则——DSDM
- Must have（必须有的）
- 系统的基本功能
- Should have（应该有的）
- 很重要但短期内有替代解决方法的功能
- Could have（可以有的）
- 如果没有时间就可以在发布中不予考虑的功能
- Won’t have this time（这次不会有）
- 客户期望拥有但同时承认需要在后续发布中实现的功能
- 成本改变优先级
- 根据架构需要安排优先级
- 预计工期
- 迭代数=估算理想日/速率
- 迭代计划
- WHAT
- 调整故事优先级的最佳时机
- 是发布计划的进一步计划
- 只在迭代即将开始时才做
- HOW
- 讨论故事
- 分解任务
- 承担职责
- 估算并确认
- 测量并监控速率
- 测量速率
- 计划速率和实际速率
- 速率图
- 累计故事点图
- 可以看出每轮迭代中完成的故事点
- 燃尽图
- 迭代燃尽图
- 展示了用完成的故事点表示的进度和剩余故事的改变
- 项目燃尽图
- 每日燃尽图
- 展示了迭代中每天剩余的小时数
- 敏捷过程
- Scrum
- 迭代递增的软件过程
- 一轮迭代的过程是一种持续改进的过程
- 一轮迭代的工作往往不需要返工
- 一个递增的软件过程是指团队按照功能点开发和发布软件
- 功能点——功能增量
- 30天为周期的迭代——Sprint
- 产品Backlog
- 所有待开发产品的功能列表
- 优先级已排好
- Sprint Backlog
- 一个团队承诺在当前Sprint完成的任务列表
- Sprint计划会议
- 在每个Sprint开始前持续一整天的会议
- 参与人员包括产品负责人、ScrumMaster和团队所有开发人员，其他管理人员和客户代表也可以参加
- Sprint评审会议
- 每个Sprint都要发布一个“潜在可以交付的产品功能增量”
- 结束时演示所完成的功能
- 每日Scrum简会
- 三个问题
- 我昨天完成了什么
- 今天我要做什么
- 我碰到了哪些问题
- 使用用户故事
- 首先确定用户角色，根据角色来收集故事
- 劣势
- 很大程度上忽略用户界面的设计问题
- 基于故事的敏捷版以使用为中心设计
- 用户角色建模
- 捕捞高层次的用户故事
- 排列故事优先级
- 精炼高优先级和中等优先级的故事
- 对故事整理分组
- 建立书面的原型
- 精炼该原型
- 开始编程
