2019-02-18 15:32:24 hdfyhf 阅读数 90
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13675 人正在学习 去看看 张传波
               

这是敏捷开发用户故事系列的第九篇。(栏目目录

本文适合听过MPD上《敏捷开发需求管理:用户故事分类、颗粒度及组织结构》,或参加过《火星人敏捷开发培训》听过第一天下午课程的读者。

若您阅读过程中感觉缺少铺垫的信息,请先阅读:

敏捷开发绩效管理之六:敏捷开发生产率(中)(功能点分析,FPA,简化的功能点)

与早期估算相关的两类用户故事

之前已经提到过,尽管用户故事规模、种类差异很大,但最终与项目开发规模直接相关的,是两大类。

第一类是文件故事(File Story),就是用户需要管理的业务数据。

比如一个人员管理系统,要管理用户/角色/权限这三个业务数据,那么就可以写下3个文件故事:用户,角色,权限。
如果不深究或来不及深究其中的细节(比如老板只拿回来一张纸上面写着这六个字,问“大约”多久可以完成),那么可以简单地这样估算:
1文件故事 = 40人天 = 2人月。(中国-政府行业软件生产率)
所以上述“人员管理系统”,需要6人月。
这可能和直观感觉大相径庭,“这么简单的事情,把需求告诉我,我一个下午就能做完。”
那么这6个人月包含什么呢?这个数据可以用来做什么?(亦即不可以用来做什么?)
使用文件故事做估算时的工作量包含
1. 需求分析/架构设计/编码/测试/部署(至初验款结帐),所包含范围的工作量大约是纯编码期的两倍略多
2. 需求模糊所需的讨论/测试/返工/修改缺陷/响应客户提出变更/乃至部署后提出的变更(在初验结账前),所包含的范围大约是“一次完成”的1~N倍。
4. 由于有多个人参与项目,所以由分工造成的文档/交流/沟通时间/修改别人Bug/人员离职时阅读别人的代码……等时间。
国内的20多个数据表明,若将团队控制在2人,生产率就能达到业界水平的2倍。但很可惜,“2人团队”一般需要至少一个业务和技术均过硬的高手参加,而除非一家公司1/2的人都具备这个素质,否则不可能全部变成2人团队。
5. 人员尽管定编在此项目中,但需要参加其他日常会议/领导前来打搅/紧急缺陷的修复/闲聊/上网……一切最终实际上会被填报在日志中的工时。某些时间看上去很不应该参与到生产率计算中(比如“闲聊/上网”),但因为永远不会有人单独填报“闲聊/上网”时间,所以它们实际上都被填报到日报中参加计算了;“领导前来打搅”的工作量,也不可能计算到其他项目中,所以也计算在人员所定编的项目中。
6. ……
这个数据可以用来做什么?
审视上面工作量的内容,会发现这个数据不是面向开发本身的,而是面向“成本”本身的,即若有任何工作量被计入成本(需要发工资或奖金的),而有没有其他项目可代为承担的,那么就计算到这个项目中。
所以,1文件故事 = 40人天 = 2人月这个计算方法,适合早期项目造价估算。
也就是企业只有提供2人月的成本,才能完成1个文件故事。
作为在项目初期想知道全貌的高层领导,“6个人月的成本才能从头到尾完成这3个文件故事”,要比“告诉我需求,我一下午就能开发出来”要有意义得多。

第二类是操作故事(Function Story),就是用户对业务数据进行的业务操作。

比如对一个人员管理系统,要管理用户,就要有增删改查等操作,这些操作都是业务语境中面向业务数据的,和我们平时说的数据操作不是一个东西。
FPA有一些方法,能根据业务操作估算出比仅仅知道业务数据时更准确的数据,但很可惜,这些操作的数量很难在项目早期估算出来,比如我问:除了增删改查,对“用户”还有哪些操作?在项目的初期,很难说的清楚。但实际工作的时候,就会发现落下了“批量操作”“冻结”这两个操作,而且,每次都只会落下而不会多估,反而不准确。
所以,在项目的初期,不要尝试用操作故事进行估算,而只使用文件故事。
不过,操作类故事可以被用于做生产率度量,因为在项目结束后,计数工作就不会有偏差了。这个,在日后会再谈。
火星人工具中,将来会推出利用用户故事度量生产率的功能,其前提之一是使用者利用火星人中对用户故事的定义进行描述。这一点在本文文初列出的研讨中描述。

非功能性需求造成的生产率波动

由于行业差异/质量要求/软件规模等,会造成生产率的差异,并非每个文件故事都要花费2个人月完成。
影响生产率的因素很多,按韩国的统计数据(韩国现在拥有全世界1/3的FPA专家),主要因素是应用领域差异,韩国的分类统计很细,简单说差异系数大约分别是:
1. OA/MIS类应用:1.0(即每文件故事 = 40 × 1.0人天,下同)
2. 科学计算类:1.4 (简单的财务软件/计算软件)
3. 实时控制类:1.7 (电信计费软件/生产管理软件)
4. 指挥管控类:2.2 (交通/核能/武器/航空等)
这些数字具体应用时并不准确,需要企业用自己的积累。
其他影响因素还包括质量要求、软件规模等,但影响率都只有0~20%左右,与应用领域相比不足为虑。

注:文件故事和操作故事及其英文File Story / Function Story,都是笔者自己临时起的名字,在国际上尚没有对用户故事绝对颗粒度进行讨论的先例。
文件故事得名于FPA中提到的内部逻辑文件(Internal Logical File),但与之对应的操作故事在FPA中被称为“交易”(Transaction,来自早期银行软件)过于难以理解,还是称之为操作故事(英文名Function Story则来自于我们日常所说的“功能性需求”)。
这种命名的混乱还会持续一段时间,取决于未来参与此话题讨论的结果。由于Agile和FPA都来自国外,很多讨论将照顾到国外的用语。
在此期间若看到以下中英文术语,他们大致是等同的:
业务数据 = 数据 = File = Internal Logical File (还有另外一种EIF) = File Story = Data = Data Story = FILE = DATA (后两者是火星人软件中的配置类型)
业务操作 = 操作 = 功能 = Transaction = EI/EO/EQ = Function = Function Story =  Operation = Operation Story = FUNC = OPER (后两者是火星人软件中的配置类型)

           

再分享一下我老师大神的人工智能教程吧。零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到我们人工智能的队伍中来!https://blog.csdn.net/jiangjunshow

2011-09-16 22:59:20 cheny_com 阅读数 10272
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13675 人正在学习 去看看 张传波

这是敏捷开发用户故事系列的第一篇。(栏目目录

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

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

用户故事三要素:角色,功能,价值

按“作为一个……,可以……,以便……”样式和思路写成的用户需求,就是用户故事。

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

角色

角色切记不要总是写“作为一个用户”,而是要把用户区别对待。这样才能更好地理解他们使用什么功能,如何使用,为何使用。

比如“作为一个开发人员,可以登录批量编辑页面,以便高效率地编辑多个故事”就是一个危险的举动,因为如果有多个程序员同时这么做,存储的时候会发生冲突(这个页面后来被删除了)。但“作为一个项目经理,可以登录迭代计划首页,同时编辑多个迭代的信息”则是可行的,因为项目经理一般就有一个,而且这个功能使用次数很少,即使有多个人有权限使用,偶然发生冲突的损害,与平时效率提高相比,也微乎其微。

所以把角色特化出来后,更容易理解功能的价值和风险。

日后另有文章详述如何识别角色,以及如何基于关键角色编写故事。

功能

功能即用户能亲自执行的操作。

应区分用户操作和产品功能之间的关系,因为产品功能可能也提供了用户所需的价值,但却极可能不便于操作。

一个例子是之前我使用一个XX手机,联系方式上在“拨出”之外,总是有一个“编辑拨出”,后来才知道是为了能在前面加拨17951之类的IP电话前缀。写成用户故事,差不多是:“作为一个用户,可以使用编辑拨出在拨打长途前输入IP前缀,以便节省话费。”不过这个功能从来没用过,因为太费劲。实际使用中要么我会把外地电话录入的时候就加上17951,要么一个电话就打出去了管它三七二十一。

后来又使用另外一款Android手机,因为别的原因安装了360,发现它有一个自动IP功能,写成用户故事,就是“作为一个用户,可以在拨打长途的时候自动使用IP拨出功能,以便节省话费。”这个功能每月可以给我节省不下20块钱,如果他有一天收费,我必会买。

价值

价值是完成操作后,客户所得到的价值。

价值里边,常常要带有一点褒义词,或有一些吸引人的内容,比如前面的“高效地”“节省话费”。

潘家宇老师当年提到何为“用例”的时候提到了类似的概念:“用例就是那个你能卖掉的东西。”用户故事也是用来被卖掉的东西,看不到价值的就不是用户故事。

比如上面的360的用户故事写得就比较好,估计如果有读者没装360,看完本文立刻就去。

底层的一些功能看不到直接的用户价值,怎么办?系列中另有一篇描述用户故事的分类。

 

本篇先简单说明一下用户故事的定义,更多内容将逐步展开。

 

点击下载免费的敏捷开发教材:《火星人敏捷开发手册

 

2011-09-30 09:51:48 cheny_com 阅读数 7611
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13675 人正在学习 去看看 张传波

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

 

引子

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

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

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

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

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

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

这类故事怎么办呢?

分类

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

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

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

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

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

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

颗粒度

客户可见

产品经理可见

开发团队可见

产品功能描述数据级别史诗  重构 债务
操作级别功能  
版本发布描述增强级别增强外部缺陷内部缺陷

 

颗粒度维度

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

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

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

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

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

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

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

展现程度维度

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

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

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

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

实际使用情况

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

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

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

 

 

点击下载免费的敏捷开发教材:《火星人敏捷开发手册

 

2011-09-16 23:10:42 cheny_com 阅读数 7070
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13675 人正在学习 去看看 张传波

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

 

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

用户建模四部曲

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

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

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

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

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

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

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

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

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

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

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

总结

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

 

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

第2步:识别关键用户

第3步:合并次要用户

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

 

灵活应变

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

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

 

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

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

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

 

 

点击下载免费的敏捷开发教材:《火星人敏捷开发手册

 

2015-11-23 23:05:36 zhangdaisylove 阅读数 2276
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13675 人正在学习 去看看 张传波

## 创建故事的时机

1. 由Scrum Master和Product Ower来写故事。敏捷虽然是要提高大家的积极度或参与度,但是故事创建并不需要每个成员都参与,如果都参与写故事会造成故事风格不统一,对整体评估和说明反而不利。


2. 故事创建要提前。Scrum Master需要提前安排好下次迭代开发的故事,并把需求转化为故事,产品需求文档和故事基本可以同时送到团队开发成员。我们上次开发是,一起过需求,然后给大家需求分析时间,然后列故事,对故事进行评估。这样就造成一点不好,Scrum Master和开发人员同时拿到需求,都需要时间分析,而Scrum Master创建故事的时候,大家是没事干的,这个时间至少需要半天。所以Scrum Master需要提前把下次迭代的故事列到backlog里面,下次迭代直接选取优先级高的故事开发,更有利也更合理。

## 如何创建故事

编写好的故事,关注六大特征 INVEST:独立的 (Independent),可讨论的 (Negotiable),对用户或客户有价值的 (Valuable to Purchasers or Users),可估计的 (Estimatable),小的 (Small),可测试的(Testable)。我们开发中的经验是更注重,小的,独立的,可测试的。
* 大的故事一定要拆分,别超过5天,否则故事到Done的时间过长,也不利于控制。
* 独立的,避免故事之间的相互依赖,如果过大,按第一条拆分。
* 可测试的,表示对用户有价值的一个流程,而不是通过页面来划分,很容易陷入这种模式,一个或几个设计界面组成一个故事,这种看是明确的东西,其实隐藏了需求关联性,也容易在开发中容易造成功能遗漏,比方说页面之间的关联功能。故事描述格式可以写作,作为用户,需要什么功能,以便做什么事情。比方说,作为用户需求登录功能进入后台管理。

## 时间预估

扑克牌,每人根据自己情况得出一个天数
如果估算不一致,通过最多和最少估算人说出自己的估算方式,避免遗漏,也避免考虑过多
不需要把故事的需求细节了解的太细,而且不要把细节或实现方式放到估算会上,故事细节由用户和开发人员讨论得出。

预估是估算,不可能每个故事都特别准确,但最终的整体时间是可参考的


使用文件故事做估算时的工作量包含
1. 需求分析/架构设计/编码/测试/部署(至初验款结帐),所包含范围的工作量大约是纯编码期的两倍略多
2. 需求模糊所需的讨论/测试/返工/修改缺陷/响应客户提出变更/乃至部署后提出的变更(在初验结账前),所包含的范围大约是“一次完成”的1~N倍。
4. 由于有多个人参与项目,所以由分工造成的文档/交流/沟通时间/修改别人Bug/人员离职时阅读别人的代码……等时间。
国内的20多个数据表明,若将团队控制在2人,生产率就能达到业界水平的2倍。但很可惜,“2人团队”一般需要至少一个业务和技术均过硬的高手参加,而除非一家公司1/2的人都具备这个素质,否则不可能全部变成2人团队。
5. 人员尽管定编在此项目中,但需要参加其他日常会议/领导前来打搅/紧急缺陷的修复/闲聊/上网……一切最终实际上会被填报在日志中的工时。某些时间看上去很不应该参与到生产率计算中(比如“闲聊/上网”),但因为永远不会有人单独填报“闲聊/上网”时间,所以它们实际上都被填报到日报中参加计算了;“领导前来打搅”的工作量,也不可能计算到其他项目中,所以也计算在人员所定编的项目中。
6. ……

没有更多推荐了,返回首页