用户故事:这个User Story要拆吗?怎么拆?

发布时间:2018-11-16

本文转自:小婧

什么是User Story其实我觉得要对User Story做一个定义还是挺难的。

曾经的我以为,所谓User Story是User来讲述的Story。

你看啊,User Story的编写范式:

As a role, I want to do something or a piece of functionality, so that I can achieve some business value or statement of intent. 

但是,随着真正的实践,我发现,User总是一个缺席的定义者。

我们指望User来定义User Story,而大部分情况下是由我们这群BA来定义的。

我曾经和一名敏捷教练讨论,我们BA总是在臆想用户的需要而写User Story,这样有意义吗?

这名来自美国的副总裁回答我说,至少你们从用户的角度来思考了,不是吗?

1.jpg

不过,并没有解答我的疑问,我也相信有很多人和我有同样的问题:User Story到底是从哪里来的?谁来写?

也有很多人认为需求提出方应该来写User Story,至少也应该来确认User Story是否恰当。

但实际情况是,很多时候我们真的只能靠想象,充分利用我们的“同理心”来想象。

我翻了一下BABOK中对于User Story的定义:

A user story represents a small, concise statement of functionality or quality needed to deliver value to a specific stakeholder.

——《BABOK 3.0》

这样看来,User Story只是用来描述可以带给User的价值的功能或质量需求,而非必须由User提供。

后面这段描述更加明确的指出了这点:

With a focus on stakeholder value, user stories invite exploration of the requirements by promoting additional conversations with stakeholders and grouping functional requirements for delivery.

——《BABOK 3.0》

这里,我们暂停一下,敲个黑板:价值。

User Story是强调给用户带来价值的。

OK,我们继续。

广为人知的拆分原则User Story写起来并不复杂,但是从敏捷的小步快走的角度出发,大部分的User Story是需要进行拆分的。

而各种敏捷著作中都有写明 User Story拆分的INVEST原则:

Independent:独立性User Story必须高内聚,也就是拥有独立性,不依赖于其他User Story的实现而实现。

如果你将一个User Story拆成前台和后台,那肯定不符合这个原则,因为这两个Story的依赖性非常高。

Negotiable:可协商User Story并不应该是一个人的一言堂。

之前有个小伙伴问我,是不是应该由BA来写User Story。我说,BA提供的是初稿,最终稿需要让团队所有相关人员达成一致。

Valuable:有价值再次敲黑板,价值!

价值是User Story的关键所在,这个Story如果对用户是没有价值的,那就需要重新拆分或者重写。

Estimable:可评估在之前的Scrum文中,其实我提到了关于User Story的Point评估问题。

我们必须保证User Story的可评估,因为User Story是所有实现的基础,我们需要根据评估的结果进行计划、追踪和回顾。

Small:足够小这个原则也决定了User Story要拆得足够小,至于要拆多小,这个我个人觉得应该由团队协商一致,至少也应该是在一个Sprint可以完成的程度。

我在之前的团队里,当评估的点数大于3的时候,我们就一定要拆。

因为根据我们以往的经验,5点及以上的User Story会导致我们的Sprint失败,非常可能做不完或者测不完。

而拆分的过程也是一个再次思考和讨论的过程,大家很有可能会发现之前被隐藏和遗漏的地方。

Testable:可测试为用户带来价值的User Story必须是可以测试的。

请反复读一下我上面这句话。

之所以称以上原则为“广为人知”是因为大家都知道拆User Story的时候要遵循这些原则,但是依旧不知道要怎么拆。

怎么拆都怪怪的?还记得我上面敲黑板的两个字吗?

价值

所有User Story的拆分都要以价值为导向,在拆完后也需要通过“这个小的User Story有给用户带来业务价值吗?”来校验是否拆的合适。

这么说可能有点抽象。我来举个例子。

有这么个图书馆借阅系统的User Story:作为一个用户,我希望可以找到满足条件的书籍信息,以便我可以在书架上找到它。

这个User Story有点大,好吧,不是有点大,是非常大。

如果你拿这个User Story去和大家讨论,会面临以下问题的解答:

•这个用户是注册用户,还是访问用户?

•不同类型的用户操作是一样的吗?

•所谓的“满足条件”指的是哪些条件?书名?作者?ISBN……

