文章

Scrum_tup2

写好用户故事的10个技巧

用户故事可能是捕获产品功能的最流行的敏捷技术:使用用户故事很容易。但讲出有效的故事可能很难。以下十个技巧可以帮助您创建好的故事。

1. 用户第一

顾名思义,用户故事描述了客户或用户如何使用产品,它从用户的角度进行表达。另外,用户故事特别有助于捕捉特定的功能,例如搜索产品或进行预订。下图说明了用户,故事和产品功能(由圆圈表示)之间的关系。
Read more

scrumcn_userstory

用户故事,史诗故事和主题故事

敏捷团队喜欢以一种刚刚好的方式处理需求。我们采用最低限度地、逐渐细化并保存在产品待办项(Product Backlog)中的特性描述文字,来替代传统长篇大论的需求文档。

我们发现用户故事是最好的描述方式,这种形式能够捕获到特性足够多的信息,并促进产品负责人和团队在后续进一步交流。用户故事是从人(通常是系统的用户或者客户)渴望新功能的视角来对特性进行描述。

用户故事一般会采用以下这种简单格式进行描述:“作为【某类用户】我【想要/能/需要…】以便【满足什么用户价值】”。尽管这种描述格式有其优越性,但只要能围绕着故事进行交流,用户故事可以以任何形式进行描述。
Read more

scrumcn_userstory

要写封闭式的用户故事

在我们编写用户故事或者拆分用户故事的时候,写封闭式的用户故事至关重要。一个封闭式的用户故事意味着这个故事完成后,用户可以达成一个明确的、有意义的目标。我喜欢打这样的一个比方,完成了一个用户故事,用户应该可以停下来休息一会儿,喝杯咖啡了。

下面给一个不是封闭式的用户故事的示例: Read more

scrumcn_userstory

用户故事系列之六:用户故事的产生与组织结构

这是用户故事系列的第六篇。
一条需求敢跳出来,基本上就能被化成一条用户故事,看完一二三四五,上山打老虎都不怕,这个似乎已经不太难了。

难的是,项目或产品的第一天,给一张白纸:“请列出有哪些故事”。那个时候其实不是大脑空空,而是有千言万语就是说不出。

前年做另外一件事情的时候偶然得到一种方法,去年到今年用在一个敏捷项目上,果然很舒服地列出了大量故事,后来的开发过程证实它们都满足独立交付、可测试、耦合低等特点,属于好故事之列。

引子
这件事情其实在之前的博客中已经多次提到了,就是软件项目的造价管理。注意这里提到的是项目,而非产品研发。项目就是那种一手交钱一手交货的甲乙方项目。

之前曾经提到过:无论有多少种方法对优先级进行排序,作为产品而言,都永远应该把最体现差异化价值观的功能置于万事之前。

这里要说的则是:无论有多少管理方法,作为项目而言,都永远应该把造价估算置于万事之前。

这个前不是一般的前,最好能用几张A4纸的篇幅就搞定,因为一般老板刚去签订合同的时候,手里没有需求,没有设计,没有故事,就这么几张纸。当然另一个尴尬的事情则是:即使有很厚的需求文档了,也仍然没有方法知道要多久才能完成项目,真的很愁人。

其实这两件事说的是一件事:如何在早期列出具有某种表征意义的需求列表。

甚早期的用户故事生成方法
在之前的博客详细描述过了,这里只从产生和组织用户故事的角度谈谈,详情请看文末的链接。

在我们的开发工作中一共有两类东西要开发,一种是数据,一种是操作。

所谓数据,就是比如要编写一个CRM,其中有“用户、角色、权限”这三种东西,就是要管理的数据,这里权且记下用户有“3个史诗故事”要管理。

所谓操作,就是对用户,应该有增、删、改、查、加入角色……这些称之为操作,这里权且记下对用户,用户会有“5个用户故事”。

下面是我们的实际项目的局部截图,课本是史诗,蓝色是故事带括号和加号的是两个合并的故事,箭头是增强请参考上篇故事分类:

scrumcn1368088255

史诗都是名词,都是要被管理的核心信息,而且是用户可以理解的信息;

故事都是动词,都是用户平日里使用软件产品所进行的业务操作;

最后一个小贴士是每个史诗故事平均有7个左右的故事,少于4个要怀疑是不是史诗,多于10个要怀疑是不是应该拆分新的史诗了。

最后这条是NESMA 20年来的经验数据,很值得参考但莫较真。比如上面例子分为用户/角色/权限3个史诗对19个故事(平均6.3个),你可以试试再拆拆或合合,效果肯定不如这三个干净。只能说他们20年真没白干。

