敏捷开发用户故事例子 - CSDN
  • 什么是用户故事用户故事(user story)是一个用来确认用户用户需求的简短描述,作为什么用户,希望如何,这样做的目的或者价值何在。用户故事在软件研发中又被描述为需求。用户故事通常的格式为:作为一个&...

    什么是用户故事?
    用户故事(user story)是一个用来确认用户和用户需求的简短描述,作为什么用户,希望如何,这样做的目的或者价值何在。用户故事在软件研发中又被描述为需求。用户故事通常的格式为:作为一个<角色>, 我想要<功能>, 以便于<商业价值>。

    因此,一个好的用户故事就包括了这三个要素:
    1.角色:使用者。
    2.功能:需要完成什么样的功能。
    3.价值:为什么需要这个功能,这个功能带来什么样的价值。

    另外,用户故事还需要遵循3C原则:卡片(Card)、会话(Conversation)和确认(Confirmation),用户故事的3C原则由Ron Jeffries在2001年提出,直到今天仍被奉为用户故事的基本原则。

    1.卡片:
    用户故事描述的传统形式是手工书写的用户故事卡,卡片上应该只有几句话来捕获需求的精髓或目的。

    后来产品经理们通过写需求设计文档或者规格说明书,通过一个非常完整的word文档将某一个产品的需求定义出来。由于产品需求文档涉及到的内容从项目到实现效果,非常庞大,以至于后来的项目管理中出现了摒弃繁杂的需求文档的做法,或将需求文档仅作为一个参考标准。如知名项目管理软件 禅道提倡将需求文档中的需求点摘出来,录在禅道的【需求描述】里面,作为一个个独立的功能点。
    这其实跟卡片作用是一致的,用简洁凝练的语言,完整呈现用户故事的三要素。

    2.会话:
    会话指的是卡片上所记录的用户故事是可以进行讨论和细化的,它包括利益相关人(客户/用户)、产品负责人及开发团队之间进行更细化地讨论用户故事的可行性。用户故事经过会话确认后,才能正式进入开发阶段(用户故事实现)。敏捷开发的流程完整体现了用户故事(需求)的流转过程。

    以敏捷开发中的Scrum为例:

    scrum的基本流程如上图所示:
    1.产品负责人负责整理user story,形成左侧的product backlog。 ——用户故事整理
    2.发布计划会议:product owner负责讲解user story,对其进行估算和排序,发布计划会议的产出就是制定出这一期迭代要完成的story列表,sprint backlog。 ——用户故事确认
    3.迭代计划会议:项目团队对每一个story进行任务分解,分解的标准是完成该story的所有任务,终每个任务都有明确的负责人,并完成工时的初估计。 ——用户故事分解
    4.每日例会:每天scrum master召集站立会议,团队成员回答昨天做了什么今天计划做什么,有什么问题。 ——用户故事实现
    5.演示会议:迭代结束之后,召开演示会议,相关人员都受邀参加,团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来,由po整理,形成新的story。 ——用户故事的二次整理

     

    敏捷开发中用户故事的细化为开发提供了可执行标准,敏捷开发的特点是快速迭代,一个用户故事的大小和复杂度应该在一个迭代中开发完毕为宜。如果用户故事太大,可能会导致对它的开发横跨几个迭代。,此时就应该将这个用户故事分解。每个任务的时间最好不要超过8小时,就是要保证1个工作日内完成,如果做计划时发现有些任务的时间超过了8小时,就说明任务的划分有问题,需要进行子任务的分解。

     

    3.确认:
    用户故事确认可以理解为对用户故事是否达到验收标准的检测。用户故事需要一系列的验收测试用以保证故事功能的完成及软件按照我们的预期运行。同时要保证这个用户故事最后实现是可以带来商业价值的。

    用户故事的确认由测试人员完成。测试人员在测试版本所关联的用例列表里执行用例,完成测试,然后生成测试报告。测试报告是对用户故事实现程度的最直接体现。

    如果一个用例执行失败,可以直接由这个测试用例创建一个Bug,由开发人员进行二次开发和修复,直到测试通过。

    写好用户故事除了要以3C原则为基础,同时需要考虑到用户故事需要具备的六个特征(也叫INVEST原则):
    Independent:独立性
    用户故事之间应该具有独立性,不应该依赖于其他的用户故事。一般可以通过组合用户故事或者分割用户故事来减少用户故事间的相互依赖性。
    Negotiable:可协商
    用户故事是由客户或者PO同开发小组的成员共同协商制定的,用户故事代表了一个用户群体的需求,而这个需求是零散的,通过相关人员的沟通,协商经常可以丰富用户故事。
    Valuable:有价值
    用户故事对于最终的用户是有价值的,因此应该站在用户的角度去编写,描述的是一个一个的feature,而非一个一个的task。
    Estimable:可评估
    对于一个用户故事的划分需要足够的领域知识,使得在划分故事之时就能大致了解故事开发的周期,为了减少估算的不确定性,故事本身不能太大。
    Small:短小
    故事应该尽量的短小,当然也不是说越小越好。短小的故事可以减少分解过程中估算的误差,最好的故事是能够在一个迭代周期之内完成的。如果太大就应该考虑将其拆分为多个粒度更小的用户故事。
    Testable:可测试
    如果一个用户故事无法进行测试,那么也就无法判断该故事是否真的完成。所以,用户故事必须在定义了验收测试通过的标准后才能认为用户故事开发完毕。

    展开全文
  • 本文描述了敏捷开发的技巧:如何以用户故事管理项目. 什么是用户故事(user story) 假定这个项目的客户是个饮料自动售货机的制造商。他们要求我们为他们的售货机开发一款软件。我们可以找他们的市场经理了解这个软件...

    摘要:

        一件用户通过系统完成他一个有价值的目标(买一罐饮料)的事。这样的过程就叫“用户案例(user case)”或者“用户故事(user story)”。本文描述了敏捷开发的技巧:如何以用户故事管理项目.

    什么是用户故事(user story)

        假定这个项目的客户是个饮料自动售货机的制造商。他们要求我们为他们的售货机开发一款软件。我们可以找他们的市场经理了解这个软件的需求。

        因此,我们的客户就是他们的市场经理。谈需求的时候,有一回他这样说:“用户往售货机每塞一个硬币,售货机都要显示当前该客户已经投了多少钱。当用户投的钱够买某一款饮料时,代表这款饮料的按钮的灯就会亮。如果那个用户按了这个按钮,售货机就放一罐饮料到出口,然后找零钱给他。”

        上面的话描述的是一件事情,一件用户通过系统完成他一个有价值的目标(买一罐饮料)的事。这样的过程就叫“用户案例(user case)”或者“用户故事(user story)”。也就是说,上面我们的客户所说的话,就是在描述一个用户故事(user story)。
        (我解释一下为什么用故事这个词,没兴趣也可以忽略。在一个系统面前,每个用户要完成同样的目标,都要做这个系统设定的例行的事,这件事情不是一个例子,所以不叫事例,这也不是故事,也不能算一段历程,而是一个例行的事。)

        如果我们想要记下这段用户故事,我们可能会用这样的格式:

        名称:卖饮料

        事件:

        1. 用户投入一些钱。

        2. 售货机显示用户已经投了多少钱。

        3. 如果投入的钱足够买某种饮料,这种饮料对应的按钮的灯就会亮。

        4. 用户按了某个亮了的按钮。

        5. 售货机卖出一罐饮料给他。

        6. 售货机找零钱给他。

        注意到,一个用户故事里面的事件可以这样描述:

        1. 用户做XX。

        2. 系统做YY。

        3. 用户做ZZ。

        4. 系统做TT。

        5.  ...

    用户故事只是描述系统的外在行为

        一个用户故事只是以客户能够明白的方式,描述了一个系统的外在行为,它完全忽略了系统的内部动作。比如,下面有下划线的那些文字,就属于不应该出现在用户故事中的系统内部动作:

        1. 用户投入一些钱。

        2. 售货机将塞进来的钱存在钱箱里,然后发送一条命令给屏幕,屏幕显示目前已经投入的金额。

        3. 售货机查询数据库里面所有饮料的价格,判定钱足够买哪些饮料,对于钱足够买的那些饮料,对应的按钮的灯就会亮起来。

        4. 用户按下一个亮起来的按钮。

        5. 售货机卖出一罐饮料给用户,然后将数据库里面该饮料的存货数量减1。

        6. 售货机找零钱给用户。

        不管是口头描述的,还是书面形式,这样的内容是描述用户故事时一个很常见的错误。特别的,千万不要提及任何有关数据库,记录,字段之类的对客户一点意义都没有的东西。

    评估发布时间

        用户故事是用来干嘛的?假定客户希望在50天内递交这个系统。我们做得了吗?为了解答这个问题,我们就要在项目开始的阶段,试着找出所有的用户故事,然后评估一下,每一项历程需要多长的开发时间。可是,怎么评估呢?
        比如,我们现在收集了下面这些用户故事:

        卖饮料:如上面所说的。
        取消购买:在投入了一些钱后,用户可以取消购买。
        输入管理密码:授权的人可以输入管理密码,然后增加存货,设定价格,拿走里面的钱等等。
        补充饮料:授权的人可以在输入管理密码后增加存货。
        取出钱箱里的钱:授权的人在输入管理密码后,可以取出钱箱里的钱箱里面的钱。
        安全警报:有些事情经常发生的话,系统会自动打开安全警报。
        打印月销售报表:授权的人可以打印出月销售报表。

        然后找出里面最简单的用户故事(这里的“简单”,意思是说实现周期最短)。我们不一定非常精准的判断哪个最简单。只要挑出你觉得最简单的就行了。比如,我们觉得“输入管理密码”是最简单的用户故事。然后我们判断说,这个用户故事算1个“故事点(story point)”。
                           
    用户故事          故事点
    卖饮料       
    取消购买       
    输入管理密码   1
    补充饮料       
    取出钱箱里的钱       
    安全警报       
    打印月销售报表       

    不过一般我们不会列出清单,而是做出一堆卡片贴在墙上,每张卡片记录一个用户故事,然后将故事点写在卡片上面:

    image

    这样的一张卡片就叫“故事卡(story card)”。

     

     

    用户故事通常按照如下的格式来表达:

    英文:

    As a <Role>, I want to <Activity>, so that <Business Value>.

    中文:

    作为一个<角色>, 我想要<活动>, 以便于<商业价值>

    举例:

    作为一个“网站管理员”,我想要“统计每天有多少人访问了我的网站”,以便于“我的赞助商了解我的网站会给他们带来什么收益。”

    需要注意的是用户故事不能够使用技术语言来描述,要使用用户可以理解的业务语言来描述。

    Ron Jeffries的3个C

    关于用户故事,Ron Jeffries用3个C来描述它:

    卡片(Card) - 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述,工作量估算等。

    交谈(Conversation)- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。

    确认(Confirmation)- 通过验收测试确认用户故事被正确完成。

    展开全文
  • 这是敏捷开发用户故事系列的第三篇。(栏目目录) 用户建模的目的,是为了更好地分析用户行为和用户价值,并因此获得商机。用户建模四部曲有一次培训中,分组建模的时候,一位学员就自言自语地说了一句话:“真的啊...

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

     

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

    用户建模四部曲

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

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

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

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

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

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

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

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

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

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

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

    总结

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

     

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

    第2步:识别关键用户

    第3步:合并次要用户

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

     

    灵活应变

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

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

     

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

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

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

     

     

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

     

    展开全文
  • 作者: 徐磊(CSDN专访、...从事过网管、技术支持、网络、软件开发等工作;2004年加入了SSW(www.ssw.com.au);2005年组建SSW中国研发中心任Country Manager;2012年成立独资公司SSW LIMITED BEIJING任GM。2014年创...

    作者: 徐磊(CSDN专访CSDN博客),1999年,本科毕业于北京理工大学工业管理专业和计算机专业;2001年,硕士毕业于UNSW信息工程专业。从事过网管、技术支持、网络、软件开发等工作;2004年加入了SSW(www.ssw.com.au);2005年组建SSW中国研发中心任Country Manager;2012年成立独资公司SSW LIMITED BEIJING任GM。2014年创立Lean-Soft,专注于软件工程领域的创新实践。
    声明:原创投稿文章,未经许可禁止转载。

    本系列的第二篇【用户故事驱动的敏捷开发(创建backlog)】

    敏捷开发现在已经不是新鲜事物了,我们都从各种渠道听到过不同的团队实施敏捷的胜果,听的时候觉得很美,回到家就发现那都是别人家的团队,结合自己的情况一看就发现问题一大堆。就算是最终打算一试,也经常会不知如何开始。这就是我希望编写这份文档的原因,能够找到一个遵循的敏捷项目管理模型,虽然我们都知道没有一个放之四海而皆准的方法,但在更高的层面上我觉得这仍然是可行的。也就是说,管理模型是一致的,但是其中采用的方法可能各有不同,最终目标是唯一的:打造一支可以快速适应变化的高质量团队,并输出高质量的产品!

    今天想跟大家分享的是用户故事的规划过程,对于如何使用用户故事驱动团队的开发过程,后续会有更新。

    用户故事的主要问题

    用户故事可以帮助开发团队从用户的角度来理解需求,同时在交付的过程中按照用户可用的场景进行交付,确保了开发团队可以持续的交付用户关心的功能。但是在实际开发中,团队往往不知道如何入手。

    如何用好用户故事需要解决几个关键问题:

    • 如何产生用户故事,让用户将故事讲清楚?
    • 如何将用户故事的内容原汁原味的传递给开发团队?
    • 如何将用户故事中的内容转换为开发功能点,识别与其他功能点的依赖,形成详细的产品规格?
    • 如何在使用用户故事进行增量开发的过程中保持架构的稳定性?同时驱动架构的优化和演进。
    • 如何在开发过程中按照故事进行交付,协同开发,测试,架构以及UI/UE等团队?
    • 如何使用各种开发工具和平台,借助如任务跟踪,分支计划,持续集成,持续发布,自动化测试等工具让开发过程变得更加高效?

    用户故事的需求整理方式与传统需求的整理方式有很大的不同,传统软件开发中我们依赖用户需求,技术需求,规格说明书等工具试图使用规范的文档来解决需求收集和传递的问题。在这个过程中,我们将用户的需求转换成技术可以理解并可实施的规格。对于已经习惯了这种方式的人来说,要转换成使用用户故事的方式需要比较大的思维方式转变,大家往往遇到的疑问也是,难道使用用户故事就不需要规格了吗?其实不然,首先我们要了解用户故事到底是什么。

    用户故事到底是什么?

    大家可能觉得既然我们使用用户故事来替代传统需求,那么用户故事就是记录需求的方式了。其实,用户故事不是用来编写的,而是用来讨论和跟踪的。

    • 使用用户故事,我们的目的是让用户可以自然的讲述需求,这样才能确保信息的真实性。因为任何软件产品都是为了帮助用户完成某种任务,可以说任何的软件产品或者系统都是通过交互来解决问题的,而交互的双方可能是人和系统,也可能是系统和系统,也可能是模块和模块。这样理解的话,任何的需求其实都是某个个体(人,系统或者模块)在和其他个体进行交互的过程中,我们希望的行为方式。用户故事的3个关键点:人,过程和目的;可以帮助我们将这个行为方式讲清楚。在讲故事这个过程中,我们应该专注于故事主线,而不是如何实现。
    • 一旦用户讲清楚了故事,下一步我们需要产生相应的可开发的功能点。这里我们需要专注于如何实现。一般来说,我们很难通过一个功能点来满足一个用户故事,而必须要不同的功能点配合完成。但是我们仍然必须确保讨论的范围是仅仅围绕当前的故事,这时候技术人员非常容易发散,会考虑一些和当前功能点相关,但是和当前故事不相关的内容,如:这个功能可能以后还要用到的,所以我们还要这样这样等等。这时,用户故事可以起到控制讨论范围的作用。你可能会觉得,技术人员的角度是对的,因为可扩展,可复用等是软件设计的基本原则。但是我们应该从发展的角度来看待这些问题,假设我们可以预见的其他用户故事确实会影响这个功能点,那么这样考虑是ok的,但是应该到讨论那个用户故事的时候再去考虑;如果我们没有其他可以预见的故事会影响这个功能点,那么这些所谓的扩展性复用性设计就是浪费,因为你不知道是否会需要。
    • 讨论清楚了功能点,进入开发以后,用户故事是控制技术团队开发进度和交付进度的引线,也就是我们应该按照故事一个个的进行开发测试和交付。这样才能确保我们交付的永远和用户预期一致,所有的开发,测试投入都是可以产生用户认可的价值的。这个时候用户故事起到了跟踪和驱动开发过程的作用。

    通过以上分析,我们可以看到用户故事如何编写并不重要,重要的是它所驱动的过程,通过这个过程,我们可以把用户和技术团队紧密结合,并让大家产生对交付内容的统一认识。所以,用户故事是一种沟通工具,而不是编写工具或者需求模板!

    故事讲给谁?

    在真正开始将故事之前,我们首先要确保正确人都参与进来。对于规划一款产品来说,你至少需要:最终用户代表,产品经理(或类似Scrum中的PO),项目经理(或类似Scrum中的ScrumMaster),团队中的技术骨干(那些对实现的业务很熟悉,对所要使用的技术或者系统很熟悉的技术人员),技术骨干又可以分成架构,开发和测试三个不同技能的人。这样看来,你至少需要6个人参与这个讲故事的过程(除非有些人可以互相替代)。

    你的故事是讲给这里面每个人听的,同时也希望每个人都能够在讲故事的时候有所输入,不仅仅是在听。

    • 最终用户代表:这些人一般会作为讲故事的主角,因为他们是最了解故事的人。但是最终用户代表只能用用户的角度来描述故事,这里会缺失很多技术细节。当他们开始讲故事的时候,技术人员就需要补充这些细节,将那些从用户角度看上去可能很简单的故事后面所涉及到的复杂度暴露出来。
    • 产品经理和项目经理:这两名成员基本起到协调人的作用,一般产品经理(PO)偏向用户,项目经理(ScrumMaster)偏向团队。我们希望他们的这种倾向性能够在讨论过程中体现出来,将故事的优先级,重要程度,实现难度等问题进行归纳总结,形成我们的项目计划。同时,这个故事讨论的过程一般都是以会议形式进行,这2个人应该作为会议的组织者(主持人)出现,引导团队高效的完成讨论过程。
    • 技术骨干:首先技术人员要明确自己也是主角,而不仅仅是旁听。很多人都有这样的体会,明明很简单的一个功能,为啥做起来会那么慢?这里面有2个原因,第一个是用户自己就没有吧这个所谓的“简单”功能想明白;第二个是一个对用户“简单”的功能,对于技术来说恐怕没有那么简单,但这个信息一般很难跟用户讲明白,所以很多技术就倾向于不说或者说的很少。结果就是双方对于难度的认知不一致。技术骨干参与这个讲故事的过程的目的,主要就是为了帮助用户从技术实现的角度理解故事,同时自己也能够将技术实现的思路想明白。

    怎样讲故事?

    讲故事的过程我们通过3个步骤进行:找线索 -> 画主线 -> 规格化

    找线索 – 画出故事的主角

    用户不知道从哪里开始讲故事,这是我们会遇到的第一个问题。其实这时候用户的内心感觉就如同看完一部电影以后走出电影院,试图给没有看过这个电影的朋友讲述。想一想在这个场景下你会如何开始?比如,大话西游大家都看过吧;那么讲故事的方式是,孙悟空在500年前如何如何….,然后紫霞仙子如何如何… 你会发现,你永远都会从某个角色开始讲述。其实让用户讲故事的方式也一样,我们首先要引导用户说出这个故事里都有谁。一部电影是多个角色的故事线交织的结果,一个产品也是一样。有了这些角色,我们就有了可以抽取故事的线索。

    这里我们可以借助2个工具来协助找线索:影响地图和用户画像(12

    你会发现,当团队开始整理不同的类型的用户的时候,他们已经开始自然的讲述故事,因为要把一个角色说清楚,你就必须考虑他要做的事情,故事自然就出来了。但是在这个阶段,我们切记不要过于发散,明确我们的目的是整理用户画像,只要不同用户类型间的边界清晰了,就可以结束,不要为细节纠缠。另外,在后续的过程中我们也会发现可能有些角色还需要添加进去,那么就到时候说。

    最终将我们整理出的每个用户类型用一张即时贴粘在白板的最左侧,如下图:

    图片描述

    一般我会按照距离最终用户的远近来摆放这些即时贴,同时对每个角色进行编号,以便后续可以很容易的进行引用。

    画主线 – 使用影响地图画出故事主线

    有了故事的主角,讲故事就相对容易了。在这个阶段,我们希望能够帮助团队尽量将故事的每一个步骤的都想清楚,通过在看板上进行可视化,我们就可以达到这个目的。这里, 我们可以使用简化版的影响地图,如下图:

    标准的影响地图上有4个列,分别是WHY WHO HOW和WHAT,这种结构在进行比较大和模糊的目标讨论的时候,如:战略规划,会很好用,因为HOW和WHAT比较容易区分;但是用在讨论用户故事的步骤时候,其实HOW和WHAT区别不大,如果坚持使用规范的影响地图会让团队感到迷惑。所以,我建议将HOW/WHAT合并。具体来说:

    WHY:我们这个用户故事是什么?为什么我们要做这个故事?
    WHO:这个故事里面都有哪些角色?
    HOW/WHAT:这些用户为了完成这个故事,需要做些什么,怎样操作?
    

    请参考:影响地图中HOW的理解与对比

    图片描述

    如上图:是一个标准的“新用户注册”的用户故事,大家一定都非常熟悉。基本上这个故事就是浏览者通过 登录->注册->填写信息->验证邮件提交注册,管理员审核,成为已注册用户后首次登录->完善资料。但通过卡片的方式将每个步骤放入白板后你会发现,整个团队可以很好的聚焦到很细节的问题上,同时又对整个故事具备全局观。如果不借助这种可视化方式,那么团队可能很容易丢失当前讨论的主线,从一个细节延展开到其他的部分去了。

    注意这里对每个用户故事进行了ID标注,同样也是为了后续可以容易进行引用。

    你可能会问,那我用个思维导图一类的工具不是更好么?电子化工具的好处是对信息的保存和分享方便,但是在团队讨论中,我们更加重视团队讨论的氛围,聚焦和整体效率,如果使用电子化工具,就无法让每个人都可以同时对这张图进行操作,而必须由一个人操作,其他人很容易走神,如果工具不熟练还会耽误时间。所以看上白板是个很Low的工具,其实对于团队讨论来说,它的效率高于任何的电子化工具。

    图片描述

    如上图:这是我作为敏捷教练参与的一次用户故事讨论,你可以看到大家都聚集在白板周围,整个讨论都是站立进行,任何人都可以随时发表意见,用手指着某个即时贴就可以开始说:“这个”步骤怎样怎样。如果没有可视化工具,或者使用电子化工具,希望每个人都可以用“这个”来聚焦所有人的注意力是很困难的,你可能需要解释“这个”到底是什么,又或者需要在电子工具中鼠标来点,如果操作者不是讲解者,那会更加麻烦。细节决定效率!

    规格化 – 使用用户故事地图进行功能分析

    有了故事主线,我们就可以进行下一步的功能细化。这一步所产出的其实就是传统软件开发过程中的软件规格说明书。软件规格说明书对于开发人员实现产品功能非常重要,是软件开发中不可缺少的部分。很多人认为敏捷开发不需要文档,其实这是个巨大的误解。但是敏捷开发中的文档确实和传统的需求文档有很多区别:

    • 敏捷开发重视的是文档产生的过程,希望通过透明化的过程和集体讨论来确保内容的完整性和信息在过程中的传递。对于文档本身的格式倒是没有具体的要求,只要确保讨论中的内容都被记录就可以。
    • 敏捷开发中的文档并不是用来传递需求的主体,人才是传递需求的主体。
    • 敏捷开发的文档是一份活的文档,所以我们更希望通过系统来记录需求,而不是传统的word或者excel等静态文档来记录。这些文档的作用是帮助团队成员来回忆和讲述,同时也作为过程追踪的手段。
    • 传统软件开发中往往有2份项目计划,一份列出需求并在需求上进行估算以便推导出预算;另外一份是时间和资源计划,这份计划又往往是按照阶段来进行规划的。敏捷开发只有一份项目计划,就是按照用户故事来组织时间,资源和各个阶段的跟踪 – 这其实就是用户故事驱动的敏捷开发的含义。

    规格化的过程中我们可以使用用户故事地图的方式来进行,团队一起根据故事主线中的每个步骤进行讨论,分析出在产品的特定区域(模块)中的功能点,并使用技术人员容易理解的方式来描述这部分的功能。这整个过程就是从将需求从用户角度的描述转换到技术实现角度描述的过程。在这个过程中你会发现一些在故事主线中看不到的技术细节。

    这个过程中,我们希望综合考虑架构和测试的输入,这两个角色需要从自己的角度确保每个故事的分解都满足架构的要求,并且是可以进行测试的。由于每个用户故事都会穿越多个功能区域,架构师必须协助团队确保架构的扩展性,复用性以及性能等要求。对于测试来说,要确保每个用户故事都是可测试的才能确保后续的测试计划和用例可以配合团队的开发过程,并按照故事逐个交付给用户。

    图片描述

    如上图,将以上用户登录这个故事分解为功能点,展示在用户故事地图上,这是标准的用户故事地图格式:

    • 最上面2层是产品的功能区域(模块)
    • 每个模块下面功能点,这些功能点来自于用户故事中的某个步骤的分析
    • 每个功能点的即时贴上标注出用户故事的ID,这样便于我们比对影像地图找到对应的功能点
    • 一些在影响地图中没有明确列出的内容在这张图上被显示出来,比如上图中后台管理和系统功能部分的内容

    如何组织需求讨论会

    讲故事的过程我们一般通过需求讨论会的形式来进行,确保以上应该参与的人员都到场。既然是个会议,我们就必须确保会议的高效,这里可以参考三星高效会议的8点原则:

    (1)凡是会议,必有主题;
    (2)凡是主题,必有议程;
    (3)凡是议程,必有决议;
    (4)凡是决议,必有跟踪;
    (5)凡是追踪,必有结果;
    (6)凡是结果,必有责任;
    (7)凡是责任,必有奖罚;
    (8)凡是奖罚,必须透明。

    针对需求讨论会,我们至少需要有以下安排

    • 会议主题:XXX产品需求讨论会,目的是在4小时内对XXX产品的XXX内容进行讨论
    • 会议议程:
      • 组织者:产品经理XXX或者项目经理XXX
      • 参与者:业务方或最终用户,产品/项目经理,团队技术人员(架构,开发,测试等)
      • 讨论内容(按照优先级排序的故事列表)
    • 会议分工:
      • 主持人:由产品经理和项目经理轮换组织
      • 需求记录人:由技术团队内某人承担,负责在讨论过程中将用户故事和所产生的功能点进行详细记录,形成文档或者录入系统。
      • 问题记录人:由技术团队内某人承担,负责在讨论过程中将无法现场确认的问题进行记录,形成文档或者录入管理系统。
    • 会议交付物:
      • 针对议程中的每个用户故事所产生的文档或者管理系统记录
      • 讨论过程中所记录的问题列表或者管理系统记录
      • 针对用户故事文档的下一步操作,如:制定开发计划,预算等等
      • 针对问题的跟踪方式,如:问题列表的状态由谁负责维护,每个问题由谁负责解决跟进,每个问题预计解决的时间。

    需求讨论会的过程就是按照以上3个步骤讨论故事和分析故事的过程,我们可以按照以下流程进行

    • 讨论会前期准备
      • 可以在进行正式的需求讨论会前先进行一次头脑风暴,邀请用户和技术一同参与,在这个过程中大家可以自由讨论。目的是让大家现对产品的大致情况有所了解。
    • 讨论会过程
      • 首先由主持人(产品经理PO/项目经理ScrumMaster)向团队列出会议所要讨论的故事列表,这个过程不用讨论细节,目的是让大家知道会议的内容和目标,便于控制进度。
      • 根据所列出的故事列表优先级,从第1个故事开始梳理故事主线,分解功能点,并由专人负责记录
      • 重复以上过程直到完成列表中所有故事的讨论
    • 注意事项
      • 一定要按照故事列表逐个讨论,每个讨论都要细化到功能点并完成记录,再进入下一个故事的讨论;不要先讨论所有故事主线,在一并分解功能点。这样做的目的是让团队可以聚焦,避免多条线索交织造成干扰。
      • 在讨论每个故事的时候,不要讨论与当前主线无关的内容;特别是技术团队容易从一个功能点扩散到其他功能点,因为这是技术团队对产品的视角;这种扩散会降低效率。主持人在看到这种情况的时候应该适时制止,告诉团队其他的功能点可以留到其他故事中讨论,只要的产品的一部分,我们在后续的故事中肯定会涉及。
      • 完成每个故事的讨论后可以进行短暂休息,在讨论过程中要确保每个参与成员都集中精力,避免形成小组讨论的形式。建议每个故事的讨论都站立在白板前进行。
      • 主持人可以由PO和ScrumMaster按照故事进行轮换,主持人的主要职责是确保过程的顺畅,团队精力的集中。
      • 待确认事项
      • 建议在白板上开辟一片区域对讨论中出现的团队无法当场确认的问题进行记录,避免在这些问题上纠结太久,影响会议效率。

    以上是如何使用用户故事来驱动产品规划和设计的过程,后续我会对如何再借助kanban和Scrum来驱动开发和交付过程。


    (责编/钱曙光,关注架构和算法领域,寻求报道或者投稿请发邮件qianshg@csdn.net,另有「CSDN 高级架构师群」,内有诸多知名互联网公司的大牛架构师,欢迎架构师加微信qshuguang2008申请入群,备注:姓名+公司+职位。)

    展开全文
  •  User Story是敏捷开发和管理的核心,User Story是从用户的角度对系统的某个功能模块所作的简短描述。一个User Story描述了项目中的一个小功能,以及这个功能完成之后将会产生什么效果,或者说能为客户创造什么价值...
  • 这是敏捷开发用户故事系列的第一篇。(栏目目录)全系列将涉及何为用户故事,面向客户价值编写故事,用户建模,产品待开发项的分类,故事颗粒度,故事的组织结构,等等若干问题,力求将此中问题尽量解决干净。本系列...
  • 敏捷开发-实例1

    2016-03-21 15:02:49
    本系列的第一篇【用户故事驱动的敏捷开发 – 1. 规划篇】跟大家分享了如何使用用户故事来帮助团队创建需求的过程,在这一篇中,我们来看看如何使用这些用户故事和功能点形成产品backlog。产品backlog是敏捷开发中...
  • 作者:陈勇 出处:blog.csdn.net/cheny_com 用户故事的颗粒度一直是一个谈论已久的话题,但参加了很多研讨会,搜索了很多网络资源后发现... 前言:为何需要讨论用户故事的颗粒度 其实需求颗粒度的问题由来已久,即
  • 这是敏捷开发用户故事系列的第五篇。(栏目目录) 引子在之一、之二、之三中,我们曾经提到了“作为一个……可以……以便……”的用户故事描述方式,还提到应该如何描述用户故事,才能更好地反映客户价值。下面请...
  • 用户故事敏捷方法的一部分,有助于将重点从撰写需求转移到讨论需求。所有敏捷用户故事都包含一两句话,更重要的是,有关所需功能的一系列对话。 什么是用户故事用户故事是从希望新功能的人(通常是系统的用户...
  • 用户故事 一、什么是用户故事用户故事也是一种常见的需求描述的方法,它从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素: 1. 角色:谁要使用这个功能。 2. 活动:需要完成什么样的功能...
  • 敏捷开发是快速迭代,快速交付的开发模式。这也就要求迭代周期内任务量不宜过大,以保证在预期内能够按时完成开发计划。敏捷开发中怎样保证开发任务的适宜呢?答案是任务分解。而任务分解的前提则是需求确认。 敏捷...
  • 这是敏捷开发用户故事系列的第二篇。(栏目目录)敏捷开发中的用户故事采用的语法模式看似简单,却蕴含着深刻的思想。“作为一个……,可以……,以(以便)……”不同于一般专注于功能的需求条目描述方法,三个……...
  • 敏捷开发目前已成为互联网公司的首选方案,为应对市场的快速变化,我们公司也在大力推广敏捷,最近在读《用户故事与敏捷方法》一书,我想边读边做一些分享,传播知识的同时加强记忆。 1.  基于用户建模是一个比较...
  • 在大型企业中经常是各种软件开发模式混用,一些采用敏捷开发,一些则是采用传统的瀑布式或RUP(统一软件开发过程)。敏捷开发,相对传统软件开发模式,它主要是针对快速变化的需求,不断优化管理流程,最终推出优质...
  • 用户故事很重要,是实施敏捷开发和持续交付的重要开端。 所谓用户故事就是含有一定业务价值的端到端交付。瀑布开发是把项目按照不同生命周期阶段横向拆分的过程。 而敏捷开发是把项目或产品或业务目标竖向拆分...
  • 产品经理-需求分析-用户故事-敏捷开发 详解 用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素:1. 角色:谁要使用这个功能。2. 活动:需要完成什么样的功能。3. 商业价值:为什么...
  • 本文描述了敏捷开发的技巧:如何以用户故事管理项目. [bitsCN_com] 什么是用户故事(user story) 假定这个项目的客户是个饮料自动售货机的制造商。他们要求我们为他们的售货机开发一款软件。我们可以
  • 这是用户故事系列的第六篇。(栏目目录) 一条需求敢跳出来,...前年做另外一件事情的时候偶然得到一种方法,去年到今年用在一个敏捷项目上,果然很舒服地列出了大量故事,后来的开发过程证实它们都满足独立交付、可测
  • 举个例子敏捷开发像是在冲浪,一直处于动态、不断变化的环境中。在项目研发过程中出现的需求变化和挑战就是你在冲浪时要应对的海浪。他们从不停止而且永远在变化,这种情况下意味着需要快速地适应变化。 首先,...
1 2 3 4 5 ... 20
收藏数 21,021
精华内容 8,408
关键字:

敏捷开发用户故事例子