需求不明确?试着讲一讲用户故事吧

发表于:2018-3-14 11:23  作者:miosama   来源:简书

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 需求分析 需求管理 软件测试管理

  「不要从产品开始,从故事开始」。
  需求不明确?
  在项目推进过程中,将需求转化为开发团队可操作的东西是一项非常具有挑战性的任务。很多时候用户或者客户的需求是这样的:
  「我需要一个登录功能」
  「我希望能拉黑别人」
  ……
  但假如向开发者这样提需求,往往会得到这样的回复:「为什么要这样做?这么做的意义是什么?」。仅仅从这些需求来看,由于需求的不完整性,不但难以实现开发,同时也无法成为最终需求验收的标准。
  遇到这种情况,可以试着讲一讲「用户故事」。
  用户故事
  目前用户故事作为需求的基本形态,应用于产品的敏捷开发过程中。用户故事的典型格式是:
  作为 < 用户 >,我想要 < 愿望 >,这样我就可以 < 收益 >。
  我们再回到上面「拉黑」的例子中,按照用户故事的格式,就可以这样对需求进行描述:
  作为 < 社区成员 >,我想要 < 增加一个拉黑的按钮 >,这样我就可以 < 屏蔽那些我不喜欢的用户 >
  很明显可以看出,在一个用户故事中包含如下这几个部分:
  1、角色主体,即谁要使用这个功能
  2、功能,也就是经典格式中的「愿望」,它具体描述了整个需求需要实现的内容。愿望是用户故事的核心
  3、收益,即完成这个需求后能给角色主体带来的价值
  以往我们只关注需求的「功能」,忽视了功能主体和预期用法,而用户故事很好地弥补了这一缺陷,将需求放到实际场景中,有助于避免需求提供者和实际开发者之间的误解。
  怎么写用户故事
  用户故事应该能清晰地体现需求的具体内容和对使用者带来的价值,因此最好的方法是让一线人员,如客户团队或商业团队来描述故事,产品管理者或测试者对故事进行总结和后续的拆分。《用户故事与敏捷方法》一书中提到了用户故事的 INVEST 原则,可以作为用户故事的编写指导。
  独立的(Independent):所讲述的故事应该独立并且完整,相互之间应没有依赖关系。
  比如说一个故事中会使用到微信和支付宝两种支付方式,则「使用微信支付账单」不是一个独立的故事结构,正确的说法应该是「使用支付功能支付账单」。
  可谈判的(Negotiable):需要明确一点,用户故事其实是「讨论需求」,而不是「下达指令」,它需要小组内成员对用户故事的需求讨论达成一致,如果没有,则用户故事是失败的。
  有价值的(Valuable):明确当前需求的价值,为后续迭代做准备
  需注意这里的价值主体为「用户」。比如说技术人员希望对管理后台进行优化,这种优化的价值普通用户是无法感知的,不需要体现在以普通用户为「用户」的故事里。
  可估算的(Estimable):用户故事需要可以被估算,这就要求用户故事不能太大,同时讨论人员需要具备一定的技术知识。
  这里有一点需要明确,有时候用户故事中的需求被驳回,并不是因为需求不合理或无法实现,可能是技术团队目前的技术债没有偿还,因此估算时需要技术人员对当前涉及的技术方案进行评估,综合考虑是立即执行还是对以往技术债修补后再开展,甚至可以单独拉出一个版本进行技术重构,否则会导致技术债越堆越多,反而影响后续迭代。
  小规模的(Small):好的工作故事不能太大,最好能保证在一个迭代内可以完成。如果用户故事过大,则违反了上述可估算性,在后续开发安排上就会有较大风险。
  继续说上面「拉黑」的例子,「需要一个拉黑功能」看起来是一个需求,但其中还有很多细节没有说清楚:
  用户如果不想拉黑对方了,是否可以解除拉黑?
  拉黑有没有期限?
  拉黑之后能不能给对方发消息,如果不能应该怎么提示?
  ……
  以上的这些问题都是所谓的「需求坑」,如果不能很好地进行识别,那这样的用户故事会对后面的讨论或者开发带来很大的障碍,无形中增加了很高的成本。
  可测试的(Testable):用户故事必须清晰地界定验收测试标准。
  比如说「用户觉得很满意」,这是一个较为主观的概念,无法实际进行测试,不应该在用户故事中体现。可以在产品上线后进行满意度问卷调研。
  举个栗子?
  团队之前曾经接过一个需求,要求在应用中实现慢性病智慧医疗场景,覆盖用户从查询就医到后续护理的全流程。团队在讨论的过程中,做了这几件事:
  1、抽取场景中的关键流程
  2、丰富关键流程的分支
  3、抽取出用户故事,并进行拆分
  
部分故事截图
  上图红框部分即为每一个流程节点的用户故事,但需要注意的是,这仍是大粒度的用户故事,需要做进一步的拆分。例如在购药的环节,又将其拆成了以下几个故事:
  
粒度拆解
  如上图,这样就使得用户故事的工作流、业务规则都已经足够详尽。
  最后,当把用户故事抽提出来后,最好团队成员可以对着故事卡片再复述一遍故事,做到对故事和其中的需求充分理解,有一个完整的例子之后就可以开始迭代,避免后续在实现上出现偏差。
上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2020, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道