这个方法听起来很水很模糊,但因为开过几次造价估算培训课,在我经手的3次培训中,通过短短1天培训后,4~5个小组的(最大-最小)/平均 误差只有正负12%,而误差的很大来源,是一个模拟问答环节总是比较嘈杂,很多团队没有注意听答案!@¥#…%!核对需求后,误差可迅速降低到大约一半。课堂练习只有一张A4纸,里边很模糊地隐含了多达90多个用户故事,练习时间只有1小时,能达到如此的一致性已经很满意了。

大尺度上用户故事的组织结构
最早我们在史诗之上,就是无意义的层级式目录结构了,但就像太阳系外有银河系,银河系外有超星系,超星系外有超星系团一样,事情还没有完。

本来以为在史诗之上没有有实际逻辑意义的结构了,但发现“用户角色权限”这三个故事的距离,远远近于其他故事,应该还有一种具有逻辑意义的东西来描述;其他一些史诗故事也发现了这种内聚性,但尚无合理的划分方法将其定义下来。

笔者暂时创造了“故事群”这个概念来描述他们,但没有找到合理的定义,让不同的人可以一致性地划分故事群。

 

之所以借用功能点分析的概念来产生和组织用户故事,是因为关于用户故事,一直没有非常标准的颗粒度和组织方法;而对于数据、操作,则在接近40年前就开始尝试标准化定义,当前有5个国际标准之多,中国的国家标准也马上出来了。在接受这些标准培训后,不同个体对数据和操作的计数差异,只有不到10%;尚没有任何用户故事的定义能达到如此一致性。

不否认创造和使用敏捷开发的一线员工在定义需求、制定计划、每日跟踪中的经验和权威性,但在大尺度上掌握用户故事的组织结构,以及在甚早期判断项目范围的方面,则正是这一人群的弱项。

敏捷方法需要借鉴已有的外界方法。

 

为什么不用UML方法?因为本人很不熟悉UML。UML比较适合在大尺度上组织用户故事,但很难在甚早期开展(一张A4,隐含90个故事,1小时估完)。

当然这不会抹杀UML在分析用户故事中的作用,日后或许会请另外一位老师写篇文章《用户故事与UML》,我转发过来作为其中一篇,以求完整。

 

作者:陈勇

本专栏经作者授权开设,专栏文章未经许可不得转载

 

scrumcn_userstory

用户故事系列之五:用户故事的分类

这是敏捷开发用户故事系列的第五篇。

引子
在之一、之二、之三中,我们曾经提到了“作为一个……可以……以便……”的用户故事描述方式,还提到应该如何描述用户故事,才能更好地反映客户价值。

下面请尝试一下描述这两个故事:

1. 如果把“保存按钮”统一放在页面上端而非下面,有些屏幕上侧控件的修改,就无需滚屏即可保存。

2. 所有自定义字段,统一改为4000长度的nvarchar。

第一个勉强可以写为:“作为一个用户,可以方便地点击上端的保存按钮,以便在某些控件修改的时候无需滚屏即可保存”,但是这个故事颗粒度显得过小,开发可能只需要1小时,而在客户眼中,也不应该和“作为一个用户,可以对故事进行增删改查,以便……”放在一起。

第二个故事,则找不到“用户”的位置,因为它是我们自己要做的改进,客户完全可以不感知。

这类故事怎么办呢?

分类
有各种分类方法可以把用户故事重新组织一下,下面这种是我自己做的分类,不是一个成熟的方法。

所以在利用这些方法时,一定要理解其用意而不是方法,这样当自己有别的用意时,就能灵活修改。

我自己在开发一个不大的软件时发现,把所有用户故事罗列在一起显示显然极度混乱,于是做了一个相当大的树形结构来显示。

结果发现尽管屏幕利用率很高了,还是难以一眼看到产品的主要功能,原因就是大大小小的故事都挤在一起,有些是产品的卖点应该让客户看到的,有的是要做的重构只和开发团队有关,有些则介于其中,产品经理需要知道,但又不用告诉客户。

另外同样想给客户看的东西,也有大小差异,比如上面例子中的1,如果在“产品版本更新公告”里边,可以写上;但对新客户而言,就不需要,他们完全可以当作产品原来就是这个样子接受下来。

所以最后我的大致分类维度是:横坐标是向外界展现的程度,纵坐标是颗粒度。颗粒度在一定程度上是“有必要呈现的程度”,就是可以以简繁有别地显示产品功能。

 

 颗粒度    客户可见    产品经理可见  开发团队可见
 产品功能描述  数据级别  史诗
 操作级别  功能
 版本发布描述  增强级别   增强  外部缺陷  内部缺陷  重构 债务

 

颗粒度维度
所谓文件,就是一组要操作的数据,比如一个要有用户管理的系统,就肯定有“用户,角色,权限……”这些要操作的数据。其特点是文件是系统的使用者能理解的数据,文件都是名词。

所谓操作,就是对某组或多组数据的操作,对一组数据的操作入手“创建角色”“删除用户”,对多组数据的操作如”为用户分配角色“,其特点是操作是系统使用者的业务操作(就是”干活“的操作),操作都是一个动词。

所谓增强,就是此外的用来做定语、状语、补语的内容了。比如开始引子里边的案例1,就是为了用户方便做的东西,既不是用户要管理的数据,也不是用户平时工作的操作。

这个维度,在”客户可见“的层面上理解,非常方便。

比如描述产品有何功能的时候,只需要展示客户可见的史诗和功能。

比如描述产品版本发布描述(升级公告)时,则应该展示发生变化的史诗、功能、增强三者。(缺陷后面谈)

关于这个维度,请参考:http://blog.csdn.net/cheny_com/article/details/6723715

展现程度维度
除了给客户看的东西,有些东西需要产品经理、开发团队自己知道就可以了。他们所知的范围,向前包括,意思就是说客户能看的,产品经理都能看,产品经理能看的,开发团队都能看。

缺陷有两种,客户提出的,自己发现的。前者要向客户展示(在产品升级公告里边),后者产品经理知道就可以了。

重构则是因为开发的方便性、可维护性、性能、功能的实现方法重新设计等原因引起的内部工作,无需向客户及产品经理透露即可。

债务是开发人员“走捷径”留下的可能出问题的地方。这种“可能出问题”,是指未来的功能、结构发生变化后可能出问题,而不是当前的做每种操作可能出问题(那就应该称为缺陷了)。因此既不需要现在就要改正,也需要留下一个记号日后好查。

实际使用情况
在实际项目里边,我发现这种分类可能会因为项目的不同而不同。比如最近我们想增加三种内部史诗、内部功能、内部增强,因为有些功能是为了内部开发方便做的,而且也有文件、操作、增强的区别。

我们还为不同的故事设置了类似“作为一个……,可以……以便……”的描述模板,但还不是很成熟,日后会分享给大家。

所以,在具体管理中本人也会常常改变分类方法,因此本文的内容日后会发生变化;而大家也应该在每个项目中重新思考以往的分类是否合适。

 

作者:陈勇

本专栏经作者授权开设,专栏文章未经许可不得转载

 

scrumcn_userstory

用户故事系列之四:优先级排序

这是敏捷开发用户故事系列的第四篇。

优先级排序听起来是一个很简单的工作,一个字段无外乎“重要/一般……”,调整一下然后按排序,就出来了。

但其实里边有不少名堂:谁应该负责排序工作?谁最终拍板?研发因素要不要考虑?需求依赖关系导致的顺序如何处理?持续交付的考虑?商业决策的考虑?

以下知识与经验,来自于多个来源,主要是部分网上资料、实际项目的访谈,并在自己现在正在做的一个项目中得到验证。具体应用时,应灵活掌握。

谁负责排序?
Product Owner负责。

在产品研发环境中,一般是产品经理;在项目开发环境中,一般是项目经理。

作为产品或项目的掌舵人,这个人必须对产品或项目的概貌非常了解,从业务概貌到业务细节,都应该了解。从业务这一点上说,了解程度要超过研发团队本身。

有些团队把排序工作交给客户,非常不妥。客户任何时候都只是浅层参与,随时可能会懒散、不专心,因此不要尝试把主动权交给他们。即使此事必须通过客户,也要有内部相应的人加以把控,判断排序的真实性。

谁负责拍板?
要想既了解概貌,又了解细节,对产品经理(以下略去项目经理的情况)而言要求过高,这时候一般配备产品总监,以在更高的层面把控方向。

产品总监的工作更倾向于长远化、市场化、人性化。比如很多消费电子类产品的产品经理负责研究新潮的功能,而产品总监则负责研究“使用这些功能的新潮的人”。

研发因素的考虑
尽管一心一意希望按客户价值排序,但实际情况是往往制约于产品功能的技术实现和依赖关系,不得不做变通。

因此,应该考虑研发团队的介入。

什么?客户,产品经理,产品总监,研发团队……导致谁说了算?说对了,这时候一般需要“产品负责人团队”,即PO团队。

