论坛首页 综合技术论坛

User Story Q&A

浏览 5524 次
锁定老帖子 主题:User Story Q&A
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2011-04-15   最后修改:2011-04-17

1. 什么是用户故事?
用户故事描述了对用户或客户有价值的功能。用户故事由以下三方面组成(3C):

  • 一份书面的故事描述,用来做计划和作为提示(Card)。
  • 有关故事的对话,用于具体化故事细节(Conversation)。
  • 测试,用于表达和编档故事细节且可用于确定故事何时完成(Confirmation)。

可以用故事卡来记录用户故事,在故事卡的正面记录故事的简短描述,背面则记录测试要点。

2. 什么是优秀的用户故事?
优秀的用户故事应该具备以下6个特点(INVEST):

  • 独立的(Independent)。
  • 可讨论的(Negotiable)。
  • 对用户或客户有价值的(Valuable to users or customers)。
  • 可估计的(Estimatable)。
  • 小的(Small)。
  • 可测试的(Testable)。

3. 为什么使用用户故事?
使用用户故事能够带来下面好处:

  • 用户故事强调口头沟通。可以提供迅速的反馈周期,能够促成对需求的充分理解。
  • 用户故事更容易被人理解。
  • 用户故事的大小适合做计划。
  • 用户故事适合于迭代开发。可以很容易的从一个史诗故事入手,并在需要的时候将其分解成多个小故事。
  • 用户故事鼓励延迟细节。可以很快的写出大量用户故事,迅速的开展工作。
  • 用户故事鼓励随机应变的设计。团队能迅速的在高层及低层细节思考间切换。
  • 用户故事鼓励参与性设计。
  • 用户故事有利于传播隐性知识。

4. 用户故事有哪些不足?

  • 大型项目中,用户故事之间的关系可能错综复杂,难以组织好成千上万的用户故事。
  • 如果开发过程规定要有需求的可追溯性,需要额外的文档。
  • 在特大规模多团队的项目中,仅靠用户故事是不够的,不然难以保证信息在大型团队中充分共享。

要点:

  • 可以考虑使用其它补充需求说明或使用用例。

5. 怎样开始编写用户故事?
首先从识别关键用户角色开始。按以下步骤对用户角色建模(角色卡):

  • 通过头脑风暴,列出初始的用户角色集合。
  • 整理最初的用户角色集合,表明角色之间的关系。
  • 整合角色,合并完全重叠的角色,丢弃多余的和不太重要的角色。
  • 提炼角色,定义角色的特征,以便更清楚的了解不同角色的差异。

要点:

  • 用户角色代表的是单一用户。
  • 用户角色定义的是人,而不是其它外部系统。

6. 怎样发现和收集用户故事?
以下2种方法有助于发现和收集用户故事:

  • 用户访谈。
  • 故事编写研讨会(头脑风暴,简单原型)。

要点:

  • 使用开放式的,背景无关的提问。
  • 应该把重点放在故事的数量上而不是质量上。

7. 当不能或很难接触实际用户时该怎么办?
以下方法有助于解决问题:

  • 组建由用户代理领导的用户顾问团队(业务分析师和领域专家是较好的用户代理人选)。
  • 尽早的频繁的发布产品,以便尽快得到用户的真实反馈。

8. 怎样描述用户故事?
可以使用下面的格式描述用户故事:
作为一个(角色),我想要(功能),以便于(商业价值)

9. 怎样处理非功能需求?
使用约束卡片,如果需要也可以使用其它形式的补充需求说明。

10. 怎样估算用户故事?
用故事点估算方法估算故事。

要点:

  • 估算用户故事工作量的相对大小。
  • 团队估算

11. 怎样安排故事的优先级?
故事的客户价值和风险是安排故事优先级要考虑的重要因素。

12. 怎样将用户故事分配到发布计划?
按以下步骤分配用户故事到发布计划:

  • 确定客户预期的大致发布日期。
  • 确定迭代长度(一般2-4周)。
  • 估算用户故事(故事点估算)。
  • 估算团队初始速率(每个迭代完成的故事点)。
  • 安排故事优先级(按客户价值和风险等因素)。
  • 按故事优先级,故事点,团队速率分配故事到每轮迭代。

13. 怎样将用户故事分解为多个任务?
以下3方面是分解任务时要考虑的重要因素:

  • 有利于估算。
  • 有利于协作分工。
  • 有利于跟踪完成情况。

14. 怎样将任务分配到迭代计划?
按以下步骤分配任务到迭代计划:

  • 将用户故事分解为多个任务。
  • 团队成员认领任务。
  • 团队成员估算并确认他们自己的任务。

要点:

  • 团队分解任务
  • 个人估算任务(按小时)

15. 当用户界面设计不适合频繁变更时怎么办?
可以按下面步骤实现以使用为中心的设计:

  • 用户角色建模。
  • 捕获高层次的用户故事。
  • 排列故事优先级。
  • 精炼高优先级和中等优先级的故事。
  • 对故事整理分组。
  • 建立书面的原型。
  • 精炼该原型。
  • 开始编程。

16. 怎样基于用户故事监控团队速率和完成情况?
以下4种方法有助于监控速率和完成情况:

  • 速率图,用于展现每轮迭代的速率(每轮迭代完成故事点),以便于监测实际速率和计划速率的偏差。
  • 累计完成故事点图,用于展现每轮迭代完成的故事点,以便于监测累计的实际完成故事点和计划完成故事点的偏差。
  • 迭代燃尽图(发布燃尽图),用于展现每轮迭代末剩余的故事点,以便于把握项目整体的进展情况。
  • 每日燃尽图(Sprint燃尽图),用于展现一轮迭代中每日剩余工作的小时数,以便于把握每轮迭代的进展情况。
   发表时间:2011-04-18  
iPhone不能进行迭代开发:),因为用户看到了就会导致商业泄密,致使大量跟进者模仿。

上面说的“对于大型项目story的缺点”,还是比较中肯的,story最大缺点是没有逻辑性。用户一般很难有足够的耐性帮我们一个个澄清story和异常分支。
真正保证完整设计的,还是有经验的设计人员。

最重要的还是人:)
0 请登录后投票
论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics