用户故事和敏捷方法

少于 1 分钟读完

概览

什么是用户故事?

用户故事描述了对用户、系统或软件购买者有价值的功能。用户故事由以下三方面组成:

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

使用故事的过程

  • 由客户团队(用户、产品经理)而不是开发人员来编写用户故事,因为客户团队是产品的构想者,可以排列优先级
  • 确定迭代长度:一般是1-4周的时间
  • 预估迭代速率:迭代速率是指每轮迭代可以做多少事情。第一次预估可能是错误的,每迭代结束后可以知道开发团队的实际速率,可以用该速率来决定下一次迭代速率,从而调整迭代内容。

规划发布和迭代

对于故事优先级,开发团队和客户团队的意见相左怎么办?

应该互相倾听观点,但最终应坚持客户组织利益最大化原则

故事点

排列故事优先级需要考虑成本,故事成本由开发者给出,每个故事用故事点来估计,故事点表明一个故事相对于其他故事的大小和复杂度(类似复杂度点数)。

故事及其成本

故事 故事点数      
故事A 3      
故事B 5      
故事C 5      
故事D 3      
故事E 1      
故事F 8      
故事G 5      
故事H 5      
故事I 5      
故事G 2      

用户故事发布计划

迭代 故事 故事点数
迭代1 A、B、C 13
迭代2 D、E、F 12
迭代3 G、H、J 12
迭代4 I 5

用户故事的特点

  • 强调对话交流而不是书面沟通
  • 产品和开发都可以理解
  • 故事的大小适合做计划,适合迭代开发
  • 鼓励推迟考虑细节,直到你非常清楚的了解真正需求

如何编写故事

一个优秀的故事应该具备以下特征:

  1. 独立的:尽量避免故事间的互相依赖,可以通过将互相依赖的故事合并成一个大的故事。
  2. 可讨论的:故事是可讨论的,不是签署好的合同或者软件必须实现的需求,细节在开发团队和客户团队的讨论中产生。
  3. 对用户或者客户是有价值的:最好是让客户来编写故事。
  4. 可估计的:将不可估计的故事变成两个故事,一个快速的探针故事(用来获取足够的信息)和一个故事(真正实现的功能)。
  5. 小的:合适的故事大小最终取决于团队规模以及所使用的技术。对于太小的故事(比如用户界面变更),可以考虑合并到其他的故事里。
  6. 可测试的:通过测试可以证明开发人员正确的实现了故事。

故事是用来提醒开发和客户交谈,而不是记录详细的需求定义。

搜集故事

这个章节的有个理论是颇有意思的,搜集故事就是获取用户的真实需求,要像“拖网渔船捕捞鱼”那样来收集需求,第一遍先用大眼渔网捕获大鱼,也就是大的需求,之后再捕获中等大小的鱼,暂时可以放过小鱼,鱼的大小用来比喻该需求对该软件的商业价值或必要性程度。在捕捞需求的时候也会捕获一些废弃物或者残骸,这些是我们在每一轮的迭代中需要丢弃的。

搜集需求通常有以下几种方式:

  • 用户访谈。这里比较重要的一点是不要只询问用户“你需要什么”是不够的,大部分用户不太善于理解,也难以表达他们的真实需求。需要使用非常具体的问题,最好是从背景无关的问题开始提问。
  • 问卷调查
  • 观察:观察用户实际使用软件的情况。
  • 故事编写工作坊:开发人员、用户、产品和其他对编写故事有帮助的人共同参加的会议。参与人员编写尽可能多的故事,此时不对故事排优先级,以后客户有机会来排优先级。

与用户代理合作

与真实用户一起合作对项目的成功至关重要,但是我们通常很难有机会与真实用户一起工作,此时用户代理就很重要,他们自己可能不是用户,但他们在项目里面代表着用户。

书里提到过让销售人员充当用户代理是危险的,对于他们来说,最重要的故事是那些如果没有实现就会导致“丢单”的故事。我在05年的时候加入了一家 SASS 公司,通常来说, ToB 的业务通常都依赖与销售人员的努力,不乏听到过公司的销售人员在“扫楼”的过程中吃闭门羹。我还记得有一次销售总监跑到我的跟前说“这个功能我们要赶紧上线,上线后就可以收钱了”,而结果往往都是事与愿违,销售人员更是为了拿下订单,通常会提前承诺我们将会上线XXX的功能,倒逼开发,开发人员为了不同企业的定制化需求疲于奔命,搞得系统往往臃肿不堪,难以维护。个人觉得在中国做 SASS 很困难,做的都是赔本赚吆喝的事情!正如书中所写,如果一家产品公司过分关注每一笔丢失的订单,他们可能会失去战略方向,产品的长期愿景会停滞不前。

与用户代理一起合作的方法:

  • 使用用户顾问团队
  • 使用多个用户代理
  • 分析竞争产品
  • 尽早发布软件来获取用户反馈

估算用户故事

可以定义一个故事点为一个理想日的工作(理想日代表一天没有任何干扰,没有会议,没有电子邮件,没有电话等等)。用理想日估算会更具优势,一方面可以不用考虑各种干扰因素的影响,一方面可以真实的反映出任务的工作量。

  • 故事估算应该由整个团队集体完成。
  • 程序员估算一个故事时,他们应该考虑完成这个故事所需做的所有事。他们要全盘考虑测试代码,与客户讨论,帮助客户改进或自动化验收测试等诸多因素。
  • 点数需要合理而非绝对精确。
  • 可以用第一轮的迭代速率预测未来的迭代速率,随着团队学到新的技术、新的领域知识或者开始习惯与新成员合作或习惯新的工作方式,迭代速率可能会改变。
  • 故事的估算精度随故事大小增加而降低。

迭代计划

迭代计划会议的内容:

  • 讨论故事
  • 从故事中分解任务
  • 开发人员认领任务
  • 开发人员单独评估任务复杂度,确保其不会做出过于乐观的承诺

开发人员职责:

  • 帮助把所有故事划分为任务,而不是只关心自己想做的事情
  • 为认领的任务承担责任
  • 负责监控自己剩余的工作,同时也要关注同事的工作,如果提前完成了自己的工作,需要主动帮助同事承担一部分工作

测量并监控速率

  • 计算速率只考虑哪些已经完成的故事,不要计算迭代中未全部完成的故事(未全部完成的故事对客户是没有价值的)
  • 不要在一两轮迭代结束后就忙着预测迭代速率
  • 尽量在完成一个故事后再去完成下一个故事

Scrum 和用户故事

Scrum 的主要规则:

  • 在 Sprint 开始的时候召开 Sprint 计划会议
  • 每个 Sprint 必须发布可以工作的、经过测试的代码,这些代码能够完成对最终客户有价值的一些功能
  • 产品负责人为产品 Backlog 排列优先级
  • 团队一起决定一轮迭代可以完成多少个故事
  • 在任何时候都可以向产品 Backlog 中添加故事、或者重新排列优先级
  • 每天有一个 Scrum 短会。每个项目成员回答三个问题:我昨天做了什么?我今天要打算做什么?我有什么困难?
  • 只有团队成员能在每日 Scrum 简会中发言
  • 在 Sprint 结束时的 Sprint 评审会议中,团队会演示完成的成果

标签:

更新时间:

留下评论