商业分析BA:用户故事怎么拆?

什么是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,这样有意义吗?
这名来自美国的副总裁回答我说,至少你们从用户的角度来思考了,不是吗?
不过,并没有解答我的疑问,我也相信有很多人和我有同样的问题: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,够小了吧?
有没有觉得哪里不对劲?
有人说,因为没有按照User Story的格式来写,没有写:作为一个用户,我希望可以查看搜索界面,这样我就可以开始准备搜索了。
更奇怪了,是吧?
来,想一下,这些被拆出来的Story对用户来说有业务价值吗?
你提供一个前台页面给用户,不能搜索,只能看,是准备打印出来挂到美术馆里面“供人瞻仰”去吗?
那么应该怎么拆呢?
我这里提供一个思路,大家可以揣摩一下。
大的User Story:
作为一个用户,我希望可以找到满足条件的书籍信息,以便我可以在书架上找到它。
第一个 User Story:
作为一个用户,我希望可以通过图书名称找到图书的书名、作者、馆藏状态以及索书号信息,以便我可以在书架上找到它。
第二个 User Story:
作为一个用户,我希望可以通过图书作者找到图书的书名、作者、馆藏状态以及索书号信息,以便我可以在书架上找到它。
或者这么拆:
大的User Story:
作为一个用户,我希望可以找到满足条件的书籍信息,以便我可以在书架上找到它。
第一个 User Story:
作为一个用户,我希望可以通过图书名称找到图书的书名以及索书号信息,以便我可以在书架上找到它。
第二个 User Story:
作为一个用户,我希望可以通过图书作者找到图书的书名、作者、馆藏状态以及索书号信息,以便我可以在书架上找到它。
有感觉到什么吗?
嗯,这样就万事大吉了嘛?
我只能说,图样图森破……
因为这里还有一个延伸的问题,就是程序猿GG看到这样的User Story拆分,很想打人。
为什么?
因为在代码实现的时候,其实在做第一个User Story的时候,可以“顺手”把第二个User Story的逻辑实现了。
而如果不顺手实现,那么意味着在做第二个User Story的时候会需要改才交付完成的第一个User Story的代码。
就好像我们装修房子。
之前的拆分方法是:水电进场开工、瓦工进场开工、木工进场开工、漆工进场开工、家具及软装进场。
而我后面的两种拆分方法是:先把客厅的水电、地砖、墙面、家具软装都搞定后,再来依照这个顺序搞一遍卫生间,再搞一遍卧室……
但是,看出差别了嘛?
前面的拆分方法一个工种干完,下一个接着干,只有当所有的都干完了,房子才能交付。
而后面的拆分方法至少保证第一个User Story可以交付一个完整的客厅给用户,这对用户来说是有价值的。
这也是敏捷的奥义所在。
但是,工人们肯定不乐意了,我水管先铺一段到客厅的,后面我还要把铺到客厅的一部分拆了再铺到卫生间去……
哈,也从另外一面说明了敏捷方法明显不适合工程装修。
那么你要怎么说服大家接受User Story的价值导向的拆分方式呢?
关键在于,敏捷的另外一项重要工作:重构。敏捷的开发过程其实很强调重构、自动构建等等。所以,这也是为什么我一直觉得敏捷的框架和流程是一个完整的体系。你不能抛开重构谈User Story拆分,你也不能无视价值来写User Story。
我大概花了两三年的时间才摸索出来写和拆User Story的感觉,当然这和业务熟悉程度也有一定的关系。
我想要说的是,想要拆好User Story是需要自己不断的去摸索的过程,没有办法说我今天看了一篇文章或者听了一堂课,我就能把User Story写好、拆好了。
重点是要亲自动手去拆,去写,去试错。
说了这么多,你在拆User Story的时候遇到了什么问题?
这篇文可以解答你的问题吗?

posted @ 2019-10-13 15:14 互联网民工 阅读(...) 评论(...) 编辑 收藏