第一次听到这种团队,是看一个国外游戏团队的开发经验。他们的产品负责人团队,他们引入了自己公司的高层、策划人员(即需求开发和管理人员)、开发人员、发行商、热心玩家等等,最终工作由主策划(产品经理)汇总。

需求依赖的考虑
其实多数需求依赖都可以被避开,比如没有“删除功能”,在开发的初期,一样可以登录数据库直接暴力删除。

但是这个会带来以后的问题,比如要持续交付,这个让客户怎么用?更深入的问题,下面继续谈。

持续交付的考虑
上次在做培训的时候,有人问到一个问题大致如下:“我们是持续交付了,但是刚开始的产品缺胳膊少腿,界面也不美观,客户看了直摇头,对我们印象很差,该怎么办?”忙了半天才做到持续交付,居然起到反作用。

这里边其实发生的最大的问题是:一定要从客户的角度理解可运行软件和持续交付,而不要从开发角度!

从开发角度看,上了持续集成系统,每天有一个EXE或DLL生成,就可运行了,可持续交付了,其实大错特错。

比如做一个敏捷开发管理软件,从第一分钟,就是可以运行的软件;但估计要做出可以填写、展示用户故事,无论如何也要到第二周;而要最后卖掉,怎么也得有“用户和权限”这些次要功能。把这些所谓“次要功能”做出来之前就给客户,而又未能向客户说明,极有可能适得其反。

当然一种做法是:把“登录功能”提前呗,不就从第一天就能真的给客户了?不。

商业决策的考虑
作为产品而言,永远应该把最体现差异化价值观的功能置于万事之前,也就是三个月内要决定产品是否值得做,六个月内决定产品的主要功能及投入多少人力,九个月到一年的时候,就发布了(这里边的时间点仅为举例,需灵活掌握)。因此千万不要把登录功能这类大路边的功能做在前面,会积压大量资金人力并大大推迟决策点。

比如某家游戏企业,为了能提前获知游戏是否好玩,以平台化的方法做出了很多基本的能登录、能玩、能买卖、有图片的游戏,新团队只需要在上面做出核心玩法,即可提供高层做出是否继续的判断。

提前做体现价值观的功能,或做出平台加速核心功能开发,都是为了更早给出决策。

项目开发的情况,本人遇到的比较少,但是显然不应该从在开始做那些路边的功能。

最佳实践:故事群
所谓故事群,是在观察一些团队及自己亲自实践的结果。

故事群接近史诗故事的概念,即将故事按照每个故事群交付后,客户可完整操作部分功能的方式,将若干个故事归入一群,并尝试在每个迭代中实现一群,交付或展示给客户。

比如如果做一个敏捷开发软件,则可能规划如下的群:

1. 用户故事相关群

2. 迭代计划相关群

3. 日常工作相关群

4. ……

这样的好处包括:

1. 每个群交付后,局部的功能比较齐全,客户可以较为完整地使用,从而可针对某类功能集中地给以反馈。

2. 由于这些功能整体在说一件事情,客户和开发人员的精力比较集中,能把一件事情想得比较透彻。

当然,这种方法对产品经理的工作能力还是有要求的,否则一个一个群之间很难衔接顺畅。

 

作者:陈勇

本专栏经作者授权开设,专栏文章未经许可不得转载

 

scrumcn_userstory

用户故事系列之三:用户建模

这是敏捷开发用户故事系列的第三篇。

 

用户建模的目的,是为了更好地分析用户行为和用户价值,并因此获得商机。

用户建模四部曲
有一次培训中,分组建模的时候,一位学员就自言自语地说了一句话:“真的啊……我好像不知道谁会使用我的产品……”这其实是一种常见的现象。

比如前文所说的敏捷开发管理软件,如果想把一个用户故事描述为“作为一个用户,可以登录“我的空间”,以查看我我在的所有项目的进展以及自己的任务”,就会遇到这个麻烦。所谓领导,肯定想浅层次低能看到多少项目,就看到多少项目,而且最好能汇总一下显示;作为普通程序员,则肯定不止是想知道自己在哪些项目中有任务,而是想知道自己有哪几个任务是急需完成的(领导肯定也有着急的事情比如要审批,但肯定不如把控大局更重要);作为项目经理,又介于其间。

分析到这一步,就已经做了用户建模的第1步:列出尽可能多的用户。

第2步则是:识别关键用户。

按刚才的划分,还是很难确定谁是关键用户,因为“项目进展”的关键用户是领导和项目经理,而“我的任务”的关键用户则是普通程序员更常用。

这说明这个故事太大了,应该予以分拆,直到能识别出关键用户为止。后面还会提到另外一种更科学的判断故事颗粒度过大是否应该分拆的方法,这里先用这个方法。

