精华内容
参与话题
问答
  • Scrum敏捷开发简介

    万次阅读 热门讨论 2014-02-16 23:46:45
    Scrum是一种灵活的敏捷软件开发管理过程。这个名词来源于英式橄榄球。Scrum方法由Ken Schwaber和 Jeff Sutherland 提出,它将软件开发团队比作橄榄球队,全队有明确的最高目标:发布产品的重要性高于一切。团队高度...

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


           对于功能需求可能经常发生变化的项目来说,Scrum是它们最为理想的选择之一。在一个采用Scrum的项目中,首先要将所有需要完成的工作列在一个产品待开发项(Product Backlog)中,项目开发过程中需求的改变也要写进去。在每个迭代(Sprint)开始之前,要开一个迭代计划会议(Sprint Planning Meetting)。在会上,产品责任人(Product Owner)为 Product Backlog中的各功能需求确定优先级(或者是在会前完成),随后Scrum开发团队按照优先级,从Product Backlog中挑选出他们认为能在本次迭代中完成的任务,把它们从Product Backlog中挪到Sprint Backlog中来。在Sprint进行过程中,Scrum团队每一天都要举行一个简短的每日立会(Daily Stand-up Meeting),以便团队成员了解开发进度。Sprint结束之后,需要开评审会(Review Meeting)和反思会(Restrospective Meeting)。开发团队在评审会上把这个Sprint的开发成果展示给大家看;而在反思会上,团队成员们会回顾过去的这个Sprint,从中总结经验和教训。



           那么什么是Product Backlog?什么是Sprint Backlog?

           产品待开发项(Product Backlog):根据初始需求分解出的任务列表,包括功能性的和非功能性的所有功能; 由Product Owner为Product Backlog中的任务确定优先级别;当开发团队开始做某个任务的时候,再精确定义和分解这个任务。

           Product Backlog是产品所要具备的所有功能的总纲。当一个项目刚刚开始时,没人能够事先预见到所有的任务和需求,并为之做一个充分、详细而又包罗万象的计划。可行的方式是,先为一个项目写下所有它应该具备的显著特征和功能,数量不必很多,最好够让团队的第一个Sprint有活可干。随着Sprint的进行,生产出可发布的产品增量,客户对产品的直观认识也随之加深,他们可以据此建议更改或者添加产品Backlog中的任务。

           在Sprint计划会议上,产品负责人人为产品Backlog中的任务确定优先级,并向Scrum团队描述这些任务。Scrum团队随后根据团队整体情况,确定他们能在这个即将到来的Sprint中完成哪些功能,并把它们挪到Sprint Backlog中去。


           迭代计划会(Sprint Planning Meeting) :在每个Sprint开始之前,需要召开Sprint计划会议,一般为4至8个小时。参加人员有产品责任人、Scrum Master、Scrum团队和其他感兴趣的人,比如管理层人员和客户代表。Product Owner从产品Backlog中挑选优先度高的任务,并与Scrum团队一起决定在这个Sprint中需要完成多少功能;Scrum团队将这些任务分解成小的功能模块; Scrum团队成员详细讨论如何能按需求完成这些功能模块,并估计完成每个功能模块所需的大概时间。


           每日立会(Daily Stand-up Meeting):既团队每日例会,条件允许的话,每天都应该在同样的时间和地点,所有成员站立着举行。由于是站立的状态开会,因此时间比较短,一般为15分钟左右。这个会议最好是在每天的早晨开,有利于团队成员们安排好当天的工作计划。只有团队成员可以在每日Scrum会议上发言,其他人员如果对项目进度有兴趣也可以参加,但只能旁听而不能发言。

           会议由Scrum Master主持,Scrum团队的所有成员轮流回答上图中的三个问题,即:

      1. 昨天我完成了什么工作;
      2. 今天我打算做什么;
      3. 我遇到了什么障碍。
          通过这三个问题,团队成员之间可以彼此相互熟悉工作内容,充分了解项目进度,相互帮助解决问题。Scrum Master除了倾听团队成员的发言外,他还有责任设法解决团队成员在会上提出的困难,尽快扫除阻碍他们工作的障碍。即使有的问题Scrum Master没有能力解决,例如某些技术细节问题等,他也应该找到团队中或其他团队的来帮助快速的解决问题。另外,还有两点需要注意的地方:其一,这是团队成员之间的交流,也是相互的承诺,并不是用来向老板汇报工作进度的;其二,这也不是一个专门用于解决各种问题的会议,成员们遇到的问题可以在会上提出来,而有能力解决这些问题的人可以在会后帮助他们解决问题。

           Sprint评审会(Review Meeting):Sprint结束时召开;由开发团队展示这个Sprint中完成的功能;长度为两个小时左右;不需要PPT;一般是已完成的功能的Demo; 谁都可以参加:客户、管理层、Product Owner、其他开发人员等等。
           在每个Sprint结束时,应该组织一个Sprint评审会议。Scrum开发团队将在会上展示他们在这个Sprint中所做的工作。一般采用向大家演示产品新功能的方式来展示。
           相对来说,Sprint评审会议不必很正式。通常不需要用到PPT幻灯片,而且长度最好控制在两个小时之内。也就是说,不要让Sprint评审会议成为Scrum团队的负担,他们不必花太多时间来准备这个会议。
           Sprint评审会议的参与者,可以包括所有对该产品感兴趣的人:产品责任人,Scrum团队,利益相关者,管理层人员,客户,甚至来自其他项目的开发人员等等。

           在Sprint评审会议上,Scrum团队用Demo的形式展示产品的新功能之后,与会人员依据在Sprint计划会议上确定的本Sprint的目标来评审具备了这些新功能的产品。


           为什么一定要用Demo的形式来展示产品的新功能呢?因为这种方式有很多好处:
           首先,参与会议的人都能直观的看到Scrum团队的工作成果;其次,利益相关者们可以据此提出更切合实际的反馈意见;第三,为了完成Demo,团队会努力完成并发布那些功能,即使只是发布在测试环境下,也比没完成的好。如果不做Demo,也许不少功能会停留在“已完成99%”的阶段。相比较起来,在有Demo的情况下,也许“已完成”的功能数量会相对少一些,但它们是确确实实完成了的,否则,那些“99%”的貌似完成的功能势必还要拖到下个Sprint来解决。
           假如有一个刚从传统的开发模式转而采用Scrum的团队,由于不习惯这种自我约束、自组织的方式,在Sprint中并没做多少工作,那么在会上演示的时候,他们会觉得很尴尬。没准老板看到他们花了这么多时间只做了这么少的工作而感到很生气。发生这种情况当然是大家都不想看到的,但良药苦口,在下一个Sprint中,这个团队肯定会吸取教训,他们会明白无论什么情况下都必须Demo,那么他们必然会很好的完成这个Sprint并演示给大家看。

    展开全文
  • 敏捷软件开发scrum介绍

    千次阅读 2018-08-31 20:30:54
    敏捷软件开发最近几年越来越火。跟传统软件开发相比有什么优点呢。今天我们就来聊一聊。 首先我们来看下什么叫做敏捷。 敏捷软件开发过程 软件开发过程是指设计软件开发过程中涉及的一系列活动,指导开发组一步...

    敏捷软件开发最近几年越来越火。跟传统软件开发相比有什么优点呢。今天我们就来聊一聊。

    首先我们来看下什么叫做敏捷。

    敏捷软件开发过程

    软件开发过程是指设计软件开发过程中涉及的一系列活动,指导开发组一步一步的进行软件开发。

    包括传统的瀑布过程、螺旋过程、原型过程、敏捷过程等。

    敏捷则是一类过程的统称。之所以把他们都称之为敏捷,是因为它们有共同的特点。

    敏捷过程讲究快速迭代快速试错,将一个大的项目分解成一个一个独立的小项目,每个项目实现一定的功能,每个项目的成果物

    都是可以运行的软件。经过多次迭代之后完成整个项目。

    这里有两个关键点:

    1.独立的小项目

    2.每次交付可以运行的软件。

     

    与瀑布开发方法的对比:

    1.粒度更小,更容易施加控制,降低复杂度。

    2.更好的适应需求的变化。传统瀑布方法需要经历需求获取、需求分析、设计、开发、测试、交付、运维等。上下步存在严格的依赖关系。一旦中间有任何一步出现问题则会导致难以估量的错误,越到后期修改的成本越大。而敏捷方法及时的引用开发和测试以及客户参与,可以及时调整偏差。及时出现问题也只需要付出很小的代价。因此更灵活。

    3.人的认知过程是循序渐进的,敏捷方法推崇增量式需求获取。符合人类的认知习惯。经过多次迭代对需求认识越来越清晰,可以及时纠正原有的认知错误。而瀑布方法妄图在开始时一次性花费巨大的代价获取所有需求。而且获取的需求也不一定是准确和完整的。

    4.瀑布方法上下步是串行的,具有严格的次序关系。因此在执行前面的步骤时负责后面任务的人员都处于闲置状态。人员利用率不足。

    敏捷宣言

    1.个体和交互胜过流程和工具

    面对面沟通是最有效率的方式,人才是最重要的。胜过繁琐的流程和工具。

    2.可以运行的软件胜过面面俱到的文档

    文档只是工具不是结果。不能为了文档而文档。而应该将主要精力放在如何构建正常运行的软件上。

    3.客户参与胜过合同谈判

    多和客户沟通,让客户参与到项目中来,有助于交付满足客户期待的软件。

    4.响应变化胜过遵循计划

    拥抱变化,面对变更应及时调整策略

    敏捷方法是一系列过程的统称,都包括哪些过程呢?

    XP(极限编程)、RUP(统一软件过程)、Scrum等。

    其中scrum在近些年越来越流行。因此我们专门介绍下。

    Scrum英文意思是橄榄球,这里用橄榄球运动来代表这种开发方法激烈、刺激。

    Scrum是敏捷的一种,因此符合敏捷过程的所有特点。但是敏捷中的每种方法在具体实施时还是有一些不小的差异。

    这里我们着重介绍Scrum。

    Scrum讲究以人为本,采用迭代方法、循序渐进的开发软件。

    具有三种角色:

    Product Ower:产品owner,类似于产品经理。负责收集需求,定义优先级,确定需求实现程度

    Scrum Master: Scrum教练,负责项目按照scrum流程执行,处理在项目执行中遇到的各种困难和阻力,把控质量、跟踪进度。类似于传统PM的角色但又有比较大的差异。

    Scrum Team:Scrum开发组,在scrum的框架下执行项目开发工作。

    Sprint

    英文是冲刺的意思,代表一次迭代过程。每次迭代2-4周。

    几种活动:

    Sprint plan meeting:冲刺计划会议,在每次冲刺前进行。由scrum master product ower、scrum team和高层参加,时间一般为

    4-8小时。Product owner将product backlog中的任务划分优先级,同时进行需求澄清。scurm团队成员对本次sprint要完成的user story进行分解成task,挑选感兴趣的任务并接进行工期估算。

    Sprint daily meeting: 每日站会,两个主题:昨天做了什么,今天计划做什么。进度如何。

    Sprint review :sprint 评审,每次冲刺结束时由Scrum team将本次冲刺完成的任务进行展示,检验执行情况和质量。长度控制在两个小时左右,不需要ppt。与会人员根据sprint计划会议的目标来评审目标的完成情况。

    Sprint 回顾会议:回顾整个冲刺,总结和反思,促进团队持续成长。

    燃尽图:横轴表示sprint花费的时间,纵轴表示sprint中所有的任务。燃尽图可以体现sprint的进度。

    User Story:sprint backlog中的每一项都使用一个User Story来描述。一个User Story就是站在用户的角度对系统的每一项功能的一项简短描述。User Story粒度不要太大,一般需要在一个sprint内完成。Scrum team会将User Story拆分成一个或多个task。

     

    scrum开发流程。

    Product Owner在项目开始时将任务放进Product backlog,由于需求是增量式获取的,因此这个过程也是增量式的向Product backlog中添加任务。

    在每次sprint开始时,进行sprint plan meeting,会议上由product owner确定product backloug中任务的优先级,scrum团队决定本次sprint要完成的任务,将任务分解成工作项并进行工期估算,同时将任务从product backlog转移到sprint backlog。冲刺阶段每日进行sprint daily meeting,每次在15分钟左右。两个主题:昨天完成了什么,今天计划做什么。有困难提出但会后和相关干系人讨论,不占用会上时间。冲刺结束时进行冲刺评审,对本次冲刺完成的任务进行演示。检查完成情况。冲刺评审之后进行冲刺回顾,回顾过去的冲刺存在的问题,提出改进方案。重复以上过程,直到完成所有任务。

    Scrum与加班的关系

    敏捷不提倡加班。敏捷的开发不是一直以冲刺的力量奔跑,而是要求团队成员密切配合步调一致,使整个项目有序的向前推进。

    加班从长远来看对整个团队的士气和战斗力是不利的。

    加班的源头,一是因为计划不充分、不准确,中途有不可预料的变化。scrum的流程、每日sprint会议、sprint计划会议等都是为了克服传统软件开发的弱点。这些弱点包括:流程无序、管理困难、难以变更、难以拥抱变化。另一个原因是文化氛围或者观念,认为只有

    加班才能体现对工作的热情,这是很幼稚的。对一个人来说,长时间的工作和生活的不平衡都会导致一些问题。敏捷开发讲究以人为本,对于团队来说如果人出了问题项目失败的可能性就可能达达增加。

     

    几种中国式的敏捷:

    极限编程:每天只工作8小时,还没有达到极限,工作不饱和。来来来多给你分配点任务。

    拥抱变化:产品、需求频繁变更,朝令夕改,昨天说好的今天又变卦。

    迭代式开发:做完了赶紧上线,出了问题再修复一版更新上去。

    持续集成:每天提交几百行代码,不用编译不用自测不用测试用例。

    测试驱动:点了两下没发现问题就可以发布了。

    迭代回顾:新版本刚上线肯定有很多问题,这两天辛苦一下。24小时待命。

    sprint冲刺:明天版本上线,大家辛苦通宵冲刺一下。

    结对编程:开玩笑,一个人的任务两个人轮流干,每人只领一半工资行不行。

    展开全文
  • Scrum敏捷开发基础知识篇

    千次阅读 2018-06-19 22:53:01
    Scrum 的定义
