敏捷开发用户故事_敏捷开发中的用户故事和故事墙 - CSDN
  • 这是敏捷开发用户故事系列的第十一篇。(栏目目录) 经常有人问起有没有完整的用户故事案例。本人在网上找了一下,大约能找到两三篇,但多数只是为了描述用户故事的语法而已,都不涉及用户故事的颗粒度、大量故事的...

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

    经常有人问起有没有完整的用户故事案例。本人在网上找了一下,大约能找到两三篇,但多数只是为了描述用户故事的语法而已,都不涉及用户故事的颗粒度、大量故事的组织结构这类内容。

    本来想用我们自己的火星人做案例,但考虑到大家都不熟悉我们的工作内容,一直没有动手。前天突然想到何不用大家都熟悉的CSDN博客系统做一个演示,所以才有此文。

    分析过程使用的方法是敏捷开发用户故事系列之十:八步走从用户故事生成代码结构提到的方法(前四步),如果只计算用Word生成故事树的时间,只有1小时不到(当然这是在系统已经完工的情况下,如果尚未开工正在头脑风暴,可能要花费两个人一上午,一般还会遗漏20%左右。当然这已经很快了)。这种方法的优点是不必迟疑下一步该怎么办,而可以聚焦于正在分析的业务本身。

    定义

    子系统 无特殊含义,作为目录使用
    模块 无特殊含义,作为目录使用
    业务数据 一般为名词,用户在系统中需要管理的业务信息。一般每个核心信息包含4~9个下面提到的业务操作,否则应考虑合并或拆分。
    业务操作 一般为动词或动宾词组,用户在系统中对业务数据所作的业务操作。最常见的业务操作即我们常说的“增删改查(查看所有,查看单个)”等五个操作。

    CSDN博客用户故事分析

    下面的三个大子系统,可参考以下页面:

    前台功能可参考:
    http://blog.csdn.net/cheny_com
    后台功能可在登录后访问:
    http://write.blog.csdn.net/postlist
    社区功能可参考:
    http://blog.csdn.net/

    下面是火星人帮助系统中的截图,因无法显示悬停内容,在图后有一些展开的说明文字。

    注意事项

    以下是图中的部分解释(不限于图中有图标的地方,大致从左到右,从上到下)
    他人博客
    若将自己和他人的博客统称为“博客”,则所涉及的操作数量远远超过9个;而且博客用户也能明确感知到两者的区别,故将两者拆分处理。
    
    自己博客
    对于自己的博客也可以查看两种视图,但由于与他人博客的数据格式、展示目的、展示方式大致相同,故不再单独计数。
    
    评论
    评论无论长短都是直接展开显示在评论列表中的,故没有“查看评论详情”。
    
    查看博客配置信息
    博客标题、描述等内容大致目的相同(即都在简单说明网站信息),所以合并并称为“博客配置信息”。
    
    博客栏目
    指博客左侧显示内容的设置,不是“博客系列”所指的栏目。
    
    查看自定义栏目详情
    即“将栏目的内容显示在博客栏目列表中”。在功能点分析FPA中,这是一类最常被遗忘的功能,又称“隐含操作”。
    

    其他遗漏内容

    对博客管理员而言,“推荐的栏目”“推荐的专家”“推荐的博客”等都是业务数据,不过由于没见过实际的操作界面,所以未加以分析。
    这些业务数据面向普通用户的几个“查看所有推荐栏目”(就是具体页面上左边或右边边框的推送框)等操作,我暂时写在博客首页-首页文章下面了。实际上,管理员应该还有一个“查看所有推荐栏目”的页面,但逻辑可能和我们的不太一样,因此可能应该计数为另外一个用户故事。

    此方法的优势

    使用这种名词-动词方法的优势在于,不同的人分析结果大致相同。
    差异一般在于对具体故事的名称、描述、所处位置的略微不同,但对故事的存在性、数量的差异很小。
    实际上,这种方法的原型是功能点分析法,而名词就是ILF(本文没有分析EIF),动词就是EI/EO/EQ。据称不同人使用功能点分析法对同一系统所作分析的差距小于10%(一说5%),这是这种方法被用来做早期报价和估算的原因。

    如有问题,欢迎在下面留言:)
    展开全文
  • 这是敏捷开发用户故事系列的第一篇。(之一,之二,之三,之四,之五,之六,之七,之八,之九)全系列将涉及何为用户故事,面向客户价值编写故事,用户建模,产品待开发项的分类,故事颗粒度,故事的组织结构,等等...

    这是敏捷开发用户故事系列的第一篇。(之一之二之三之四之五之六之七之八之九

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

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

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

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

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

    角色

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

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

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

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

    功能

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

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

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

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

    价值

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

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

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

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

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

     

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

     

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

     

    转载于:https://www.cnblogs.com/wodeyitian/archive/2011/09/16/2459975.html

    展开全文
  • 敏捷开发用户故事

    2014-08-14 20:12:07
    1.1. 敏捷开发的目的 质量风险前移 适应需求变化 及时总结、思考和促进团队成长。     2. User story和需求列表的不同 需求栈通常如下: 序号 功能 详细描述 1 功能1 ...

     

    1.1. 敏捷开发的目的

    质量风险前移

    适应需求变化

    及时总结、思考和促进团队成长。

     

     

    2.      User story和需求列表的不同

    需求栈通常如下:

    序号

    功能

    详细描述

    1

    功能1

    …………………………………………

    2

    功能2

    ………………………………………….

     

     

     

     

     

     

     

    为完成以上功能,我们通常会将任务按重要性,和依赖性对其的优先级排序,排在前的优先做。这是在开发过程中惯用的手法。

    可是每个功能开发该估计多少工作量呢?这个数据确实千差万别,同时按功能实现还有一个缺点,有些功能只有接口,没有界面。如后台功能。这导致测试没办法正常介入。只有当后继的支持功能和界面完成以后,测试才能介入。同时后继开发也面临着问题,包括上次迭代不完整引起的重构问题,上次迭代遗留的BUG可能很多。

     

    出现这些问题的实质原因在区分清楚user story和需求列表的区别,特别是在敏捷开发中的区别。

    敏捷开发,崇拜的价值交付,每一个迭代的交付都是有价值的。传统开发模式下任务是横向切的。


    横向切的意思就是先做数据存储,再做数据访问,再做业务,再做界面。你可以看见当界面没有成型时测试是没有办法有效介入的。

    而敏捷是竖直切的。


    没一个迭代都有完成的数据存储,数据访问,业务和界面的实现。通过每一步迭代完成一套功能。

    l  概括起来,敏捷的userstory有如下的特点:

    l  已工作场景为单位描述

    l  每个user story相对独立

    l  可讨论的,能够支持开发,需求,客户三者,基于场景沟通。(一个功能是无法承担这样任务的)。

    l  有独立的价值。客户可以付钱来卖的。

    l  可估计,可预算的。包括了技术上是能实现的,方案和业务逻辑是可实施的,时间上是可估计的。

    l  小到一个迭代内可完成的。

    l  可测试的。

     

    在实际的开发过程中,也会对userstory排序,排序是更具user story对用户的价值为准则,价值高的先开发。

    展开全文
  • 这是敏捷开发用户故事系列的第五篇。(之一,之二,之三,之四,之五,之六,之七,之八,之九)引子在之一、之二、之三中,我们曾经提到了“作为一个……可以……以便……”的用户故事描述方式,还提到应该如何描述...

    这是敏捷开发用户故事系列的第五篇。(之一之二之三之四之五之六之七之八之九

     

    引子

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

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

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

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

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

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

    这类故事怎么办呢?

    分类

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

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

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

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

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

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

    颗粒度

    客户可见

    产品经理可见

    开发团队可见

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

     

    颗粒度维度

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

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

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

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

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

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

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

    展现程度维度

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

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

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

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

    实际使用情况

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

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

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

     

     

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

     

    转载于:https://www.cnblogs.com/wodeyitian/archive/2011/09/30/2459962.html

    展开全文
  • 用户故事(user story)是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素:1. 角色:谁要使用这个功能。2. 活动:需要完成什么样的功能。3. 商业价值:为什么需要这个功能,这个功能带来什么...
  • 什么是用户故事用户故事(user story)是一个用来确认用户和用户需求的简短描述,作为什么用户,希望如何,这样做的目的或者价值何在。用户故事在软件研发中又被描述为需求。用户故事通常的格式为:作为一个&...
  • 本文描述了敏捷开发的技巧:如何以用户故事管理项目. 什么是用户故事(user story) 假定这个项目的客户是个饮料自动售货机的制造商。他们要求我们为他们的售货机开发一款软件。我们可以找他们的市场经理了解这个软件...
  • 这是敏捷开发用户故事系列的第二篇。(之一,之二,之三,之四,之五,之六,之七,之八,之九)敏捷开发中的用户故事采用的语法模式看似简单,却蕴含着深刻的思想。“作为一个……,可以……,以(以便)……”不同...
  • 敏捷开发中,团队成员认领的是任务还是用户故事
  • 这是敏捷开发用户故事系列的第三篇。(栏目目录) 用户建模的目的,是为了更好地分析用户行为和用户价值,并因此获得商机。用户建模四部曲有一次培训中,分组建模的时候,一位学员就自言自语地说了一句话:“真的啊...
  • 这是敏捷开发用户故事系列的第九篇。(栏目目录)本文适合听过MPD上《敏捷开发需求管理:用户故事分类、颗粒度及组织结构》,或参加过《火星人敏捷开发培训》听过第一天下午课程的读者。若您阅读过程中感觉缺少铺垫...
  • 这是敏捷开发用户故事系列的第八篇。(栏目目录) 本文内容来自火星人团队对火星人产品中300个用户故事编写后总结的经验和成果,欢迎致力于敏捷开发而又对用户故事感到困惑的开发者参与讨论。本篇文章尤其适合参加...
  • 这是敏捷开发用户故事系列的第四篇。(栏目目录)优先级排序听起来是一个很简单的工作,一个字段无外乎“重要/一般……”,调整一下然后按排序,就出来了。但其实里边有不少名堂:谁应该负责排序工作?谁最终拍板?...
  • 面对一张白纸的时候,如何才能迅速理清头绪写出一个结构相对完整、颗粒度适中的功能清单,而且程序员就知道了要写哪些类和函数?下面是简单的八步走法。
  • 一期:活动描述,之一,之二,之三,之四,之五二期:活动描述,之一,之二,之三,之四,之五,之六三期:活动描述,之一,之二,之三,之...关键词:敏捷开发 用户故事 史诗故事 重构 增强 缺陷 MVC FPA 功能点分析一
  • 这是敏捷开发日常跟进系列的第五篇。 (栏目目录) 用户故事和MVC没有关系,因为MVC是实现方法,因此在思考用户故事的时候,不要一下就想到实现方法,很容易把故事写坏。但是MVC和用户故事有很大的关系,如果用户...
  • 一个PDF文档,请从资源页下载。
  • 作者: 徐磊(CSDN专访、...从事过网管、技术支持、网络、软件开发等工作;2004年加入了SSW(www.ssw.com.au);2005年组建SSW中国研发中心任Country Manager;2012年成立独资公司SSW LIMITED BEIJING任GM。2014年创...
  • 用户故事可以帮助开发团队从用户的角度来理解需求,同时在交付的过程中按照用户可用的场景进行交付,确保了开发团队可以持续的交付用户关心的功能。但是在实际开发中,团队往往不知道如何入手。
  • 这是用户故事系列的第六篇。(栏目目录) 一条需求敢跳出来,基本上就能被化成一条用户故事,看完一二三四五,上山打老虎都不怕,这个似乎已经不太难了。难的是,项目或产品的第一天,给一张白纸:“请列出有哪些...
1 2 3 4 5 ... 20
收藏数 73,868
精华内容 29,547
关键字:

敏捷开发用户故事