敏捷开发中的史诗故事_敏捷开发 史诗故事 - CSDN
  • 作者:陈勇 出处:blog.csdn.net/cheny_com 用户故事的颗粒度一直是一个谈论已久的话题,但参加了很多研讨会,搜索了很多网络资源后发现... 前言:为何需要讨论用户故事的颗粒度 其实需求颗粒度的问题由来已久,即

           作者:陈勇

           出处:blog.csdn.net/cheny_com

          

    用户故事的颗粒度一直是一个谈论已久的话题,但参加了很多研讨会,搜索了很多网络资源后发现一直没有定论,只好在这里原创一下。

     

    前言:为何需要讨论用户故事的颗粒度

     

    其实需求颗粒度的问题由来已久,即使是在传统开发中,也没有提及在需求分析阶段应该把需求做到什么颗粒度才可以开工。所以在下面这些分析之后会发现,其实即使反推到传统开发中,下面提及的方法也依然有效。

    为何要对用户故事做一个颗粒度约束呢?

    笔者在开发实践中发现,如果大小不一的“用户故事”堆积在一起,很难看出一个产品到底实现了哪些功能(或一个项目到底有哪些需求)。如果回溯到敏捷开发的源头就会发现,由于敏捷开发中设定用户故事是为了描述开发任务(尽管是从客户价值角度)而非产品功能或项目需求,因此并没有区分用户和开发人员到底分别看到什么。

    其实各种“用户故事”中,大致可以分为史诗Epic、故事Story、增强Enhancement、缺陷Defect、技术债务TechDebts、重构Refactor等几种。其中史诗和故事大致形成树状结构,很容易勾勒出产品或项目的结构,是最需要展示给用户的;增强和缺陷在一定程度上需要展示给用户,但除了评审中或交付后客户提出来的之外,都可以不展示给用户,而且即使展示,“展示”的层次也应该不同于史诗和故事;而技术债务和重构由于太技术化,不适合直接展示给用户,而更适合展示给Product Owner及开发团队。

    本文所讨论的,就是用于“展示产品或项目结构”的史诗与故事的颗粒度问题。

    好的用户故事的标准

     

    先看看好的用户故事的标准(内容及观点与《敏捷开发与用户故事》中大致相同):

    封闭性:完整地交付一个客户价值

    针对性:只包含一个用户,因为多个用户常常有细微的差别

    独立性:故事间没有依赖

    这几条标准中最有价值的观点应该是独立、完整地交付一个客户价值,这在敏捷开发中是至关重要的。传统的开发会说要交付一个软件功能,而敏捷开发则认为用户必须使用这个功能以获得自己的价值(请回忆一下用户故事的编写语法)。

    不过仅仅如此就说能方便地划分故事颗粒度,似乎还有点模糊,下面会引用两个成熟体系中对颗粒度划分的标准来做进一步说明。

     

    功能点分析方法与用户故事

     

    第一个是国际标准功能点分析方法(FPAFuction Point Analysis)中对内部逻辑文件及基本过程的定义。

    内部逻辑文件-基本过程树是一个潜在的史诗-故事树的原型。

     

    一个ILFILFInternal Logical File)就是一组逻辑上的数据,用户能够理解和识别它,对其进行的操作都是用户的业务操作。

    比如如果我们要开发一个“Scrum开发管理平台”,那么有一些明显的“逻辑”数据:系统用户,用户故事,迭代,剩余时间……它们不同于数据库表或程序中的类,因为远在程序被设计之前,就可以判断它们是否存在。

    一个基本过程(Essensial Process)就是对用户有意义的一次业务操作,在完成这次操作后客户得到其业务价值,而且数据稳定完整。

    比如我们“增加一个用户故事”,需要完成的细节过程很多:显示输入界面,在界面中输入数据,数据校验,数据写入数据库表,显示“成功”信息……但只有这一切都完成,从用户角度看才能获得其业务价值,数据也才稳定完整,因此“增加一个用户故事”就是一个基本过程,而“数据校验”等则不是。

    FPA定义中,基本过程还根据分为外部输入/外部输出/外部查询这三种。简单说,我们常说的“增删改查”都是基本过程。为了防止总是从技术角度谈增删改查,常常使用用户业务术语来描述,比如“起草”(输入)、“编辑”(输入)、“发送”(输出)等。

     

    使用FPA中的内部逻辑文件-基本过程树作为史诗-故事树的颗粒度原型有下面几个好处:

    基本过程有严格的定义,已经形成了ISO标准,歧义少;

    基本过程面向客户价值交付,与敏捷开发的价值观接近,也很容易用用户故事描述;

    文件和基本过程的数量被业界证实与软件的工作量有很好的对应关系,已经有多个国家如日韩澳荷芬等将其作为软件计价标准,工信部也已经进行国标立项,面向政府、银行、电信等大量软件外包场景中的造价估算,本文作者是技术专家组成员。

     

    使用FPA中的内部逻辑文件-基本过程树作为史诗-故事树的颗粒度原型,将作出以下约束:

    只有独立完整地交付一个客户价值才算是故事,而缺陷、增强等均不作为有效故事对待;

    只有用户可以直接作为业务操作使用的功能(可以是人-机或机-机交互)才算是有效故事,“开发一个某某函数”(即使这个函数很有客户价值)等均不算是故事;

    多个过程不能合并为一个故事,比如“……,可以对故事进行增删改查,……”。这样可以防止过于粗糙的功能描述阻碍用户价值的有效传达,也利于合理计算用户故事的数量。

     

    MVC与用户故事

     

    第二个是MVC中对ControllerAction的定义。

    Controller-Action树是另一个潜在的史诗-故事树的原型。

    FPAMVC居然能扯上关系?是的,上面提到的FPA中的内部逻辑文件,与MVC中的Controller有很好的对应(有的不能),而基本过程(输入输出查询)与MVCControllerAction有很好的对应关系。比如如果有一个“UserStoriesController”(UserStories可以看作ILF),就会有一堆Create / Edit / Delete / Index……这就是4个基本过程(从前面“增加一个用户故事”的例子可以看出,Create + [HttpPost]Create两者一起才组成一个完整的基本过程)。

    基本过程对应Action还是好理解的,但为何对应内部逻辑文件的是Controller而非Model?因为Controller是面向用户写的,而Model是面向实现技术的。何以见得?因为如果要访问“增加一个用户故事”,我们会输入/UserStories/Create,而其中可能会用到几个ModelUserStories, Statuses, Priorities, Owners……用户无法直接访问Model,但可以直接访问Controller。所以MVCModel更像是DataModel,而Controller才是BusinessModel(有时不是),是“一组逻辑上的数据,用户能够理解和识别它”。

     

    使用MVC中的Controller-Action树作为史诗-故事树的颗粒度原型有以下几个好处:

    Action是一类特殊的面向用户业务和价值的函数,还是客户可以直接感知并调用的函数;

    Action的数量多,客户可感知的功能一般也就多(相对于一般函数);

    Action是一类可单独演示、单独测试的函数,很适合作为故事使用;

    Action很容易被程序员所理解,使用MVC的程序员更容易回答“你们的软件有多少真正的用户故事?”。

     

    使用MVC中的Controller-Action树作为史诗-故事树的颗粒度原型,将作出以下约束:

    多个过程不能合并到一个故事中(与前面FPA的观点相同),因为不能用一个Action实现“增删改查”。

    ControllerAction将只包含有意义的用户故事。有些程序员为了调用方便,会在Controller里定义一些不期待用户直接调用的函数(尤其是直接定义在controller.cs中),应挪到Model中实现。

     

     

    限制与风险

     

    实际上在FPA中,文件与基本过程并非树形结构,一个基本过程完全可能访问多个文件;而在史诗-故事树中,很多故事其实也是跨史诗的;只有MVC强制Action必须属于一个Controller,不过“故事结构 Category-Story”到底应该放在CategoriesController中还是UserStoriesController中?这是一个两难的选择。

    此外FPA中整体认为OptionsConfig这类内容均非要被“卖给”客户的功能,因此不计算内部文件;但在开发中,却需要为其设计Controller来完成工作,两者立足点不同,处理问题会有所差异。

    就像明明分子-原子-中子-质子-电子就可以组成世界了,但上帝还是“额外”设计了几百种夸克一样,关于史诗-故事的正确结构应该如何,与增强、缺陷、技术债务、重构的有机关系应该如何,这些内容的合理展现形式应该如何,还需要同行们更多的讨论。

     

    后语:殊途同归的各流派思想

     

    FPA,大致产生于1970年左右,由IBM的开发人员为了处理银行业务而产生,其目的是以一种客户可以理解的方式来描述和计数产品功能或项目需求。

    MVC,大致产生于????左右,由一些软件开发者为了改善软件结构而产生,其目的是通过分离客户业务与实现技术,增强在客户业务变化时软件的可重用性、可维护性。

    敏捷开发,大致产生于1998年左右,由一群资深开发人员为了改善繁重的开发过程而产生,其目的是减少不体现客户价值的中间环节和文档,快速适应需求变更,追求客户价值最大化。

    但最后居然大致归于:

     

    内部文件 ≈ Controller ≈ 史诗

    基本过程 ≈ Action ≈ 故事

     

    世界是没有银弹的,为了不同的目的不同的人发明了不同的方法,也遗留下不同的悬而未决的问题,只有各种方法互相包容借鉴,才可能发明出更加完善的解决方案。

     

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

     

    展开全文
  • 敏捷软件开发中史诗故事都是常用的术语。对于管理敏捷软件开发来说,Choerodon猪齿鱼是一个很好的工具,为敏捷术语和功能提供了非常广泛的实践方法,例如:史诗故事、任务、子任务和缺陷,这些都是Choerodon...

    在这里插入图片描述
    在敏捷软件开发中,史诗&故事都是常用的术语。对于管理敏捷软件开发来说,Choerodon猪齿鱼是一个很好的工具,为敏捷术语和功能提供了非常广泛的实践方法,例如:史诗,故事、任务、子任务和缺陷,这些都是Choerodon中的问题类型。

    • 史诗:是一个功能集或是一个大的用户故事,但因为颗粒度太大而无法适应冲刺,它可以分解为许多较小的故事;
    • 故事:是简短的用户需求,足够小以适合冲刺;
    • 任务:是完成用户需求的过程性的工作,表示用户故事开发任务的完成;
    • 子任务:子任务通常是故事或任务的具体拆分,由单人承接,而且通常能在短时间内完成;
    • 缺陷:主要针对测试中的缺陷或者已发布版本的缺陷;

    image

    本文将详细为大家介绍敏捷中史诗和故事以及它们在敏捷中的具体使用规范。

    什么是史诗?

    史诗是一个大的故事,当一个功能具有多个场景时,该功能则需要在史诗层面进行多种实现。史诗代表的通常是与特定结果密切相关的原始想法,与该史诗相关联的用户故事则代表需要交付的解决方案的各个方面。总的来说,通过史诗可以跟踪待办事项中比较大的用户需求,史诗中包含多个小的产品功能的用户故事,这让用户需求更加具有层次结构。

    如何编写史诗?

    对于史诗的编写,目前还没有标准格式,一些团队会使用熟悉的用户故事格式,也有一些团队则用简短的短语表示史诗。

    在命名史诗时,请牢记以下两点:

    1.它是开发或需求的核心内容;
    2.编写时使用组织中的每个人都可以理解的语音文字,以免产生歧义;

    因为史诗是编写用户故事时要参考的内容,并且在编写用户故事时还要参考所有团队成员的意见,所以正确的编写史诗并将详细信息在史诗中体现非常重要,这有助于避免团队中的许多冲突和对产品功能的误解。

    用史诗介绍开发的新功能时,需要包括开发此功能的原因、需要解决的用户需求以及新功能的度验收量标准。此外,该功能的任何文档或早期的思路,可以向团队简单介绍,或者提供清晰的图片和信息。注意:团队对功能达成共识和目标是成功交付的关键。

    Choerodon中的史诗示例:

    • 史诗01:向用户提供排序和优先级选项,以轻松管理需求
      • 用户故事01:作为发布经理,我希望将发布映射到不同的sprint,并看到每个故事的优先级。
      • 用户故事02:作为系统管理员,我拥有优先处理产品需求的权限。
      • 用户故事03:作为用户,我可以标注需求的优先级,并实现简单的拖放操作重新排序需求。

    编写史诗时需要注意的是:

    1. 谨慎思考
      在编写史诗时,可以先撰写项目构想的草稿,并需要思考最有必要的内容以及在以后的开发中包含的内容。这些都需要仔细考虑。

    2. 逻辑清晰
      在编写后续的史诗时,应该根据先前的主题来创建史诗,前后的史诗需要合乎逻辑且一致。

    3. 结合测试
      史诗不只是从大的故事进行思考,它分解的每个功能还需要在测试中可用。

    4. 参考专家人士的意见
      在编写过程中不应仅依靠个人或团队成员的眼光和思路,还需要参考专家人士的意见,阅读专业人士的的博客或他们推荐的书籍。他们的工作经验和意见能使史诗更加客观,也能让团队成员获得专业的经验和技能。

    史诗是项目计划过程中重要的组成部分,有了史诗,团队成员和利益相关者可以看到产品真正的目的和用户需求。正确的史诗是进一步项目开发甚至产品研发的好帮手。

    什么是用户故事?

    用户故事是基于史诗进行分解的,反映的是用户需求和用户可以得到的价值。它们从用户的角度描述功能的各个部分。在敏捷开发过程中,当我们开始站在用户的角度上思考时,即使这个功能不是当前解决方案的范畴,我们仍需要建立用户可以操作的行为场景。例如,我们正在针对共享照片和视频的特定问题制定解决方案,根据经验我们按照预期的方式执行所有操作,但是用户第一次使用并且不了解产品,可能查找不到特定角色对应的照片。为了避免这种情况,在用户故事中从用户角度清楚地说明所需的功能非常关键。

    如何编写用户故事

    在敏捷方法论中,团队构建的所有内容都应围绕用户,这里的团队指的是产品经理、客户、利益相关者还有产品的最终用户。为了深度了解用户的需求和痛点,在开始编写用户故事之前,需要确定好产品的角色。以下是编写用户故事时广泛使用的模板:

    “ 作为一名 <角色或角色>,我可以 <目标/需要> 这样说 <为什么>”
    或者,在另一种情况下:
    “作为 <特定的用户类别>,我希望 <能够执行/执行某项操作>, 以便 <获得某种形式的价值或收益>”

    上面的描述为产品用户制定了业务价值。除此之外,用户故事的魅力在于,它不仅制定了业务价值,而且还制定了开发和测试的要求。通过简单的描述,添加产品功能的验收标准等描述,以总结需要完成的所有任务。

    以下Choerodon中某个项目的用户故事的简短形式:

    作为夜晚驾驶的驾驶员,我想迅速找到最近的优质加油站,以补充高品质的汽油。

    • 验收标准:
      • 作为开灯的司机,我可以看到所有即将到来的加油站。
      • 点击“Ctrl+T”,我可以选择适合我的加油站品牌的加油站。
      • 到达加油站,我可以看到即将到来的选定品牌的加油清单。
      • 点击“M”键,我可以看到最近在地图上选择的加油站。

    image

    用户故事的重点是从用户的角度清楚地说明所需的功能,需要正确的理解用户需求并详细的表达出来。编写用户故事时需要注意:

    1. 用户故事≠任务
      用户故事不是任务。在实际开发中,一个故事可能需要数百个任务才能成功交付,任务与执行有关,而用户故事是根据用户需求定义的。在编写故事时,应着重于提供有关产品功能的信息。

    2. 故事简明扼要
      故事必须简单而准确。只需使用简单准确的语言即可,有助于团队成员和利益相关者深入了解用户需求,避免花时间澄清用户故事中不清楚的地方,比如术语和首字母缩写词等。

    3. 了解用户
      在开始编写用户故事之前,都需要收集一组关键用户(理想情况下是产品的角色用户),了解他们的个人资料、观点、对产品的期望以及相关的“痛点”,以帮助更好地了解用户及其需求。

    4. 大胆思考
      当将产品描述为用户故事放到待办事项中时,“没有预算,时间周期不允许,可行性低或成本高等”会限制产品的思维。正确的做法是大胆思考 ,将用户故事维护到待办事项列表,从产品的清晰度、用户愿景方面获得的价值。

    用户故事提供了一种快速而准确地描述软件产品或系统功能的好方法,在产品规划会、产品迭代会中具有主导和输出作用。在这些会议过程中,用户故事需要以紧凑、结构化的方式阐明思想的提要。

    故事地图

    根据敏捷的定义,在Choerodon中我们使用故事地图的形式来体现史诗和用户故事的价值。

    image

    故事地图的优势:

    1. 将史诗用作业务价值的容器;
    2. 根据产品版本得到横向流程;
    3. 快速制定出产品的蓝图,得到mvp版本的制作周期;(关于MVP的介绍可以参考《MVP:平衡“可行性”和“最小化”》);
    4. 以故事为中心,使开发人员的精力全部集中到重点功能上;
    5. 使用增量来定期检查并调整项目进度;

    总结

    敏捷开发关注于快速且持续地交付给用户高价值、高质量、可用的产品功能。通过史诗和用户故事梳理用户需求、识别用户角色、梳理用户故事逐步完善更多细节,使执行的故事足够短小、简单,能在单个迭代期内完成,达到快速交付的目的。

    本篇文章出自Choerodon猪齿鱼社区付新圆&柴晓燕。

    展开全文
  • 5.4 史诗故事、主题 假设你和你的团队想做一些雄心勃勃的事情,比如发射一枚火箭进入太空。要做到这一点,你需要组织你的工作:从最大的目标到最细微的细节。你会希望能够对变化做出反应,汇报你的进展,并坚持一...

    https://www.atlassian.com/agile  

    5.4 史诗、故事、主题
           假设你和你的团队想做一些雄心勃勃的事情,比如发射一枚火箭进入太空。要做到这一点,你需要组织你的工作:从最大的目标到最细微的细节。你会希望能够对变化做出反应,汇报你的进展,并坚持一个计划。史诗、故事、主题和计划正是您需要的工具。
           通过了解这些流行的敏捷方法如何帮助组织工作,您的团队可以在结构、灵活性和向太空发射火箭之间取得健康的平衡。
    什么是故事,史诗,方案和主题?

    • 故事,也称为“用户故事”,是从最终用户的角度编写的简短需求或请求。
    • 史诗是可以分解成许多小任务(称为故事)的大量工作。
    • 方案是为了一个共同的目标而努力的史诗的集合。
    • 主题是跨组织的大型焦点领域。

                                          
     5.4.1 敏捷史诗vs故事
           从某种意义上说,敏捷中的故事和史诗类似于电影或文学中的故事和史诗。故事是一种简单的叙述;一系列相互关联、相互依存的故事构成了一部史诗。你的工作管理也是如此,相关故事的完成会导致史诗的完成。这些故事讲述了完成工作的过程,而史诗分享了统一目标的高层次观点。
           在敏捷团队中,故事是团队可以承诺在一个或两个星期的sprint内完成的事情。通常情况下,开发人员一个月要处理几十个故事。而史诗则相反,数量少,完成时间长。每个季度,团队通常有两到三部史诗要完成。
           如果你的公司正在向太空发射火箭,并且想要为你的发射改进流媒体服务,你可以像下面这样组织你的故事。
    敏捷故事的例子:
           iPhone用户在使用移动应用程序时,需要访问live feed的垂直视图。
           桌面用户需要在视频播放器的右下角有一个“全屏查看”按钮。
           安卓用户需要连接到苹果商店。
           以上故事都是相关的,可以看作是完成较大工作量(史诗)的独立任务。在这种情况下,史诗可能是“为第一季度发布改进了流服务”。
           将工作组织成故事和史诗还可以帮助您和您的团队在组织内进行有效的沟通。如果你把团队的进展报告给工程主管,那你就是在讲史诗。如果您与开发团队中的同事交谈,您会在故事级别进行交谈。
     5.4.2 敏捷史诗vs方案
           就像史诗是由故事组成的一样,方案也是由史诗组成的。方案提供了史诗之上的另一个层次的组织。在许多情况下,一个方案从多个团队中编译史诗,以实现比任何史诗本身更广泛、更大的目标。史诗是你可能在一个月或一个季度内完成的事情,而方案通常是在多个季度或一年之内完成的。
                                           
    史诗在一个方案的例子:
           假设你的火箭船公司今年想把每次发射的成本降低5%。这对于一个项目来说是非常合适的,因为没有一个史诗级的项目能够实现这么大的目标。在这一方案中,将会有诸如“将发射阶段的燃料消耗降低1%”、“将每季度的发射次数从3次增加到4次”以及“将所有恒温器的温度从71度调低到69度#Dadmode”这样的史诗。
     5.4.3 方案与主题
           在许多组织中,创始人和管理团队会鼓励人们去追求一些理想的目标。这些是每年或每个季度宣布的目标(有时是非常老套的),主题是你如何跟踪它们。

    • 方案是史诗的集合
    • 主题是跟踪高级组织目标的标签

           方案有一个结构设计。他们拥有史诗,而这些史诗的完成将导致方案的完成。主题是一种组织工具,允许您标记待定项、史诗和方案,以了解哪些工作有助于实现组织的目标。主题应该激发史诗和方案的创作,但不要与它们之间存在单调乏味的一对一关系。火箭船公司的主题应该是“安全第一”。
     5.4.4 构建你的工作
           敏捷性和包含性结构并不是相互排斥的,这里列出的结构并不是一种适合所有人的结构。成功是当你和你的团队理解这些概念并使它们适应你的需求。对我们来说,那就是故事、史诗、方案和主题。您可以从学习如何在Jira软件中设置Epics开始。
    5.5 史诗
           敏捷史诗是可以根据客户或最终用户的需求/请求分解为特定任务(称为“故事”或“用户故事”)的工作体。
           史诗是组织工作和创建层次结构的有效方法。其理念是将工作分解为可交付的部分,这样大的项目就可以实际完成,并且可以继续定期向客户交付价值。史诗帮助团队分解他们的工作,同时继续朝着更大的目标工作。
           在组织大型任务(如史诗)时保持敏捷性不是一项简单的任务(双关语)。无论您的组织规模大小,了解史诗如何与健康的敏捷项目相关联都是一项基本技能。
     5.5.1 什么史诗?
           史诗是一个庞大的作品,可以分解为许多较小的故事,有时在jira中也称为“问题”。史诗通常包含多个团队,多个项目,甚至可以在多个板上进行跟踪。
           史诗几乎总是通过一组sprint交付的。当团队通过开发和客户反馈了解有关史诗的更多信息时,将根据需要添加和删除用户故事。这就是敏捷史诗的关键:范围是灵活的,基于客户反馈和团队节奏。 
     5.5.2 敏捷史诗的例子
           假设现在是2050年,我们在一个娱乐太空旅行组织工作。我们一年大约发射12次,所以每一次发射都不是我们一年里做的最大的一件事,但它仍然离常规很远,需要很多人的时间来完成。这种大小正好适合史诗。
           以史诗为例,“2050年3月太空旅游发射”包括日常工作的故事,以及旨在改进航天飞机发射的关键方面的故事,从客户购买太空旅行票到火箭发射本身。因此,多个团队将通过处理广泛的故事来为这个史诗做出贡献。
    支持购买2050年3月发行门票的软件团队可能会这样构建他们的史诗:

    史诗:2050年3月推出

    故事:更新日期范围以包括2050年3月发布日期。

    故事:将所要求的航班列表的装载时间缩短至<0.45秒

    故事:在头等舱预订的确认页面上推广土星夏季促销。

    同时,推进团队可能会通过以下故事为同一部史诗做出贡献:

    史诗:2050年3月发布

    故事:发射时保持油箱PSI> 250 PPM

    故事:将整体油耗降低1%。

    故事:雇用新的推进工程师取代加里。#garygate2050

    5.5.3 在完整的敏捷计划中了解史诗
           史诗应该为开发团队提供成功所需的一切。从实际的角度来看,它是他们工作层次结构的顶层。但是,了解史诗与其他敏捷结构之间的关系为日常开发工作提供了重要的背景。

    • 产品路线图是产品或解决方案如何随时间发展的行动计划。
    • 一个主题是一个组织的目标,推动史诗和行动的创建。
    • 产品路线图被表达并可视化为沿着时间轴绘制的一组计划。
    • 将计划分解为史诗有助于将团队的日常工作(以较小的故事形式表示)与总体业务目标保持联系。

           一组完整的史诗驱动特定的计划,从而使整个产品根据组织主题以及市场和客户需求进行开发和发展。
           从我们上面的例子来看,一个主题是增加航天飞机的发射,路线图将会从每季度3次发射增加到4次,计划将会降低成本,增加门票销售,每个史诗都将增加到计划中。
                                           
     5.5.4 创建敏捷史诗
           在创建一个新的史诗时,考虑您的团队可能已经拥有的其他计划和组织工具。围绕球队的季度目标(okr)创造传奇是一个很好的开始。在创建史诗时,考虑以下几点:

    • 报告——为经理和执行人员希望关注的项目创建史诗。
    • 讲故事——使用史诗,以及与之相关的故事,作为一种机制来讲述你是如何达到某个特性或产品的当前状态的。
    • 文化——让组织文化来决定史诗的大小和粒度。
    • 时间——大多数开发团队依赖于评估框架,而不是时间,但是有必要检查一下你的史诗,确保它会花上几周的时间来完成。不要太长也不要太短。

     5.5.5 分解敏捷史诗
           将一个宏大的故事分解成更实际的故事有助于理解一个项目并保持动力,但是这对于新手来说可能是一项艰巨的任务。从史诗中创建故事并没有一种适合所有人的解决方案,但是有很多好的选择可以考虑:

    • 用户角色或角色——为每个用户角色创建一个独特的故事。“新访问者更快的登录”,“回头客更快的登录”,等等。
    • 有序步骤——分解过程并为每个步骤创建一个事例。
    • 文化——让团队规范来规定一个故事是一个快速任务还是一个为期一周的项目。
    • 时间-排除另一个商定的约定,设计可以在一次或更少的印刷中完成的故事。

           大故事和史诗之间并没有统一的定义。一般来说,团队估计完成“周”(或更长)的工作范围,而不是“小时”或“天”的工作范围,都应该被视为一个史诗,并分解为更小的故事。
     5.5.6 测量敏捷史诗
           燃尽图可用于使史诗化可视化,并有助于保持团队的积极性和执行干系人的情况。一个好的史诗燃尽图是组织的敏捷性真正闪耀的地方。
           Epic Burndown图表显示了冲刺或史诗中实际和估计要完成的工作量。 燃尽图中的水平x轴指示时间,垂直y轴指示故事或问题。
                                               
           使用Burndown图表来跟踪剩余的工作,并预测实现sprint目标的可能性。通过在整个迭代中跟踪剩余的工作,团队可以管理其进度并做出相应的响应。
           通过监视燃尽图,可以清楚地看到团队的进展情况以及阻碍因素在哪里。让这些数据点清晰可见可以让每个人都保持在同一页面上,并促进关于产品发展和完成预测的公开对话。更不用说透明能建立信任!
     5.5.7 了解敏捷史诗
           史诗并不是敏捷项目的绝对基础,但对于大多数敏捷团队来说,它们是实际的驱动因素。了解它们在健康敏捷项目中的位置可以为您的工作创建环境,将它们分解为故事可以创建动力。
    5.6 用户故事
           简单地说,用户故事就是软件系统需求,但事实并非如此。
           敏捷软件开发的一个关键要素是把人放在第一位,而用户故事则把实际的最终用户放在了对话的中心。故事使用非技术语言为开发团队及其工作提供上下文。在阅读了用户故事之后,团队知道他们为什么要构建他们要构建的东西,以及它创造了什么价值。
           用户故事是敏捷程序的核心组件之一。它们为日常工作提供了一个以用户为中心的框架——这推动了协作、创造力和整体上更好的产品。
     什么是敏捷用户故事?
           用户故事是敏捷框架中最小的工作单元。它是从软件用户的角度来表达的一个最终目标,而不是一个功能。
           用户故事的目的是阐明一项工作将如何向客户带来特定的价值。请注意,“客户”不必是传统意义上的外部最终用户,他们也可以是内部客户或依赖于您团队的同事。
           用户故事是用简单的语言概括了的几句话,概括了期望的结果。他们不讲细节。一旦得到团队的同意,便会添加需求。
           故事非常适合敏捷框架,比如scrum和看板。在scrum中,用户故事被添加到sprint中,并在sprint的持续期间被“消耗掉”。看板团队将用户描述引入到他们的backlog中,并在工作流中运行它们。正是这种针对用户故事的工作,帮助scrum团队更好地进行评估和sprint计划,从而产生更准确的预测和更大的灵活性。多亏了故事,看板团队学会了如何管理正在进行的工作(WIP),并且可以进一步细化他们的工作流。
           用户故事也是大型敏捷框架(如epics和initiative)的构建块。史诗是被分解成一组故事的大型工作项,多个史诗包含一个方案。这些更大的结构确保了开发团队的日常工作有助于实现构建在史诗和计划中的组织目标。
    为什么要创建用户故事?
           对于新接触敏捷的开发团队来说,用户故事有时似乎是一个额外的步骤。为什么不把这个大项目(史诗)分成一系列的步骤,然后继续进行呢?但是故事为团队提供了重要的背景,并将任务与这些任务带来的价值相关联。
    用户故事提供了许多关键的好处:
           故事将重点放在用户身上。待办事项列表使团队专注于需要检查的任务,但故事的集合使团队专注于为实际用户解决问题。
           故事使协作成为可能。定义最终目标后,团队可以共同决定如何最好地为用户服务并达到该目标。
           故事推动了创造性的解决方案。故事鼓励团队认真思考和创造性思考如何最好地解决最终目标。
           故事创造动力。随着故事的发展,开发团队将面临一个小挑战和一个小胜利,从而推动了发展。  
    处理用户故事
           一旦编写了一个故事,就该将其集成到您的工作流中了。通常情况下,故事是由产品负责人、产品经理或项目经理编写并提交审查的。
           在sprint或迭代计划会议中,团队决定他们将处理哪些故事。团队现在讨论每个用户描述所需的需求和功能。这是一个在团队实现故事中获得技术和创造性的机会。一旦达成一致,这些需求就被添加到故事中。
           会议中另一个常见的步骤是根据故事的复杂性或完成的时间给故事打分。团队使用t-shirt sizes、斐波那契数列或planning poker来进行正确的估计。故事的大小应该在一个sprint中完成,因此当团队描述每个故事时,他们确保将超过完成期限的故事分开。
    如何编写用户故事
    编写用户故事时,请考虑以下事项:

    • “完成”的定义——当用户能够完成概述的任务时,故事通常是“完成”的,但请确保定义它是什么。
    • 概述子任务或任务——确定需要完成哪些具体步骤以及谁对每个步骤负责。
    • 用户角色-为谁?如果有多个最终用户,可以考虑创建多个故事。
    • 有序步骤——为更大流程中的每个步骤编写一个故事。 
    • 倾听反馈——与你的用户交谈,从他们的话中捕捉问题或需求。当你可以从你的客户那里获得这些故事时,就没有必要去猜测了。
    • 时间是一个敏感的话题。许多开发团队完全避免讨论时间,而是依赖于他们的评估框架。由于故事应该在一个sprint中完成,所以可能需要几周或几个月才能完成的故事应该分解成更小的故事,或者应该将其视为自己的史诗。

    明确定义用户故事后,请确保它们对于整个团队都是可见的。
    用户故事模板和示例
    用户故事通常用简单的句子表达,结构如下:
    “作为一个[角色],我[想][这样做]。”
    分解如下:

    • “作为一个角色”:我们为谁构建这个?我们不仅追求职位,还追求人物的个性。Max。我们的团队应该对Max有共同的理解。希望我们采访了很多Max。我们理解那个人的工作方式,他们的想法和感受。我们对Max有同感。
    • “想要”:这里我们描述的是他们的意图——而不是他们使用的功能。他们真正想要达到的目标是什么?该语句应该是无实现的——如果你描述的是UI的任何部分,而不是用户的目标,你就错过了重点。
    • “那么”:他们做这件事的直接愿望是如何与他们更大的愿景相适应的?他们试图实现的总体利益是什么?需要解决的大问题是什么?

    例如,用户故事可能看起来像:

    • 作为Max,我想邀请我的朋友一起享受这项服务。
    • 作为Sascha,我想要组织我的工作,这样我可以更有控制力。
    • 作为一个管理者,我希望能够了解我的同事的进步,这样我可以更好的汇报我们的成功和失败。

           这个结构不是必需的,但是它有助于定义done。当角色能够获得他们想要的价值时,故事就完成了。我们鼓励团队定义自己的结构,然后坚持下去。

     敏捷用户故事入门
           用户故事描述了开发团队成员日常工作背后的原因和内容,通常表示为角色+需求+目的。理解他们作为团队交付内容的真相来源的角色,以及为什么要这样做,是一个顺利的过程的关键。
    从评估下一个,或最紧迫的,大型项目(例如,史诗)开始。将其分解为更小的用户场景,并与开发团队一起进行优化。一旦你的故事被公之于众,整个团队都可以看到,你就可以开始工作了。
     

    展开全文
  • 用户故事在软件研发又被描述为需求。用户故事通常的格式为:作为一个&lt;角色&gt;, 我想要&lt;功能&gt;, 以便于&lt;商业价值&gt;。 因此,一个好的用户故事就包括了这三个要素: 1.角色...

    什么是用户故事?
    用户故事(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)是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素:1. 角色:谁要使用这个功能。2. 活动:需要完成什么样的功能。3. 商业价值:为什么需要这个功能,这个功能带来什么...
  • 敏捷开发中,团队成员认领的是任务还是用户故事
  • 个人工作规划总结文档。从用户故事的概念,用户故事与用例的区别,优秀用户故事的特性,用户故事的划分,划分用户故事的原则,用户故事的验收测试的技术等几方面对用户故事进行阐述。
  • 幸运的是,敏捷开发使用四个明确的交付工具,将结构带入任何敏捷项目:史诗,用户故事,版本和冲刺: · Epic 史诗 大量的工作,包含故事 · Story 故事 最小的工作单位,也被称为任务 · Version ...
  • 我们采用最低限度地、逐渐细化并保存在产品待办项(Product Backlog)的特性描述文字,来替代传统长篇大论的需求文档。 我们发现用户故事是最好的描述方式,这种形式能够捕获到特性足够多的信息,并促进产品负责...
  • 一、史诗(Epics) 一般来说,大型的用户故事(user stories)叫做史诗(Epics)。...史诗级项目通常太大,敏捷团队无法在一次迭代完成,所以在开发之前会被分解成多个更小的用户故事。 二、拆分 (break down )
  • 这是敏捷开发用户故事系列的第五篇。 引子 在之一、之二、之三中,我们曾经提到了“作为一个……可以……以便……”的用户故事描述方式,还提到应该如何描述用户故事,才能更好地反映客户价值。 下面请尝试一下...
  • 今天出于机缘巧合参加一个敏捷的研讨会,虽然在现在这个敏捷已经烂大街的年代,再一次听到各种熟悉的名词还是能让人再次心潮澎湃。正好趁此机会我把之前在为了奇怪目的根据真实经历写的论文拿出来作为本周的博客。
1 2 3 4 5 ... 20
收藏数 1,045
精华内容 418
关键字:

敏捷开发中的史诗故事