软件开发-用户故事

• 三个主要阶段
• 定义内容
• 两种类型
• Story cards: Agile开发相关
• 接受度测试Acceptance Tests
• 其他信息
• Scrum
• 原则Principles
• 概念
• 角色
• 回顾review
• 故事&故事思维
• 产品中的故事思维
• 构建故事
• User Story 如何写
• 传统需求分析：
• 互联网发展的现状：
• 什么是用户故事：
• 为什么要写用户故事：
• 用户故事的三个原则（3C）;
• 用户故事的结构：
• 在做一个user story之前需要简单的对自己提问：
• 验收的条件则是：
• 验收标准的一个简单的例子：
• 户故事的负责人（3W）：
• 用户故事的拆分：
• 用户故事的INVEST原则：
• Ending 完整的story生命周期
• 用户Story—基本要素
• 常见的Story模板

*软件开发(Software Development Processes)：User Story Scrum **

三个主要阶段

• Concept 概念
• Implementation 实现
• Maintenance 维护

定义内容

• A set of tasks that need to be performed 需要完成的一系列任务
• Input & output from each task 每个任务的输入和输出
• Preconditions and Postconditions for each tasks 每个任务的前置条件和后置条件
• Sequence and flow of these tasks 任务的顺序和流程

两种类型

• Plan Driven：

  所有进程都事先计划好，用计划来评定进度

• Agile：

  计划是增量的(incremental)，方便改变开发进程，以反映用户需求的改变

Story cards: Agile开发相关

• 我们想要一个轻量的方法来把我们的目标系统的功能块变成文档。
• 然后在sprint的不同迭代(iteration)中完成不同story的不同部分。

A defination of a piece of functionality from an end-user perspective. 也包含一些管理信息：priority，cost(时间相关的单位)

接受度测试Acceptance Tests

• Story cards的背面：可以在产品上做的测试，以检查这张卡要求的内容是否完成.(一张卡需要多个测试)。

其他信息

• 产品或者产品部件的名称/ID
• Story name
• 风险：任何可能影响story的完成或者提高成本的问题
• 笔记Notes：在完成一个story过程中的开发者工程笔记

Scrum

• 一个敏捷开发的框架(framework)。用于用一种增量的方式管理复杂的软件开发工作。

原则Principles

• 用户用product story/user story来定义他们在系统中想要的东西。
• User story不需要在一开始就很完整。
• 开发过程是迭代的(iterative)，被分为很多个sprint(冲刺)
• 每个sprint都会处理user story的一个子集的问题。
• 一个story可能不能被一个sprint完成，则需要多个sprints
• 在每个sprint的结尾，整个队伍要整个sprint的进度
• 整个队伍要时常回顾进度(比如每天)，每个小会议都成为一个Scrum
• 各个时间段都有可能加入新的story

Sprint Planning –> Implementation(daily scrum) –> Sprint Review –> Sprint Retrospect(回顾) –> …(loop)—> Deployment

概念

• Project back-log：整个project所有user story的完整列表
• Sprint：一个有固定的时间框架的开发周期(2-4周)
• Sprint Back-log: 分配给一个Sprint的user stories
• Sprint Team：在一个sprint中处理一组user stories的一个开发小组
• Scrum：Sprint小组中频繁举行的会议。用于跟进进度。已经完成了什么？接下来做什么？有哪些阻碍？
• Sprint Review：在Sprint的结尾，回顾已完成的哪些story
• Sprint Retrospective：在Sprint的结尾，总结一下遇到过哪些问题

角色

• Product Owner
  • 负责维护Project Backlog
  • 负责写User stories
  • 设置story的优先级，将story分配给各个sprint
• Scrum Master
  • 组织、主持Scrum会议
  • 促进队伍中问题的解决

回顾review

每个Sprint结束后都要进行回顾，评估工作的完成情况。

• Sprint review

  • Product Owner列出已经完成的工作
  • 团队讨论：是否成功？有什么问题？问题是如何解决的？
  • 展示现有的产品
  • Product Owner对backlog进行总结
  • 分配下一个Sprint的Stories

• Sprint Retrospective

  • 是一种比review更高等级的总结评定！关键在于寻找可以提升开发效率的战略性改变。例如：重新分配团队中的角色，改变优先级，增加和移除stories，等等

故事&故事思维

故事是一种信息的传递方式，在形式上强调生动性、连贯性，真实性（至少听起来真实），能引起情感共鸣；内容上故事本身具有其主基调，每个情节之间能够环环相扣，具备吸引人的关键词等。故事，由于其本身固有得特点，在信息传递过程中有交互、有场景、有情节，容易引起故事听众的共鸣，可以让人更好地记忆内容，也使得内容可以更快更广泛地传播。故事思维，是运用故事的元素进行思考和设计，以求解决某种问题，达到特定处事效果的思维。

