User Story Lecture

社招-training

让大家走出去看看项目上的Story是怎么写的

1.Story 是什么

• A tool for iterative development
• Represents a unit of work that should be developed
• Help track that piece of functionality;s lifecycle
• It is a token for a conversation , a placeholder for a conversation

2.Story作用：

• 用于需求描述
• 促进共同理解

3.Story Card

• A conversation placeholder, not a detailed requirements document
• Designs may be needed for a story before it is ready for development
• Focus on the user,their goals and the value they seek

• Mock ups are a low-fi sketch that convey story concept and prompt early feedback

• NARRATIVE: Describes the purpose of a story:

  As a <user>
  I want <goal>
  So that

• ACCEPTANCE CRITERIA: describe the requirements to complete a card:

    Given <pre-condition>
    When <trigger>
    That <outcome>

• Structure
  

4.Story 怎么写



a.3C原则



b.INVEST原则

• Independent：每个用户故事应该是独立的，不会和其他用户故事产生耦合
• Negotiable：并不会非常明确的阐述功能，细节应带到开发阶段跟程序员、客户来共同商议
• Valuable：每一个用户故事的交付都要能够给用户带来用户价值
• Estimable：不需要能够准确的估计，但需要能辅助客户排定优先级
• Small：要小一点，但不是越小越好，要大小合适，可以更容易的圈定故事范围
• Testable：需要能够进行验收测试，最好能把Test Case提前加进去

c.准备

• 开始写共识之前，先完成用户体验地图和人物形象构建是很有用的。从产品草图开始也一样。
• 做准备时，确保准备好卡片、马克笔、和大面的墙以及排卡片时需要的大桌子
• 确保产品负责人和团队都参与写故事，对于大型团队，考虑组成小队，并分别专注于用户体验的不同部分
  
  
  对于API卡，两点建议
  
  1. 从User Story描写的角度，“As a ” 这个User可以是一个Persona，也可以是第三方的系统。比如说“As
     e-Comm Digital web app, I want to call Customer API to retrieve customer
     details”.
  2. 最适合用GIVEN WHEN THEN的方式来定义AC。
     GIVEN a customer exists
     WHEN a GET request of Customer API is made
     THEN Customer Name, Contact Details, Product Details are returned in the
     response.
     同样，可以Spec by Example，把具体的request 和 response给举例说明列出来。

5.Story Check:

• Simple to understand
• Testable
• Estimable
• Has Business Value
• Can be aimed in an iteration (timebox)
• Understandable by the user

6.Story 如何拆分：

20/80原则
锤子切分

7.Story 如何划分优先级






8.Story 估算

• 相对估算： 远光灯-大灯-近光灯
  
  

9.Story 非功能性需求




10.Story 交付管理






什么是好的Story

几个反模式。
* 按照技术架构分层进行拆分，常见的会按照持久层、应用层、展示层进行拆分。这种拆分方式拆出来的用户故事，会明显破坏INVEST中的Valuable的原则，而且各个故事卡由于各方面的原因，如开发进度不统一，无法灵活的集成上线。
* 拆分时，把复杂的UI交互算在故事卡片中。大部分情况下，比较fancy的UI交互都不是核心的业务功能，这部分功能可以作为用户体验优化的卡片，独立拆出来。
* 拆分时，过早考虑性能问题。在性能基本达标、不出现大问题的情况下，提升性能很多情况下也属于用户体验的一部分，可以单独拆出来，左右优化卡片。
* 拆出一些管理类的卡片。比如管理产品，实际上可能包含很多产品相关的操作，如导入、编辑、同步信息、改变状态、上架、下架等，所以应该根据具体的功能，拆分成更为准确和大小合适的故事卡片。