敏捷开发故事_敏捷开发中的用户故事和故事墙 - CSDN
  • 作为一个用户故事,只有“完成”与“未完成”两种状态,不能使用一个百分比来表达“部分完成”,例如我们不能燃烧掉一个用户故事 1/3 的故事点=来表达它已经完成 1/3了; 基于小时的估算是不精确的,不同人在同一个...

    一个团队/个人花 10 小时能完成的任务,另一个团队/个人或许需要 100小时;

    也有可能团队花了 100小时但是什么都交付不出来;

    作为一个用户故事,只有“完成”与“未完成”两种状态,不能使用一个百分比来表达“部分完成”,例如我们不能燃烧掉一个用户故事 1/3 的故事点=来表达它已经完成 1/3了;

    基于小时的估算是不精确的,不同人在同一个任务上要花不同的小时数;

    花了几个小时在一个任务上不等于这个任务有一部分被完成了, “部分完成”是一个隐藏问题的危险状态,应该避免使用;

    故事点估算更简单和敏捷,虽然它很难使用。  

     
    基于“小时估算”及基于“故事点”监控的差异,一直是一个具体而微妙的问题,令很多初涉敏捷的组织迷惑。(引用作者的用词,)这真是一个“干净利落”的案例。 能正确使用“故事点”来估算及后续监控,理应不会出现任何异议。但学界也仍然有诸如Mike Cohn 等导师级人物仍认为 Ideal Hours是可用的。我个人的理解,其思路与作者有一点关键不同:在燃尽图更新时,视角并不是记录“已消耗工时”,而是再次估算“剩余工时”。换个角度看,燃尽图的更新体现了一个不断估算的过程。再者,遵守“只有彻底完成的Task才能在燃尽图上获得分数”的规则,也可能有效的避免此问题。 个人体会:从 Burn down的价值取向分析,(彻底)完成了多少、(到底)剩余多少,是重要的;既有的成本投入,不太重要。

    展开全文
  • 关于敏捷开发,本人在很早之前已经了解相关的概念,第一次对他了解是在准备软件考试的时候了解到的,然而真正的在实际的项目中运用是从去年一月份,到现在也差不多快两年的时间了,在这两年的实际对敏捷开发这个东西从...

              

            关于敏捷开发,本人在很早之前已经了解相关的概念,第一次对他了解是在准备软件考试的时候了解到的,然而真正的在实际的项目中运用是从去年一月份,到现在也差不多快两年的时间了,在这两年的实际对敏捷开发这个东西从陌生到熟悉,然后又从熟悉到陌生,一路走下来感觉这个东西还是很有味道的,接下来的内容主要是聊聊这个所谓的敏捷开发.

     

            当然,官方有很多关于敏捷开发的解释,先看看下面的解释.

     

           敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

     

           再来看一个解释:

         

            Scrum敏捷开发方法由KenSchwaber Jeff Sutherland 提出,它将软件开发团队比作橄榄球队,全队有明确的最高目标:发布产品的重要性高于一切。团队高度自治,队员们熟悉开发过程中涉及到的各种技术,紧密合作,确保每个迭代都朝着最高目标推进。而且每隔26周,每个人都能看到能实际工作的软件,并且据此决定是发布这个版本还是继续开发以加强它的功能。

        

           上面比较官方的解释看着还是比较抽象.接下来我将会从我的角度通过对敏捷的接触,使用,学习和认识来逐渐的实际的认识所谓的敏捷开发.

       

            先说说使用的背景,本人属于乙方,比较苦逼的那边,给甲方干活.甲方要做的项目属于互联网金融方面,也号称有好几个千万.我们初始团队大概有20个人左右.甲方要求我们采用敏捷开发的方式进行开发.

          

            团队属于新组建的团队,项目属于新项目基本上是0,一行代码都木有,只有一个Eclipse让你去发挥了……由于团队里的成员基本上之前都没有接触过敏捷开发,甲方也是刚刚引入敏捷开发,所以现状就是大家都不知道敏捷具体应该怎么去做.

     

           这时候一个角色出现了.他并不是敏捷开发里的角色,但是对一个初步建立敏捷开发的项目团队而言非常重要,他就是敏捷教练,敏捷教练是甲方花大价钱聘请过来滴,具体薪资听说是论小时给的.他会针对敏捷里的各种问题方方面面,初期他起到了很大的作用.当然在项目具体进行的时候他是不跟项目组一起的,类似一个导师的角色,遇到比较棘手混乱的问题的时候,相关负责人会把他给请过来.

     

           以上就是一些基本的背景,一个互联网金融项目,一个团队,敏捷教练,敏捷开发这些.

     

           但是话又说回来,这几年的敏捷开发已经有些被神话了,但是这个东西并不是神器,实施了就可以解决所有软件公司的问题,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。适合自己的就是更好的.

    展开全文
  • 在前面的三篇文章中对敏捷开发进行了一个背景铺垫,是以笔者个人的经历为主线来逐渐从个人的角度来理解敏捷开发.     通过结对编程完成了开发框架的搭建,在搭建框架的时候其实我们的正式敏捷流程还没有开始,真正...

          

            在前面的三篇文章中对敏捷开发进行了一个背景铺垫,是以笔者个人的经历为主线来逐渐从个人的角度来理解敏捷开发.

     

            通过结对编程完成了开发框架的搭建,在搭建框架的时候其实我们的正式敏捷流程还没有开始,真正开始是大家都可以行动的时候.当敏捷开始的时候整个团队定是在相关的分工下完成任务,所以不同的人有不同的角色,接下来主要对敏捷开发中的角色进行了解.

     

            第一个要说的角色是PO

     

             敏捷开发中的PO即ProductOwner,字面意思是产品或业务负责人,即熟悉该产品所有业务相关的逻辑、流程、设置等方面事宜的人员,一般可由产品经理担任,也可由熟悉业务的开发人员担任。

     

            在我们的团队中PO是行方的专门业务人员担任并执行PO角色,本身并不开发.跟她打交道的一方面是我们这边的开发团队,另一个方面是行方的业务团队,她作为开发和业务的桥梁.

     

            PO主要是确定产品的方向和愿景,定义产品发布的内容、优先级及交付时间,为产品负责。是维护产品需求清单( product backlog )的人.详细的职责为一下七点:

     

    1、确定产品的功能;

     

    2、决定发布的日期和发布内容;

     

    3、为产品的ROI负责;

     

    4、根据市场价值确定功能优先级;

     

    5、每个sprint中,根据需要调整功能和优先级(每个sprint开始前调整);

     

    6、接受或拒绝开发团队的工作成果;

     

    7、参与ScrumPlanning Meetings(Sprint计划会议),Sprint Review Meeting(Sprint评审会)和 SprintRetrospective Meeting(Sprint回顾会)

     

     

            结合我们的团队的PO来说一下实际的情况,在项目的初期我们的PO基本上上是神龙见头不见尾,很少有机会见到他的面,因为他本身还担任行里的其他职务,总是来也匆匆去也匆匆,所以导致了前期开发中很多不可避免的问题.之后行方安排了专职人员担任项目组的PO,整个项目组20个人分成两大组,两个PO负责我们这两个大组的任务和计划.

          

           随后经过团队的磨合,PO也越来越专业,开始进行原型设计,挖掘业务,更融洽的跟开发人员进行沟通和交流.

     

          一个迭代的成功与失败完全由PO说了算(在相对比较理想的情况下),总结就是:告诉产品团队要做什么,做功能的先后顺序是怎样的,需求有变动时该如何处理。

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

    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对用户的价值为准则,价值高的先开发。

    展开全文
  • 什么是用户故事? 用户故事(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:可测试
    如果一个用户故事无法进行测试,那么也就无法判断该故事是否真的完成。所以,用户故事必须在定义了验收测试通过的标准后才能认为用户故事开发完毕。

    展开全文
  • 初识敏捷,接触到下面这些这些新词汇。...Scrum来自英式橄榄球,敏捷开发的团队就好比一只橄榄球队,他们拥有明确的最高目标,而且每时每刻都朝着目标努力,他们熟悉最佳实践,高度自我管理,高度协作...
  • 简要介绍《轻松Scrum之旅–敏捷开发故事》以小说的方式向我们介绍了主人公在经历了如噩梦般的传统的瀑布开发模型后,成功向敏捷开发转型的故事。 作者通过4个迭代开发过程,展现了主人公是如何从一个敏捷开发的新手...
  • 非常有用的敏捷开发书籍,很多公司都在用,这个是公司邀请培训送的pdf,非常好
  • (栏目目录)故事板和看板其实不是一个东西,前者是最初的敏捷开发里边的东西,受到了后者的启发产生的;而后者是制造业的东西,具体内容请参考末尾的百度百科。但是在敏捷开发里边提到这两样东西,可以认为大致...
  • 敏捷开发 故事

    2011-06-12 16:15:00
    分析 : 需求澄清完成后,SE把所有的故事卡都贴到分析阶段 等待开发开发人员和SE确认了需求,明确了做什么以及怎么做以后,把故事卡从分析阶段移到等待开发 开发中 : 开发人员一次只开发一张故事卡,...
  • 敏捷是一种关注价值,消除浪费,以人为核心、迭代、循序渐进的开发方法
  • 敏捷开发目前已成为互联网公司的首选方案,为应对市场的快速变化,我们公司也在大力推广敏捷,最近在读《用户故事与敏捷方法》一书,我想边读边做一些分享,传播知识的同时加强记忆。 1.  基于用户建模是一个比较...
  • 在上篇文章中提到,敏捷开发并不是万能的,而是要结合自己公司的特点和问题摸索出适合自己的一套模式。而项目刚开始的时候,也就是我们整个团队开始摸索敏捷开发的时候.     第一次开始正式进行会议是把所有的相关...
  • 作者是IBM 中国软件开发中心的一个Scrum 敏捷开发团队担任Scrum Master,这期间发生了很多有趣的故事。作者将他们的故事改编成小说,以小 说的形式写了这本书。对于如何实践敏捷项目管理有知道意义。
  • 敏捷开发日常跟进系列之三 故事板,看板
  • 敏捷开发的一点感受

    2014-11-30 21:13:12
    用了3天,充分挤完了海绵里的时间,看了《轻松Scrum之旅:敏捷开发故事》这本书,觉得写得很好,有意思,找到了当时看大话设计模式时候的感觉。  从书的题目可以看出,这本书主要是讲敏捷开发的,我也是第一次接触...
  • 敏捷开发中,团队成员认领的是任务还是用户故事
  • 用户故事(user story)是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素:1. 角色:谁要使用这个功能。2. 活动:需要完成什么样的功能。3. 商业价值:为什么需要这个功能,这个功能带来什么...
  • 发版后,有一段空闲期,闲来无事,看到同事桌上有本《轻松Scrum之旅--敏捷开发故事》,就借过来读了一下,通篇就是一个产品的敏捷开发过程,从概念和使用方法上看,能有不小收获。这次就写一下自己初次体验敏捷的...
  • 一个PDF文档,请从资源页下载。
1 2 3 4 5 ... 20
收藏数 18,348
精华内容 7,339
关键字:

敏捷开发故事