•要展示的书籍信息包括什么?书名?索书号?馆藏状态?

……

于是大家讨论了下,决定要拆。那这个User Story给你,你怎么拆呢?

以下是一种拆法,拆成两个User Story:

第一个:建立图书信息表,里面包括书籍的各种属性。

第二个:按照原型,画三个前台界面,包括:搜索界面和搜索结果界面,以及图书信息展示界面。

还嫌大?

那我就把第二个拆成三个,每个界面一个User Story,够小了吧?

2.jpg

有没有觉得哪里不对劲?

有人说,因为没有按照User Story的格式来写,没有写:作为一个用户,我希望可以查看搜索界面,这样我就可以开始准备搜索了。

更奇怪了,是吧?

来,想一下,这些被拆出来的Story对用户来说有业务价值吗?

你提供一个前台页面给用户,不能搜索,只能看,是准备打印出来挂到美术馆里面“供人瞻仰”去吗?

3.jpg

那么应该怎么拆呢?

我这里提供一个思路,大家可以揣摩一下。

大的User Story: 

作为一个用户,我希望可以找到满足条件的书籍信息,以便我可以在书架上找到它。

第一个 User Story:

作为一个用户,我希望可以通过图书名称找到图书的书名、作者、馆藏状态以及索书号信息,以便我可以在书架上找到它。

第二个 User Story:

作为一个用户,我希望可以通过图书作者找到图书的书名、作者、馆藏状态以及索书号信息,以便我可以在书架上找到它。

或者这么拆:

大的User Story: 

作为一个用户,我希望可以找到满足条件的书籍信息,以便我可以在书架上找到它。

第一个 User Story:

作为一个用户,我希望可以通过图书名称找到图书的书名以及索书号信息,以便我可以在书架上找到它。

第二个 User Story:

作为一个用户,我希望可以通过图书作者找到图书的书名、作者、馆藏状态以及索书号信息,以便我可以在书架上找到它。

有感觉到什么吗?

嗯,这样就万事大吉了嘛?

我只能说,图样图森破……

因为这里还有一个延伸的问题,就是程序猿GG看到这样的User Story拆分,很想打人。

为什么?

因为在代码实现的时候,其实在做第一个User Story的时候,可以“顺手”把第二个User Story的逻辑实现了。

而如果不顺手实现,那么意味着在做第二个User Story的时候会需要改才交付完成的第一个User Story的代码。

就好像我们装修房子。

4.jpg

之前的拆分方法是:水电进场开工、瓦工进场开工、木工进场开工、漆工进场开工、家具及软装进场。

而我后面的两种拆分方法是:先把客厅的水电、地砖、墙面、家具软装都搞定后,再来依照这个顺序搞一遍卫生间,再搞一遍卧室……

但是,看出差别了嘛?

前面的拆分方法一个工种干完,下一个接着干,只有当所有的都干完了,房子才能交付。

而后面的拆分方法至少保证第一个User Story可以交付一个完整的客厅给用户,这对用户来说是有价值的。

这也是敏捷的奥义所在。

但是,工人们肯定不乐意了,我水管先铺一段到客厅的,后面我还要把铺到客厅的一部分拆了再铺到卫生间去……

哈,也从另外一面说明了敏捷方法明显不适合工程装修。

那么你要怎么说服大家接受User Story的价值导向的拆分方式呢?

关键在于,敏捷的另外一项重要工作:重构。敏捷的开发过程其实很强调重构、自动构建等等。所以,这也是为什么我一直觉得敏捷的框架和流程是一个完整的体系。你不能抛开重构谈User Story拆分,你也不能无视价值来写User Story。

5.jpg

我大概花了两三年的时间才摸索出来写和拆User Story的感觉,当然这和业务熟悉程度也有一定的关系。

我想要说的是,想要拆好User Story是需要自己不断的去摸索的过程,没有办法说我今天看了一篇文章或者听了一堂课,我就能把User Story写好、拆好了。

重点是要亲自动手去拆,去写,去试错。

说了这么多,你在拆User Story的时候遇到了什么问题?

这篇文可以解答你的问题吗?


Copyright © 2020 All Rights Reseverd Designed by 5thspace.net      备案号:沪ICP备15017019号-1