开发工具之User Story

结合自己的理解,整理出的User Story笔记。

定义:

软件开发中常用的一个基本工具,用户故事,又称User Story。

wikipedia上是这样定义的:

In software development and product management, a user story is an informal, natural language description of one or more features of a software system.

软件开发中,用来描述一个软件系统单个或多个特性的非正式自然语言。

我的理解是,定下角色,然后从角色的角度出发,理清会做什么事,最后实现了什么样的价值。

Why User Story:

开发中常常遇到如下情况:

  • 不知道如何整理项目需求
  • 不知道如何拆分需要成实际的任务
  • 大概知道要去拆分,但是不知道要描述到多详细
  • 如何才能让大家都能很快读懂,参与协作。

User Story是解决上述情况的一大利器。

格式:

User Story的格式如下:

As a role of user, I want some feature, so that some business value.

身为「某角色」, 会做「某事」, 以完成「某商业价值」

例如:

  • 管理者可以新增职缺
  • 用户可以申请职缺
  • 用户可以浏览详细的工作内容
  • ……

这里,角色正是系统复杂度的关键

撰写的秘诀:

既然工具有用,那么要如何写好User Story?

  • 注意粒度大小,粒度大小很重要

    • 针对不同的受众,颗粒度是不一样的,例如:

    对于投资人/生意人来说,颗粒度就要很大,而针对用户或者客户,则是相对小的size,而针对开发人员,则需要更为小的颗粒。

    • 拆分User Story,就好比切蛋糕,直着切,不是横着切。
      • 不要用技术去切分,而是具体而微,让用户可以体验到一个相对完整,有价值的功能。好比不能单作controller,单作model,或者view,而是结合成一个MVC
      • 要具体切多小呢?有什么标准?
        • 不需要写太多,比如写20条User Stories,就过多了
        • 一条story不是描述中间一个步骤,而是完成一件事情
        • 一个user story大约是半天~数天的实作长度

    比如下图:

  • 可彻底完成的小故事

    是要完成一个小目标,让用户可以彻底完成一个任务,而不是发散,模糊,持续进行的故事。

    例如:管理员可以管理商品,就不是一个好的user story,比较发散,模糊。

    而拆分成:

    • 管理员可以上架商品,字段包括商品名称,价格,说明等
    • 管理员可以编辑上架时间,过期商品自动下架
    • 管理员可以上传多张产品图片

    这才是好的stories

  • 描述功能需求,而不是解决方案

    不要描述技术细节,包括UI规格,技术规格

    只描述对用户有价值的功能

  • 辨识用户角色

    • 包含用户角色,并讲清楚用户可以做的事情
    • 身为「某角色」, 会做「某事」, 以完成「某商业价值」
    • 撰写User Story用主动语态
    • 角色越多,项目整体复杂度会快速上升

收集和排序:

以购物网站示范,将想到的User Story都写在便利贴上,贴在白板上

  • Top-down方式:有明确目标导向

    先列出3~5个主要活动,然后将主要活动拆分成至少3个以上的可执行story

  • Bottom-up方式:创意导向,适合头脑风暴

    将所有user story贴出来,然后按照时间顺序分类,将类似功能的user story放在一组,如下:

    将分组后的活动进行小结,整理成3~5个主要活动。

    排序:

    根据优先级,分出Must have ,Should have , Could have, Nice have,先做must,然后should,could,最后再考虑Nice

参考文章:

Ihower: 什么是User Story