Scrum (名词): Scrum 是一个框架,在此框架中人们可以解决复杂的自适应难题,同 时也能高效并创造性地交付可能最高价值的产品。 Scrum 是:• 轻量的
• 易于理解的• 难以精通的 Scrum 是一个框架,...
    Scrum 的定义

    Scrum (名词): Scrum 是一个框架,在此框架中人们可以解决复杂的自适应难题,同 时也能高效并创造性地交付可能最高价值的产品。 Scrum :
    轻量的

    易于理解的
    难以精通的
      Scrum 是一个框架,自上世纪 90 年代初以来,它就已经被应用于管理复杂产品的工作 上。Scrum 并不是一种过程、技术或决定性方法。倒不如说,它是一个框架,在此框架中 您可以使用各种不同的过程和技术。Scrum 让您的产品管理和工作技术的相对成效更加清 晰地显现出来,以便您可以持续改进产品、团队和工作环境。
      Scrum 框架由 Scrum 团队以及与之相关的角色、事件、工件和规则组成。框架中的每个 部分都有其特定的目的,其对于 Scrum 的成功与使用是至关重要的。 Scrum 的规则把角色、事件和工件组织在一起,管理它们之间的关系和交互。
    Scrum 的应用

    Scrum 最初是为了管理和开发产品而开发的。从上世纪 90 年代初开始,Scrum 在全球范
    围内已得到了广泛应用:
    1. 研究与识别出可行的市场、技术和产品能力;2. 开发产品和增强功能;3. 产品和增强功能,频率高到一天发布多次;4. 开发与支持云(在线、安全、按需)和其他运行环境来提供给产品使用;以及, 5. 支持和更新产品。
    Scrum 已被用于开发软件、硬件、嵌入式软件、交互功能网络、自动驾驶汽车、
    学校、政 府、市场营销、管理组织运营,以及几乎所有我们(作为个人和群体)日常生活中所使用 的一切。
    Scrum运作示意图

     
    SCRUM框架包括3个角色、3个工件、5个事件、5个价值
    3个角色
    产品负责人(Product Owner
    Scrum Master
    开发团队
    3个工件
    产品BacklogProduct Backlog
    SprintBacklog
    产品增量(Increment
    5个事件
    SprintSprint本身是一个事件,包括了如下4个事件)
    Sprint计划会议(Sprint Planning Meeting
    每日站会(Daily Scrum Meeting
    Sprint评审会议(Sprint Review Meeting
    Sprint回顾会议(Sprint Retrospective Meeting
    5个价值
    承诺 愿意对目标做出承诺
    专注– 把你的心思和能力都用到你承诺的工作上去
    开放– Scrum 把项目中的一切开放给每个人看
    尊重– 每个人都有他独特的背景和经验
    勇气– 有勇气做出承诺,履行承诺,接受别人的尊重
     Scrum 团队
    Scrum 团队由一名产品负责人、开发团队和一名 Scrum Master 组成。Scrum 团队是跨职 能的自组织团队。自组织团队自己选择如何以最好的方式完成工作,而不是由团队之外的 人来指导。跨职能团队拥有完成工作所需的全部技能,不需要依赖团队之外的人。Scrum 团队模式仍是设计用来提供最佳的灵活性、创造力和生产力。Scrum 团队(自身)已经证 明,对于所有之前所述 Scrum 的应用以及任何复杂工作来说,它都是越来越有效的。
    Scrum 团队迭代增量式地交付产品,籍此最大化地获得反馈的机会。增量式交付“完成” 的产品保证了一个可工作产品的潜在可用版本总是存在。
    产品负责人
    产品负责人的职责是将开发团队开发的产品价值最大化。如何实现这一点的方式会随着跨 组织、Scrum 团队和团队成员个体的不同而有所不同。
    产品负责人是负责管理产品待办列表的唯一负责人。产品待办列表的管理包括:
    清晰地表述产品待办列表项; 
对产品待办列表项进行排序,使其最好地实现目标和使命; 
优化开发团队所执行工作的价值; 
确保产品待办列表对所有人是可见、透明和清晰的,同时显示 Scrum 团队下一步要做的工作;以及确保开发团队对产品待办列表项有足够深的了解。产品负责人可以亲自完成上述工作,或者也可以让开发团队来完成。然而无论何者,产品 负责人是负最终责任的人。产品负责人是一个人,而不是一个委员会。产品负责人可能会通过产品待办列表展现一个 委员会的期望要求,但是想要改变产品待办列表项的优先级都必须经过产品负责人。为保证产品负责人的工作取得成功,组织中的所有人员都必须尊重他/她的决定。产品负 责人对产品待办列表的内容和排序的决定必须是可见的。没有人可以强迫开发团队按照另 一套需求开展工作。
    开发团队
    开发团队包含各种专业人员,负责在每个 Sprint 结束时交付潜在可发布并且“完成”的 产品增量。在 Sprint 评审会议上,一个“完成”增量是必需的。只有开发团队成员才能 创建增量。 开发团队由组织组建并得到授权,团队自己组织和管理他们的工作。由此产生的正面效应 能最大化开发团队的整体效率和效用。
    开发团队具有下列特点:
    他们是自组织的。没有人(即使是 Scrum Master)有权告诉开发团队应该如何把产品 待办列表变成潜在可发布的功能增量; 

    开发团队是跨职能的团队,团队作为一个整体,拥有创建产品增量所需的全部技能; 
Scrum 不认可开发团队成员的任何头衔,不管其承担何种工作(他们都叫开发人员)Scrum 不认可开发团队中所谓的“子团队”,无论其需要处理的领域是诸如测试、架构、运维或业务分析;同时开发团队中的每个成员也许有特长和专注的领域,但是责任属于整个开发团队。
    开发团队的规模
    开发团队最佳规模是足够小以保持敏捷性,同时足够大可以在 Sprint 内完成重要的工 作。少于 3 个人的开发团队,成员之间没有足够的互动,因而生产力的增长不会很大。 过小的团队在 Sprint 中可能会遭遇到技能上的约束,进而导致开发团队无法交付潜在可 发布的产品增量。超过 9 人的团队则需要过多的协调沟通工作。对经验过程而言,大型 开发团队会产生太多的复杂性而变得无用。产品负责人和 Scrum Master 角色不包含在开 发团队人数中,除非他们同时也参与执行 Sprint 待办列表中的工作。
    Scrum Master
    
    Scrum Master 负责根据 Scrum 指南中的定义来促进和支持 ScrumScrum Master 通过帮 助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。 
Scrum Master Scrum 团队而言,他/她是一位服务型领导。Scrum Master 帮助 Scrum 团队之外的人了解他/她如何与 Scrum 团队交互是有益的,通过改变他/她们与 Scrum 队的互动方式来最大化 Scrum 团队所创造的价值。
    
Scrum Master 服务于产品负责人
       Scrum Master 以各种方式服务于产品负责人,包括: 
• 确保 Scrum 团队中的每个人都尽可能地理解目标、范围和产品域;
    找到有效管理产品待办列表的技巧;
    帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项;
    理解在经验主义的环境中的产品规划
    确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值;
    理解并实践敏捷性;以及,当被请求或需要时,引导 Scrum 事件。
    Scrum Master 服务于开发团队

    Scrum Master 以各种方式服务于开发团队,包括:
    作为教练在自组织和跨职能方面给予开发团队以指导;
    帮助开发团队创造高价值的产品;
    移除开发团队工作进展中的障碍;
    按被请求或需要时,引导 Scrum 事件;以及在 Scrum 还未完全采纳和理解的组织环境中,作为教练指导开发团队。
    Sprint
    Sprint Scrum 的核心,其长度(持续时间)为一个月或更短的限时,这段时间内构建 一个“完成”、可用的和潜在可发布的产品增量。在整个开发过程期间,Sprint 的长度保 持一致。前一个 Sprint 结束后,下一个新的 Sprint 紧接着立即开始。
    Sprint Sprint 计划会议、每日 Scrum 站会、开发工作、Sprint 评审会议和 Sprint 回顾 会议构成。
    Sprint 期间:
    不能做出有害于 Sprint 目标的改变;
    不能降低质量的目标;以及,
    随着对信息掌握的增加,产品负责人与开发团队之间对范围内要做的事可以加以澄清 和重新协商。
    每个 Sprint 都可以被视为一个项目,为期不超过一个月。就如同项目一样,Sprint 被用 于完成某些事情。每个 Sprint 都会有一个要构建什么的目标,还有一份设计过和灵活的 计划用来指导如何做这些事、工作内容和最终产品增量。
    Sprint 的长度限制在一个月内。当 Sprint 的长度太长的话,对要构建什么的定义就有可能会改变,复杂性也有可能会增加,同时风险也有可能会增加。Sprint 通过确保至少每月 一次对达成目标的进度进行检视和适应,来实现可预测性。Sprint 同时也把风险限制在一 个月的成本上。
    Sprint 计划会议

    Sprint 中要做的工作在 Sprint 计划会议中来做计划。这份工作计划是由整个 Scrum 团队 共同协作完成的。
    Sprint 计划会议是有时间盒限定的,以一个月的 Sprint 来说最长为 8 小时。对于较短的 Sprint,会议时间通常会缩短。Scrum Master 要确保会议顺利举行,并且每个参会者都理 解会议的目的。Scrum Master 要教导 Scrum 团队遵守时间盒的规则。
    Sprint 计划会议回答以下问题:
    接下来的 Sprint 交付的增量中要包含什么内容?
    要如何完成交付增量所需的工作?
     
    话题一:这次 Sprint 能做什么?
    开发团队预测在这次 Sprint 中要开发的功能。产品负责人讲解 Sprint 的目标以及达成该 目标所需完成的产品待办列表项。整个 Scrum 团队协同工作来理解 Sprint 的工作。
    Sprint 会议的输入是产品待办列表、最新的产品增量、开发团队在这个 Sprint 中能力的 预测以及开发团队的以往表现。开发团队自己决定选择产品待办列表项的数量。只有开发 团队可以评估接下来的 Sprint 可以完成什么工作。
    Sprint 计划会议中,Scrum 团队还草拟一个 Sprint 目标。Sprint 目标是在这个 Sprint 通过实现产品待办列表要达到的目的,同时它也为开发团队提供指引,使得开发团队明确 开发增量的目的。
     
    话题二: 如何完成所选的工作?
    在设定了 Sprint 目标并选出这个 Sprint 要完成的产品待办列表项之后,开发团队将决定 如何在 Sprint 中把这些功能构建成“完成”的产品增量。这个 Sprint 中所选出的产品待 办列表项加上如何交付它们的计划称之为 Sprint 待办列表。
    开发团队通常从设计整个系统开始,到如何将产品待办列表转换成可工作的产品增量所需 要的工作。工作有不同的大小,或者不同的预估工作量。然而,在 Sprint 计划会议中, 开发团队已经挑选出足够量的工作,以此来预估他们在即将到来的 Sprint 中能够完成。 Sprint 计划会议的最后,开发团队规划出在 Sprint 最初几天内所要做的工作,通常以 一天或更少为一个单位。开发团队自组织地领取 Sprint 待办产品列表中的工作,领取工 作在 Sprint 计划会议和 Sprint 期间按需进行。 产品负责人能够帮助解释清楚所选定的产品待办列表项,并做出权衡。如果开发团队认为 工作过多或过少,他们可以与产品负责人重新协商所选的产品待办列表项。开发团队也可 以邀请其他人员参加会议,以获得技术或领域知识方面的建议。
    Sprint 计划会议结束时,开发团队应该能够向产品负责人和 Scrum Master 解释他们将 如何以自组织团队的形式完成 Sprint 目标并开发出预期的产品增量。
    Sprint 目标

    Sprint 目标是在当前 Sprint 通过实现产品待办列表要达到的目的。它为开发团队提供指 引,使得团队明确为什么要构建增量。Sprint 目标在 Sprint 计划会议中确定。Sprint 目标 为开发团队在 Sprint 中所实现的功能留有一定的弹性。所选定的产品待办列表项会提供 一个连贯一致的功能,也即是 Sprint 目标。Sprint 目标可以是任何其他的连贯性来促使 开发团队一起工作而不是分开独自做。 开发团队必须在工作中时刻谨记 Sprint 目标。为了达成 Sprint 目标,需要实现相应的功 能和实施所需的技术。如果所需工作和预期的不同,开发团队需要与产品负责人沟通协商 Sprint 待办列表的范围。
    每日 Scrum 站会

    每日 Scrum 站会是开发团队的一个时间盒限定为 15 分钟的事件。每日 Scrum 站会在 Sprint 的每一天都举行。在每日 Scrum 站会上,开发团队为接下来的 24 小时的工作制 定计划。通过检视上次每日 Scrum 站会以来的工作和预测即将到来的 Sprint 工作来优化 团队协作和效能。每日 Scrum 站会在同一时间同一地点举行,以便降低复杂性。
    开发团队籍由每日 Scrum 站会来检视完成 Sprint 目标的进度,并检视完成 Sprint 待办 列表的工作进度趋势。每日 Scrum 站会优化了开发团队达成 Sprint 目标的可能性。每 天,开发团队应该知道如何以自组织团队来协同工作以达成 Sprint 目标,并在 Sprint 束时开发出预期中的增量。
    会议的结构由开发团队设定。只要会议专注于达成 Sprint 目标的进展,开发团队可以采 用不同的方式进行。一些开发团队会以问题为导向来开会,有些开发团队会基于更多的讨 论来开会。以下是一个可以使用的范例:
    昨天,我为帮助开发团队达成 Sprint 目标做了什么?
    今天,我为帮助开发团队达成 Sprint 目标准备做什么?
    Scrum Master 教导开发团队将每日 Scrum 会议时间控制在 15 分钟内。
    
每日 Scrum 站会是开发团队的内部会议。如果有开发团队之外的人出席会议,Scrum Master 必须确保他们不会干扰会议进行。
    每日 Scrum 站会增进交流沟通、减少其他会议、发现开发过程中需要移除的障碍、突显 并促进快速地做决策、提高开发团队的认知程度。这是一个进行检视与适应的关键会议。
    Sprint 评审会议
    Sprint 评审会议在 Sprint 快结束时举行 ,用以检视所交付的产品增量并按需调整产品待 办列表。在 Sprint 评审会议中,Scrum 团队和利益攸关者协同讨论在这次 Sprint 中所完 成的工作。根据完成情况和 Sprint 期间产品待办列表的变化,所有参会人员协同讨论接 下来可能要做的事情来优化价值。这是一个非正式会议,并不是一个进度汇报会议,演示 增量的目的是为了获取反馈并促进合作。 对于长度为一个月的 Sprint 来说,评审会议时间最长不超过 4 小时。对于较短的 Sprint 来说,会议时间通常会缩短。Scrum Master 要确保会议举行,并且每个参会者都明白会议 的目的。Scrum Master 教导每位参会者遵守时间盒的规则。
    Sprint 评审会议包含以下内容:
    参会者包括 Scrum 团队和产品负责人邀请的主要利益攸关者; 

    产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”; 

    开发团队讨论在 Sprint 期间哪些工作做的很好,遭遇到什么问题以及问题是如何解决; 
开发团队演示“完成”的工作并解答关于所交付增量的问题; 

    产品负责人讨论当前的产品待办列表的情况。他/她根据到目前为止的进度来预测可 
  能的目标交付日期(如果有需要的话);参会的所有人就下一步的工作进行探讨,这样, Sprint 评审会议就能够为接下了的 
Sprint 计划会议提供有价值的输入信息; 
评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变; 同时为下个预期产品功能或产品能力版本的发布评审时间表、预算、潜力和市场。 
Sprint 评审会议的结果是一份修订后的产品待办列表,阐明很可能进入下个 Sprint 的产 品待办列表项。产品待办列表也有可能为了迎接新的机会而进行全局性地调整。
    Sprint 回顾会议

    Sprint 回顾会议是 Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。
    回顾会议发生在 Sprint 评审会议结束之后,下个 Sprint 计划会议之前。对于长度为一个 月的 Sprint 来说,回顾会议时间最长不超过 3 小时。对于较短的 Sprint 来说,会议时 间通常会缩短。Scrum Master 要确保会议举行,并且每个参会者都明白会议的目的。
    Scrum Master 确保会议是积极的和富有成效的。 Scrum Master 教导大家遵守时间盒的规 则。Scrum Master Scrum 过程负责,作为团队的一员参加该会议。
    Sprint 回顾会议的目的在于:
    检视前一个 Sprint 中关于人、关系、过程和工具的情况如何;
    找出并加以排序做得好的和潜在需要改进的主要方面; 同时,
    制定改进 Scrum 团队工作方式的计划。
    Scrum Master 鼓励 Scrum 团队在 Scrum 的过程框架内改进开发过程和实践,使得他们 能在下个 Sprint 中更高效更愉快。在每个 Sprint 回顾会议中,如果适用并且不与产品或 组织标准相冲突,Scrum 团队计划不同的方式通过改进工作过程或调整完成的定义来提 高产品质量。
    Sprint 回顾会议结束时,Scrum 团队应该明确接下来的 Sprint 中需要实施的改进。在 下一个 Sprint 中实施这些改进是基于 Scrum 团队对自身的检视而做出的适当调整。虽然 改进可以在任何时间执行,但 Sprint 回顾会议提供了一个专注于检视和适应的正式机会。
    Scrum 工件
    Scrum 的工件以不同的方式表现工作任务和价值,可以用来提供透明以及检视和适应的机 会。Scrum 所定义的工件是特别地设计的,是为了给关键信息提供最大透明化,因此每个 人对工件都需要有相同的理解。
    产品待办列表
    产品待办列表是一份涵盖产品中已知所需每项内容的有序列表,它是产品需求变动的唯一 来源。产品负责人负责管理产品待办列表的内容、可用性和排序。
    产品待办列表永远是不完整的。最早开发的产品待办列表列举最初所知的以及理解最透彻 的需求。产品待办列表会随着产品及其应用环境的改变而演进。产品待办列表是动态的, 需要持续更新以反映出产品需要什么来保持其适用性、竞争力和有用。如果产品存在,产 品待办列表也就同样存在。
    产品待办列表列出所有的特性、功能、需求、增强和修复等对未来要发布的产品进行的更 新。产品待办列表项具有这些属性:描述、次序、估算和价值。产品待办列表项通常包括 测试描述,将在“完成”时证明其完整性。
    随着产品的使用、价值的获取和获得市场的反馈,产品待办列表会成长为更大和更详尽的 列表。因为需求永不停止改变,所以产品待办列表就如一份活的工件。业务需求、市场形 势或者技术的变化都会引起产品待办列表的改变。
    多个 Scrum 团队常常会一起参与对同一产品的开发。一个产品只有一个产品待办列表用 于描述下一步产品开发工作。那么这就可能需要使用能够对产品待办列表项进行分组的属性。
    产品待办列表精化指的是为产品待办列表项增添细节、估算和排序的动作。这是一个持续 的过程,产品负责人和开发团队协同工作在产品待办列表项的细节上。在产品待办列表精 化过程中,产品待办列表项被重新评审和修改。Scrum 团队决定如何来完成精化以及何时 来完成。精化的工作通常占用开发团队不超过 10% 的产能。然而,产品负责人或者其他 人在产品负责人的斟酌下,产品待办列表项可以在任何时间来更新。
    排序越高的产品待办列表项通常比排序低的更清晰同时包含更多细节。根据更清晰的内容 和更详尽的细节信息就能做出更为准确的估算;同样,排序越低,则细节信息越少。产品 待办列表项中那些即将会占用开发团队下一个 Sprint 大部分时间的项会被加以精化,因 此,任一产品待办列表项都能够在 Sprint 的时间盒期限内适当地“完成”。这些能够被 开发团队在一个 Sprint 中“完成”的产品待办列表项称为“准备就绪”,它们将作为 Sprint 计划会议中的待选产品列表项。产品待办列表项的足够透明程度通常要经过上述的 精化活动来获得。
    监控目标实现的进度
    开发团队负责所有估算工作。产品负责人可以通过帮助开发团队更好地理解需求,并根据 情况权衡取舍来影响他们,但是最终估算是由开发团队决定的。 在任何时刻,达成目标的剩余工作是可以累计的。产品负责人至少在每个 Sprint 评审会 议中都必须跟踪剩余工作总量。产品负责人比较这次的剩余工作量与之前 Sprint 评审会议时的剩余工作量,来评估在期望的时间点达成目标的进度。这个信息对所有的利益攸关 者都是透明的。
    各种不同趋势走向的实践已经被使用在预测进度方面,例如,燃尽图(burn-downs)、燃 烧图(burn-ups)或者累积流图(cumulative flows)。这些工具都被证实是有用的。然 而,它们并不能用来取代经验主义的重要性。在复杂的环境中,未来将要发生的事是无法 预知的。只有已经发生的事情才能用来做前瞻性的决策。
    Sprint 待办列表
    Sprint 待办列表是一组为当前 Sprint 选出的产品待办列表项,同时加上交付产品增量和 实现 Sprint 目标的计划。Sprint 待办列表是开发团队对于下一个产品增量所需的那些功 能以及交付那些功能到“完成”的增量中所需工作的预测。
    Sprint 产品待办列表将开发团队用来达成 Sprint 目标的所有工作变得清晰可见。为了确 保持续改进,它至少包括一项在前次回顾会议中确定下来的高优先级的过程改进。
    Sprint 产品待办列表是拥有足够细节的计划,任何进度的变化可以在每日 Scrum 站会中 清晰地看到。开发团队在 Sprint 期间修改 Sprint 待办列表,使得 Sprint 待办列表在 Sprint 期间涌现。涌现发生在开发团队按计划开展工作并学习到更多的关于哪些工作是达 Sprint 目标所必需的工作时。
    当新工作出现时,开发团队需要将其加入到 Sprint 待办列表中去。随着工作的执行或完 成,剩余的工作量被估算并更新。当计划中的某个部分失去开发意义,就可以将其移除。 Sprint 期间,只有开发团队可以改变 Sprint 待办列表。Sprint 待办列表是高度可见 的,是对开发团队计划在当前 Sprint 内工作完成情况的实时反映,该列表由开发团队全 权负责。
    监控 Sprint 进度

    Sprint 的任何时间点都可以计算 Sprint 待办列表中所有剩余工作的总和。开发团队至 少在每日 Scrum 站会时跟踪剩余工作的总和,预测达成 Sprint 目标的可能性。通过在 Sprint 中不断跟踪剩余的工作量,开发团队可以管理自己的进度。
    增量
    增量是一个 Sprint 完成的所有产品待办列表项的总和,以及之前所有 Sprint 所产生的增 量的价值总和。在 Sprint 的最后,新的增量必须是“完成”的,这意味着它必须可用并 且达到了 Scrum 团队“完成”的定义的标准。增量是在 Sprint 结束时支持经验主义的、 可检视的和已完成的产品组成部分。增量是迈向愿景或目标的一步。无论产品负责人是否 决定发布它,增量必须可用。


    看板

    看板模型要素
    流程有一个个步骤组成,每个步骤对应一个角色的工作
    工作项在各角色直接移交,经过每一个步骤直到完成
    每个步骤有2个泳道,一个就绪一个进行,未开始工作都在就绪中,
    就绪对垒中的任务需要按照优先级排列
    也可以使用进行中和完成来表示

    研发看板设计


    任务卡片


    缺陷
     
    阻碍发布的缺陷
           这类缺陷在开发完成后被发现,需要修复才能发版本,优先级高,通过粘贴在工作卡片上的红色卡片体现,这也强调了改工作还没有开发完的事实

    对于被修复的缺陷有2中处理方式
    1. 在卡片上用粗笔划去,并保留在工作项上,随着工作项卡片的变动而变动
    2. 将其从工作项上取下来
     
    让缺陷始终留在工作上的做法能够一目了然的看到迭代内完成整理项目的质量,始终保持缺陷与工作卡的关系能清晰的区分那些是已经被修复了的。但是这样做可能会产生较多的过期信息和视觉上的噪音,让其它的更重要的信息不够突出
    如果取下来可以屏蔽噪音,但是失去了物理关联性
     
    是否取下来取决于是否想看历史缺陷,看板可视化的原则就是用丑陋的看板表示丑陋的事情。
    隐藏看板的过期信息
    后期发现的或者不阻碍发布的缺陷,单独写在卡片上
    生产缺陷:
    同上
     
     
     
     
    可视化角色
    在泳道的开始贴上大头贴。
     
    暴露多任务
     
    清楚的反应出有多少人,以及每个人都在做什么,是否有多任务,是可视化的一个重要目的
     
    每个人仅用一个卡片来代表,且仅仅出现在自己的队列中
    工作项卡片重叠表示一个人的多任务
    为进行中队列多设置空间
     
    多任务不要在泳道上规则排,要重叠在一起,表示工作状态
     
    多任务大多数因为当前任务被阻塞了、依赖团队以外的人员支持,或者是被一个优先级更高的工作打断。
    对于阻塞的情况,通过一个便签说明任务被阻塞的原因,这样做有几个好处
      便于其他人了解当前的阻塞任务,提供帮助或者管理跟进
    便于在站会中及时解决问题,当站会中发现没有变迁说明多任务卡片时,现场添加。
     
    提醒自己避免多任务情况
    视觉上让问题突显,更容易被关注
     
    绿色或者蓝色有生气,表示有价值的业务需求
    白色显的中立表示没有直接业务价值的技术任务
    粉色或者红色表示缺陷
    黄色表示阻碍和问题
     
     
    可视化原则
    在看板或者便签上用一直的用色突出分类

     
     





    展开全文
  • 软件开发模式之敏捷开发scrum) 版权声明:本文为博主 android_Mr_夏 原创文章,未经博主允许不得转载。 https://blog.csdn.net/xiajun2356033/article/details/81513957 简介 这几年关于敏捷开发在互联网企业...

    软件开发模式之敏捷开发(scrum)

    版权声明:本文为博主 android_Mr_夏  原创文章,未经博主允许不得转载。 https://blog.csdn.net/xiajun2356033/article/details/81513957

    简介

    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢?

    目录

    1. 什么是敏捷开发?
    2. 传统的开发模式和敏捷开发模式的对比?
    3. 敏捷开发scrum的实施。

    什么是敏捷开发

    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。

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

    传统的开发模式和敏捷开发模式的对比

    瀑布模型: 
    这里写图片描述 
    优点: 
    1. 为项目提供了按阶段划分的检查点。 
    2. 当前一阶段完成后,您只需要去关注后续阶段. 
    3. 它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

    缺点: 
    1. 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。 
    2. 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。 
    3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。 
    4. 瀑布模型的突出缺点是不适应用户需求的变化。

    敏捷模型: 
    这里写图片描述
    优点:

    1. 敏捷开发的高适应性,以人为本的特性。
    2. 更加的灵活并且更加充分的利用了每个开发者的优势,调动了每个人的工作热情。

    缺点:

    1. 由于其项目周期很长,所以很难保证开发的人员不更换,而没有文档就会造成在交接的过程中出现很大的困难。

    敏捷开发scrum的实施

    Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;把一个开发流程的名字取名为Scrum,相当于大家像打橄榄球一样迅速、富有战斗激情。而Scrum就是这样的一个开发流程。

    Scrum开发流程中的三大角色 
    – 产品负责人(Product Owner)

    主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

    – 流程管理员(Scrum Master)

    主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

    –开发团队(Scrum Team)

    主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。

    scrum开发流程图

    这里写图片描述

    1、我们首先需要确定一个Product Backlog(产品需求列表),这个是由PO负责的(如图(一));

    2、有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;

    3、Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

    4、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图)(如图(二)和如图(三));

    5、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本。

    6、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品。

    7、最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;

    如图(一): 
    这里写图片描述

    如图(二): 
    这里写图片描述

    如图(三): 
    这里写图片描述

    如图(四): 
    这里写图片描述

    敏捷开发管理工具:teambition 
    teambition

    展开全文
  • 基于scrum的敏捷开发流程总结

    千次阅读 2018-11-05 16:39:40
    本文主要来源于华为软件开发流程,同时根据在创业团队的实践在细节上稍有修改。 需求管理 先了解几个概念: IR(Initial Requirement):原始需求。这种需求来自客户,一般由产品经理/需求经理编写。如果是研发内部...
  • 浅谈Scrum开发

    2015-04-17 14:17:59
      敏捷开发   以人为核心、迭代、循序渐进的开发方法。它是一种开发方式,开发的流程,主要核心驱动是人,采用的方式是迭代。...只写必要的文档,开发注重的是人与人之间,面与面...Scrum就是这样的一个开发流...
  • 八分钟敏捷开发scrum)扫盲

    千次阅读 2018-08-20 16:54:42
    敏捷开发scrum)是一种软件开发的流程,强调快速反应、快速迭代、价值驱动。 Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;运用该流程,你就能看到你团队高效的工作。 敏捷开发的特点就是...
  • 软件开发模式之敏捷开发scrum

    万次阅读 多人点赞 2018-08-08 19:18:20
    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • 觉得这篇文章写的非常好,非常有助于大家了解敏捷开发,原文链接在下面 https://www.jianshu.com/p/eb8f4448c5c8 什么是敏捷开发? 敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。在...
  • 一只猪的 Scrum 开发经历

    千次阅读 2018-03-20 00:00:00
    本文来自作者 李烨 在 GitChat 上分享 「一只猪的 Scrum 开发经历」编辑 | 本杰明Scrum 是一种方法论,有很多术语、定义、规则。本文不是讲 Scrum 理论,而是从应用的角度,讲述我自身 Scrum 实践的经验体会。...
  • Scrum开发过程

    千次阅读 2012-05-01 20:18:11
    Scrum开发过程 一、 敏捷原则 个体与交互 胜过 过程与工具 可以工作的软件 胜过 面面俱到的文档 客户协作 胜过 合同谈判 响应变化 胜过  遵循计划 这四句价值观用语句表达就是: 自组织团队与...
  • SCRUM开发流程介绍

    2012-02-14 20:48:00
    一、Scrum概述 Scrum是迭代的,增量型的流程。 Scrum构造的产品迭代周期为Sprints,工作的迭代周期一般为一到四周。 Sprints是有固定的周期——结束于固定明确的日期,无论该工作完成与否,从不延长。 在每一...
  • Scrum 开发过程 是什么

    2010-01-23 17:53:00
    Scrum是一个敏捷开发框架,是一个增量迭代的开发过程.。在这个框架整个开发周期由若干个小的跌代周期,每个小的的跌代周期称为一个Sprint,每个Sprint的长度2到4周。在每个Sprint中,Scrum开发团队拿到一个排列好...
  • Scrum 开发过程 是什么

    2010-01-23 17:53:00
    Scrum 开发过程 是...Scrum是一个敏捷开发框架,是一个增量迭代的开发过程.。在这个框架整个开发周期由若干个小的跌代周期,每个小的的跌代周期称为一个Sprint,每个Sprint的长度2到4周。在每个Sprint中,S...
  • Scrum开发基础知识

    2016-05-23 00:26:40
    现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP...   为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum中的各个环节,主要...
  • Scrum开发过程

    2014-12-31 10:35:06
    SCRUM将工业过程控制中的概念应用到软件开发中来,认为软件开发过程更多是经验性过程(Empirical Process),而不是确定性过程(Defined Process)。确定性过程是可明确描述的、可预测的过程,因而可重复(Repeatable)...
  • Scrum开发的简单记述,适合第一次接触Scrum的人
  • Scrum开发过程一页纸

    2019-07-12 10:16:49
    团队采用Scrum作为开发方法,非常有效,我会写一系列的文字来介绍 1. 产品负责人从客户、市场、高层等渠道收集和梳理需求,建立条目化的产品待开发项列表,包含众多用户故事 2. 冲刺计划会上,...
  • 原文:http://www.almnetworks.net/zh-CN/post/2010/07/13/Professional-Scrum-Developer.aspx 本文已经被MSDN转发至:... 微软在今年4月发布了全新的开发人员工具和团队协作平台Visual Studio 201...
  • Scrum开发模式

    2012-08-09 09:26:40
    一个story,两个sprint,这个有些令人困惑的需求的功能折腾的小累了。 内功外功均需修啊。

空空如也

1 2 3 4 5 ... 20
收藏数 24,097
精华内容 9,638
关键字:

scrum开发