产品中的故事思维

什么是产品中的故事思维呢？

就是将故事思维运用在产品的需求收集、创新、设计、改进，帮助我们在做产品的过程中看清用户使用产品的现状是什么，了解用户在使用现有产品遇到什么困难，解决用户现有场景不能被满足的需求我们的解决方案是什么，以及描述产品以后会是什么样子，能解决用户什么问题，为用户带来什么价值。

构建故事

构建故事，我们需要有故事应该具备的基本要素。

• 可信的环境（时间、地点）
• 可信的角色（谁、为什么）
• 流畅的情节（是什么、怎么样）

环境、角色、情节是构建一个故事的基本要素，前面加上定语是因为一个成型的故事必须是生动、连贯以及可信的。虽然大多数故事都是经过了一些渲染和包装，但是一个故事需要打动别人，必须具备真实性，即使不是真实发生的，但至少听起来真实。

User Story 如何写

传统需求分析：

• 时间：需求分析两个月，开发三个月
• 出现的问题：有些功能没有人使用，有些功能做错了/不要用，频繁变更，走向更大批量
• 原因：没有抓住用户/客户核心需求，优先级不正确，大批量

互联网发展的现状：

• 不确定性增大
• 市场变化快

什么是用户故事：

• 用户故事是简要的意向性描述，它描述系统需要为用户做的事情以及对用户的价值
• 迭代式开发的工具
• 代表了可开发的一个工作单元
• 帮助跟踪一个功能的生命周期
• 引起对话的载体/占位符

为什么要写用户故事：

• 1. 更早的提交产品来满足需求
• 1. 消除软件开发过程中的浪费
• 1. 团队更关注用户需求价值
• 1. 加强团队的沟通，减少信息传递的失真

用户故事的三个原则（3C）;

1. card：写在一个卡片上，用这个卡片与开发团队进行对话
   • 务价值的reminder
   • 做计划和沟通的token
   • 卡片的两个部分：作为<用户角色>想要<完成活动>实现<价值>；验收标准****
2. conversation：用于在计划或估值时引发关于故事细节的对话
   • 用于在计划或估值时引发关于用户细节的对话
3. confirmation：将细节以验收测试的方式来确认故事的完整性和正确性

用户故事的结构：

>> TitleDescription作为 （As a）“某类利益相关者”我想要（I want）“目标系统提供的行为或功能”以便（So that）”实现某种业务价值或目标”Narrative – 业务背景/工作流程Acceptance Criteria – 验收标准Mock Up – 原型图其他有帮助的内容

在做一个user story之前需要简单的对自己提问：

1. 如果没有这个故事
2. 谁会不高兴
3. 谁的利益会受损
4. 什么样的利益会受损
5. 如果存在其它方法
6. 为什么不用其他方法
7. 能不能够只做一部分
8. 能的话是哪一部分，为什么

验收的条件则是：

• Gievn （在什么样的情景或条件下）
• When（做了什么操作，采取了什么行为）
• Then（得到了什么结果）

验收标准的一个简单的例子：

• Gievn：当邮件的发送者在邮件书面写完了邮件主体（没有加粗）
• When：选中其中的几个文字，点击加粗按钮
• Then：选中的文字粗体显示

户故事的负责人（3W）：

• who谁写： 产品负责人/PO 客户/用户
• Where 在哪里些 故事卡片 工具
• When 得到需求后 需求探索的过程中

用户故事的拆分：

• 主题 Themes
• 特性 Feature
• 需求集 Epic
• 用户故事 User Story

用户故事的INVEST原则：

I：independent 独立性，各自完整，独立于其他用户故事

N：Negotiable 可协商，总是可以被替换和重写，直到成为迭代的一个部分

V：Valuable 有价值，一定要能对最终用户或商业有价值

E：Estimable 可估值，参考其他故事，功能点的大小可以被评估

Scalable：大小合适，小于一个迭代

Testable：可测试，提供可被验证的必要信息，证明它有用

Ending 完整的story生命周期

用户Story—基本要素

写用户Story的时候我们需要围绕三个基本要素来写。用户（角色）、需求（目的）、原因（好处）三点。通过一定的需要修饰就组成了我们常见的Story语句。

常见的Story模板

• 一、我是（角色），我希望（功能），这样（好处）。
• 二、作为（角色），我想要（商业价值），以便（原因）。
• 三、作为（角色），我想（目标），以便（某种原因）。

在写Story的时候我们需要尽可能的保持刚刚好的详细，让用户Story有”笔直性”。避免增加过多的细节要求，让Story变得复杂。