第3步则是:面向关键用户,描述故事

假设我们先研究普通程序员的“我的任务”的功能,那么问题就简单一些了。故事可以描述为:“作为一个程序员,可以登录“我的空间”,以查看自己的开发任务中有哪些需要处理。”

为何要写上“那些需要处理”这句话?因为一般没有人会无缘无故面对自己的任务列表发呆的,他肯定来了就有它的目的。比如我们描述了这个“哪些需要处理”的价值观,眼前就能浮现出这些任务肯定不是一视同仁地列在那里,至于要突出“延期的任务”还是“亟待解决的任务”还是“领导关注的任务”,都是具体需求了,不难实现。

可惜经常不是这么简单的三种角色,而是上来一堆程序员、脚本设计师、测试人员、黑盒测试人员等等,不可能给他们每人写一个故事,这时候要做的是第2.5步:合并次要用户。

在上面的例子里边,我们发现刚才列举的几种人可能在使用其他功能上有所不同,但在“我的空间”里边,还是基本相同的,所以把它们合并为一个“开发人员”,并把故事描述为:“作为一个开发人员,可以登录“我的空间”,以查看自己的任务中有哪些需要处理。”

总结
重新排序总结一下用户建模四部曲:

 

第1步:列出尽可能多的用户

第2步:识别关键用户

第3步:合并次要用户

第4步:面向关键用户,描述故事

 

灵活应变
本来写到这里就万事大吉了,国外书上也是这么说的,之前有几次课也是这么讲的,大家也听得挺开心的。

但自己在项目中实践了一段时间后,发现自己经常有一些“过度合并”的倾向。比如在那个敏捷开发管理系统中,角色设置是非常自由的,“添加用户”这个操作,任何授权的用户都可以做,而不一定是“系统管理员”,所以开始就写成“作为被授权的用户,可以添加用户,以便……”。但这种“授权的用户”越来越多了,就感觉其实逐渐坠入最开始的一股脑“作为一个用户”的情况,又都改成“作为一个系统管理员,……”。宁可放弃实际功能,而模拟用户可能的使用场景。

 

一会说要分清用户,一会又说太多了要合并,一会又说合并过头了不行,到底应该怎样?

这里借用《金刚经》里边的一句话,来稳定心法:“菩萨为利益一切众生故,不着于法。”就是菩萨的出发点是众生的利益,因此怎样做好他们就会怎样做,而不会纠缠于方法(比如韦陀菩萨经常杀生)。在如何用户建模这件事情上,出发点是“更清晰更有价值地描述故事”,而不是符合什么建模方法,因此实际使用时,应固守心法,而灵活掌握技法。

本系列乃至本博客其他所有文章所描述的方法,都是即是非法,又是非非法,要本着对开发团队是否有价值,如何更有价值的心法来加以采纳或调整。

 

作者:陈勇

本专栏经作者授权开设,专栏文章未经许可不得转载

scrumcn_userstory

用户故事系列之二:如何面向客户价值编写故事

这是敏捷开发用户故事系列的第二篇。

敏捷开发中的用户故事采用的语法模式看似简单,却蕴含着深刻的思想。

“作为一个……,可以……,以(以便)……”不同于一般专注于功能的需求条目描述方法,三个……把角色、功能、价值跃然纸上。然而使用不当,却有可能形似而神不似。

下面就三个部分分别举出一个例子。
Read more

scrumcn_userstory

用户故事系列之一:何为用户故事

全系列将涉及何为用户故事,面向客户价值编写故事,用户建模,产品待开发项的分类,故事颗粒度,故事的组织结构,等等若干问题,力求将此中问题尽量解决干净。

本系列文章假设正在编写一个“敏捷开发管理软件”,因为来阅读的都是做敏捷开发的,又都是做软件的,会更熟悉一些。

用户故事三要素:角色,功能,价值
按“作为一个……,可以……,以便……”样式和思路写成的用户需求,就是用户故事。

样式是技法层面的东西,它保证了无需太多思考,用户故事中即包含角色、功能、价值这三个要素。
Read more

非功能性需求的用户故事

写用户故事的挑战之一是如何表达非功能性需求。有些需求是与具体的需求无关的,它不像“作为一个文档处理者,我想要在一个文档中插入一个表格”这样的功能描述,而是关于系统的一个属性或者特征的描述。比如说可靠性,有效性,可移动性,可放大性,可用性,可维护性等。在这样的例子中,非功能性需求通常是指“某某性”或者“某某能力”。当然,并不是所有的非功能性需求都是在说“某某性”,还包括像安全机制,性能,自动化能力等等。 Read more