精华内容
下载资源
问答
  • scrum敏捷开发

    2018-09-07 23:57:51
    scrum敏捷开发,极限编程,sprint划分,站立会议,团队建设等。
  • Scrum敏捷开发

    2019-11-12 15:21:38
    什么是Scrum敏捷开发 Scrum是敏捷开发的一种,是一种以人为本,迭代式增量软件开发的过程,以英式橄榄球争球队形(Scrum)为名,因此可以想象,整个团队是高效而富有激情的。以人为本,即Scrum开发特别强调沟通,...

    什么是Scrum敏捷开发

    Scrum是敏捷开发的一种,是一种以人为本,迭代式增量软件开发的过程,以英式橄榄球争球队形(Scrum)为名,因此可以想象,整个团队是高效而富有激情的。以人为本,即Scrum开发特别强调沟通,要求团队所有人员都坐着一起工作,通过高效的沟通解决问题。

    为什么要敏捷开发

    传统的软件公司大都是使用瀑布开发模式,流程是以下这样的:

    瀑布开发模式

    瀑布开发模式一般都需要很久的开发时间才能交付,笔者目前所在公司,以前开发产品都是利用瀑布开发模型,往往需要至少三个月到半年的开发周期,而过程往往都是这样的:产品经理完成一款产品的所有需求—UE设计出原型和视觉— 开发完成开发— 测试完成— 产品经理和UE验收的时候永远是一副不可思议的惊讶表情,觉得交付的产品和自己当初的设计相差甚远,这个时候就会出现很纠结的事情,改?还是不改?改,牵扯到软件结构,项目周期,交付时间等一系列问题;不改,产品最终效果无法交付。因此最终的结果都会是稍微改一点,即产品结果接近而不同于原本需求,所要增加的人力和时间成本又不会太高。另外还有一种情况,就是开发过程中遇到不可抗拒的需求变更,这个时候对开发的架构、交付日期都有非常大的影响,经常出现一个变更导致前3个月甚至更久的工作返工白做,而这个时候浪费的成本是非常大的。久而久之,会发现每次的产品开发都是这样一种令人疲惫的模式。

    上述这种情况,我相信有很多团队都会遇到,而且很普遍。当然这里有最大的问题是,产品经理和UE交付了需求和设计之后,则和开发团队的沟通变得很少,开发和测试团队遇到问题,也很少和产品经理沟通。这里原因很复杂,可能和人有关,可能和公司文化或者公司流程有关。当然,这不能说是瀑布开发模型的错,只能说瀑布开发模型比较容易出现这种问题,原因很简单,开发周期越久,不可控的因素和风险就越大,最终的结果就越容易偏离最初想法。

    而敏捷开发的流程是这样的:

    迭代瀑布

    可以看出和瀑布开发模型的区别了吗?就是将一个完整的瀑布开发过程切成很多个短的,迭代式的瀑布开发过程,即迭代瀑布。那么这么做,就一定能解决上述遇到的问题吗?本文将在最后给出答案。

    Scrum的模式和流程

    标准的Scrum开发模式

    以下是标准的Scrum开发模式:所有的需求都到达PO/PM这里,整理出Product backlog,每次的迭代开发(Sprint)都是PO/PM从Product backlog里挑出需要开发的部分需求,然后团队一起开planning meeting,确定出sprint backlog及交付日期。接下来利用2到4周的时间进行开发和测试,其中每天都要开站会(Scrum meeting),团队内部成员在这个会议上了解整个迭代的进展情况,最终交付后,团队一起开sprint review和retrospective会议,而这整个过程都有一个很关键的角色Scrum Master来把控和组织。

     

    标准Scrum开发模式

    这样描述可能还不太理解,下面则进行详细的分类描述。

    开发周期

    Scrum开发一般建议为2-4周为一个周期,以两周为例,整个时间线大概如下,可以看到第一个迭代的结束和第二个迭代的开始是有重合部分的。

     

    Scrum开发周期

    三三四原则

    Scrum开发有一个“三三四”原则,即三个角色、三个产出物、四个会议:

    • 三个角色:PO、Scrum Master、Dev Team

      • PO:Product Owner,一般都是产品经理,负责需求分析和整理、分解验收story、维护Product backlog等(关于backlog和story会在下面有详细的描述)。
      • Scrum Master:扮演推动者的角色,他要负责主持会议、协助团队内部成员解决困难、解决外部对团队内部的过分干扰、和外界的主要沟通工作等。Master可以由专门的人来担当,也可以由团队内部的成员来担当,很多团队都是由PO来同时兼任Master,笔者建议由团队内部成员轮流担当,这样能够培养团队成员的责任感,增强团队的凝聚力,并让大家更加容易理解敏捷开发的精髓。
      • Dev Team:整个开发和测试团队,包括UI设计师等所有相关人员。
    • 三个产出物:Product Backlog、Sprint Backlog、Potential Shippable Product Increment

      • Product Backlog:产品需求池
      • Sprint Backlog:此次需要开发的需求集合
      • Potential Shippable Product Increment:可交付的结果
    • 四个会议:Sprint Planning、Daily Scrum Planning、Sprint Review、Sprint Retrospective

      • Sprint Planning:需求评审会和迭代启动会,这个会议上,需要得出以下结论:

        • 全员明确清晰的迭代目标
        • 澄清所有的需求及技术实现风险
        • 评估需要的工作量,以及需要投入的人员
        • 确定出所有最终需要发布的功能集合及工作量,需要将Story拆解成Task,以小时为单位。
      • Daily Scrum Planning:每日站会,顾名思义,就是站着开会,大家围成一个圈或者半圈,这样做有两个目的,一个是高效,另一个是可以方便团队所有人都可以看见对方。站会的目的有以下3个:

        • 监督个人的承诺:确认个人是否完成昨日的目标
        • 培养团队文化
        • 了解项目进展:团队中每个人都应该了解其他人在做的事情,以及当前团队的进展和风险。最实际的好处就是这样可以清楚的知道别人做的事情是否对自己有影响,或者自己是否可以提供帮助等。

        站会的时间,建议不超过15分钟,只描述状态和任务,不讨论技术细节,另外,每个人围绕以下3个话题来简单描述自己的进展:

        • 昨天完成了什么?
        • 目前有什么困难,需要帮助的?
        • 今天准备做什么?

        站会的时候,Scrum Master一定要注意以下问题:制止不必要的讨论、禁止小会、控制发言时间、不要跑题等,另外,站会的时候,Master需要修改燃尽图(后面会有对燃尽图的详细描述)。

      • Sprint Review:迭代评审会,此次会议的主要内容是相关利益者及团队成员展现本次迭代的功能增量,需要注意的是不展示未完成的功能,也不需要PPT,演示结束后记录好相关反馈。很多采用敏捷开的团队都不开Review会议,其实Review会议是有一定的好处和目的的:

        • 可以让团队的成果得到认可,提升团队的自我价值感
        • 其他人可以了解团队在做的事情
        • 可以吸引一些利益相关者的注意,并得到一些反馈
        • 演示能够对团队成员造成的一定的压力,迫使团队认真完成工作
      • Sprint Retrospective:迭代回顾会,会议主要是回顾此次迭代的整体情况,一定要全员参加,一起回顾此次迭代做的好的地方,以及需要改进的地方,并对这些需要改进的点,提出改进措施。

    Product Backlog & User Story

    • User Story:即用户故事,是一个解决用户某个问题的,对用户有价值的,某个功能的,一目了然的描述。这里有一个理念需要注意,即多个小故事胜过一个庞大的故事,因此User Story的描述非常重要,好的用户故事具备INVEST原则:

      • Independent:可以独立开发
      • Negotiable:可以协商
      • Valuable:有价值
      • Estimable:大小可评估
      • Sized appropriately:合适粒度
      • Testable:可测试验证的

      User Story的描述一定要站着用户角度,而且一定要注意颗粒度,一般以这种格式”作为一个<角色>,想要<活动>,达到<目的>”来描述。另外,根据经验,笔者建议描述的时候可以不用这种句式,但是思考的时候一定要这样思考,因为所有事情,过分的追求形式就会失去他本身的价值,但是从这个角度去思考每一个需求和功能点,对产品经理分析需求确实有非常大的帮助。接下来举几个User Story的例子:

      “图片编辑功能“:不是一个好的User Story,首先颗粒度太大,其实大小不可评估,因此需要对这个需求做拆分,拆分成小的User Story;

      ”作为一个喜欢自拍,又希望自己可以拍出来比较白的用户,可以通过图片编辑的美白功能,使自己看起来白一点“:该Story是一个比较好的User Story,当然,思考这样思考,记录的时候,完全可以简单描述为”图片编辑增加美白功能“。

      User Story的分解是一个技术活,对产品经理是有一定的要求的,当然,一切从用户角度出发,多思考用户场景,那么这个问题也就也就没有那么难了。

    • Product Backlog:User Story的集合,即产品需求池,这里面包含所有和该产品相关的需求,根据笔者经验,这些需求最好包含以下状态:need to check、pending、reject、planning、developing、released、wait to dev,这些状态基本包含了一个需求的所有可能的状态,对产品经理管理需求有非常大的帮助。

    看板 & 燃尽图

    看板一般是一个物理白板,目的是做迭代进展可视化跟踪和协作沟通。看板上需要将每个人的任务,以对应的状态(To Do/Not checked out、Doing/Checked out、Done)展示出来,一般使用便签纸。

    同时要在白板上画出燃尽图,燃尽图指示的是当前剩余的工作量,是一个跟踪项目进展非常好的指示器。燃尽图上一般有2条曲线,如下图的燃尽图,灰色的直线表示的是最优剩余工作量曲线,蓝色的表示实际的剩余工作量曲线,正常情况下,蓝色的线应该在灰色的线上下浮动,并在最后一天合到同一个点上。燃尽图可以在每天站会的时候由PO更新状态。

    看板&燃尽图

    关于看板和燃尽图,有以下一些需要注意的点:

    • 每个功能通过测试,且PO认可,才算结束;
    • 白板上也要讲测试、UE等的任务放上去;
    • bug修复的任务可以估算出工作量,作为单独的任务放在看板上;
    • 延期的任务,应该注明延期天数;
    • 只有完成的任务才在燃尽图中删减工作量,所以,如果增加了工作量,燃尽图的曲线可能会向上。

    一定要注意的问题

    上述基本将Scrum敏捷开发的核心内容和工作流程描述完全,那么在实际操作过程中,难免会遇到各种问题,下面笔者将根据经验,提出实操过程中需要注意的事项:

    • 关于团队,Scrum敏捷开发原则上是需要团队所有人坐在一起的,但是实际情况中,难免遇到异地问题,异地问题确实会对Scrum的实施过程造成一定的困难,并且也会将效果大打折扣。百度为了解决这个问题,研发了专门用于解决异地敏捷开发的显示器和看板工具,团队每天面对显示器进行开会和状态沟通。当然,大部分团队是没有这种条件的,但是现在有很多在线Scrum开发工具来跟踪状态代替看板,比如Leangoo、禅道等,站会大家无法面对面,最简单的办法只能是采用电话会议。不过笔者建议,在需求启动会、回顾会和评审会的时候,团队部分成员最好出差,确保团队所有成员可以面对面来开会,否则只要无法面对面,就会有大量的潜在风险,导致Scrum开发变成形式主义。但是,只要团队没有坐在一起,Scrum开发就会大打折扣,所以异地团队在实行Scrum开发的时候需要做好这个心理准备。
    • 站会的时候,一般可以由PO来移动任务卡片,这里建议由团队成员分别移动自己的卡片,这样做的好处是,可以培养成员的责任感,并在发生delay的时候,造成一定的压力。
    • Scrum开发的团队成员一般建议在7人左右,不要超过10人,如果团队成员太多,建议分成小的Scrum团队,然后每个Scrum团队的PO再聚到一起沟通状态。如果每个Scrum团队的成员过多,很容易造成效率的低下和沟通问题。
    • Scrum强调的是团队,因此是整个团队成功或者失败,而不是某个人,需要和团队的成员强化这个观念,来培养团队的责任感。
    • 需求评审会一定要确保所有人对需求完全了解,并达成一致的认可。不要觉得在开发过程遇到需求不理解再进行沟通,这样会给此次迭代带来非常大的风险。
    • 很多情况下,站会往往会变成”汇报会“,即团队成员向PO汇报工作,并且成员并不听别人在讲什么。因此,首先从PO这里,需要注意不要给团队一种压迫式的听取汇报的感觉,并且,刻意地将站会培养成沟通会。
    • Task的分解一定要注意工作量,工作量越大就会潜在越多不可控的风险,因此原则上,每个task不能超过8小时。
    • 测试人员在Scrum开发中,很容易被遗漏掉,而导致测试过程中出现风险,比如不清楚需求,测试case没有按期编写完成导致测试delay等。因此从一开始需求评审的时候,就要注意除了开发人员,测试人员也要对需求完全理解。
    • SW和VAL人员的沟通不积极,经常需要Scrum master或者其他人推一把,这个是很多传统的IT公司的通病,尤其是进行瀑布开发时有非常严格的开发流程的公司,这种问题更加严重。工程师往往习惯了在系统上提交bug,查看bug,通过在系统上添加comment沟通的形式,而Scrum开发,强调的就是通过面对面沟通来提高效率。因此当团地成员出现沟通问题时,Scrum Master一定要提出来进行告诫。
    • 产品的质量大于需求,这点是很多产品经理往往忽略的,和Scrum开发无关,而是做产品的基本要求。因为很多团队在开发的时候,产品经理为了快速将需求投入市场,而忽略的产品本身的质量,结果导致用户对产品较低的评价甚至产品死亡。Google数据称,Play Store上60%的差评是因为产品质量。
    • 以上提到的所有问题,或者这里没有提到的,Scrum开发中可能遇到的各种问题,最直接的解决办法就是”提高工程师的意识'',当然,这是最简单,也是最困难的解决办法,需要时间以及Scrum master的培养。

    敏捷带来的价值

    • 快速响应变化,及时响应用户反馈,调整优先级:Scrum开发可以完全适应现在互联网开发里的”小步快跑“,以轻量级的Story作为需求进行迭代式开发,保证最重要的总是优先做。
    • 可以持续向用户交付有价值的软件产品,以及短的软件交付周期:这是现在的互联网开发的基本要求,就是不停的通过每次迭代和升级,进行产品的优化和提升。
    • 项目团队的透明性:团队所有成员都可以完全了解当前的项目进展和问题。
    • 低的软件成本:Scrum开发可以让产品快速试错,即使错了,浪费的也最多是一个迭代的资源,而不会像瀑布开发,有可能浪费的是好几个月的资源。
    • 高的投资回报率:以较低的成本,和高效的模式进行产品的迭代,回报率当然会较高。

    总结

    首先,回顾下文章一开始的问题,文章开始提到瀑布开发模型容易遇到的2个问题;

    第一,开发结束时,交付产品无法达到预期:Scrum开发将开发周期缩短到了2到4周,并且每天通过站会的形式进行状态的沟通和跟踪,团队成员通过沟通来解决问题,这些工作方式理论上可以完全避免这种问题的出现。

    第二,不可抗拒的需求变更,导致大量的资源浪费:根据上述敏捷带来的价值,我们可以看到,小步快跑+快速试错,即使浪费,最多也只是浪费2-4周的资源。

    当然,Scrum开发只是帮助团队减少上述问题的出现概率,而非完全解决,这里的核心不是瀑布开发模式或者Scrum开发模式,而是团队责任感和意识的问题,没有责任感的团队,无论如何使用Scrum开发模式,也只会到徒有其表,甚至可能造成反作用,团队成员为了敏捷而敏捷,没有交付出好的产品,反而在这些形式上浪费大量的时间。所以,敏捷开发不是万能钥匙,有些领导一听说敏捷开发,就要团队去实行,结果往往造成更大的问题,因此,团队出现任何问题,都首先要从根本出发,寻找问题原因,再进行对症解决,Scrum开发模式只是办法之一。

    另外,Scrum开发里所有的工具和方法都只是协助,不要过分的依赖形式很重要,敏捷只是一种方法和理念,或者说是一种态度。现在很多互联网公司,虽然没有在嘴上每天吵着敏捷开发,没有看板,也没有站会,或者将Scrum开发的流程“本土化”,但是他们依然敏捷,依然可以高效的开发和产品迭代,原因很简单,使用了敏捷工具和流程并不是真正的敏捷,“敏捷意识”最重要。



    作者:Monica_Wang
    链接:https://www.jianshu.com/p/89e59933caad
    来源:简书
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    展开全文
  • SCRUM敏捷开发

    2016-07-31 07:18:48
    由于团队最近计划执行不顺利,项目经理在知道我经历过敏捷开发的流程后,让我给团队内部的各个小组分享SCRUM敏捷开发相关的知识,并负责推动团队敏捷开发计划的建设。  scrum 是一种迭代增量软件开发方法,通过该...

             由于团队最近计划执行不顺利,项目经理在知道我经历过敏捷开发的流程后,让我给团队内部的各个小组分享SCRUM敏捷开发相关的知识,并负责推动团队敏捷开发计划的建设。

              scrum 是一种迭代增量软件开发方法,通过该方法,你可以量化工作量,并且可以把每个任务量化成具体时间,得出最后一个项目的总时间(一般估算到小时)。能让管理者看清楚项目进度,把握项目进程的各种问题。scrum简单易用,但是简单的东西要掌握就容易犯错,大家可以在尝试中掌握这种项目管理方法,以下是我做内部培训个人写的教程,抛砖引玉,希望能普及该方法。

             什么是Sprint??

            Sprint是短距离赛跑的意思,这里面指的是一次迭代,而一次迭代的周期是1个月时间(即4个星期),也就是我们要把一次迭代的开发内容以最快的速度完成它,这个过程我们称它为Sprint。

            在scrum里面,有3种角色,分别是product owner(产品负责人)scrum master(团队负责人)scrum team (开发团队):


      Product owner:是需求方,提出需求,能对功能流程,业务流程拍板的人。


      Scrum master :团队负责人,一般是product manager,负责解决团队问题,领导项目。


      Scrum team:项目执行人员,开发项目一般包括,前端后端开发,ui等。


            scrum的流程如下:

          Scrum 步骤一:

      头脑风暴,如果product owner 对产品需求非常清楚,就可以省略这个步骤,开发一个原则“先紧后松”, 必须先把需求了解清楚,这里product owner可以召集技术团队/用户群体对其需求进行公开征求意见,最后输出一个产品建议表。

      Scrum 步骤二:

      product owner 对产品建议表进行筛选,做减法提炼最核心的需求。在确定了需求后,这个时候由scrum master 进行输出prd (product requirement document) , 这里就和传统的瀑布流一样了,该有的文档都必须有了,必须由scrum master 和product owner 确定好需求,包括业务逻辑,功能流程等。

          

         Scrum 步骤三:

      原型,ui设计都不是在步骤二完成的,把任务量化,包括,原型,logo设计,ui设计,前端开发等。

      尽量把每个工作分解到最小任务量,最小任务量标准为工作小时不能超过8小时。准备估算总体项目时间吧!

      把每个任务都贴在任务看板上面,看板上分为四部分:

      (1)to do待完成

      (2)doing 正在做的

      (3)done 已完成的

           (4)Cancel  推迟的

           

         如何估算时间:玩扑克游戏这个方法估算出来的工作时间比较准,参与扑克游戏的最好有专家和开发涉及到的人员。

      扑克游戏玩法:

      (1)每个人发一部扑克牌,使用扑克牌来进行打分,扑克牌的面值分数有1分、2分、3分、5分和8分,1分代表1小时的工作量。

      (2)同时展示该项目完成时间,肯定存在最大最小的工作时间,最大最小两个人请你们辩论吧,为什么要那么长时间完成,或者那么短时间完成,其他人可以提出疑问,在一定程度上达成认可。

      (3)进行再次私下对该任务写时间,再公示,再辩论,这样下去,大家写出来的该任务的时间越来越接近了。

      (4)最后达成一个共同认可的时间,这个就是该任务的工作时间!

      

       Scrum 步骤四:

      经过大家纠结讨论了好久,终于把任务量化到具体多少时间完成了!接下来,把n个任务按照开发的重要度,组合成n个sprint( 冲刺),每次执行一个sprint。


           每个sprint 都是独立的,一般先做主要功能,再到次要功能,再到小功能,最后的sprint 一般是修复bugs。

           因为任务都被量化了,每天工作了多少小时,完成了多少任务量,通过每天例会scrum master非常清楚,并且在时间燃尽图进行表示。我们就可以直观看到任务的进度了,而且是具体到多少小时!


             通过时间燃尽图可以可视化任务的时间进度,大家可以看下图,day1 是整个任务的总共时间,每天按照任务完成度更新剩余时间,或者增加时间(例如发现一个技术难点,团队成员请假等要增加开发时间)。


             Scrum 步骤五:

            需要进行 每日站立会议,每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 时间燃尽图。

          

           Scrum 步骤六:

          当一个Story完成,也就表示一次Sprint完成,这时,我们要进行演示会议,也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);最后就是 回顾会议,也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中。

    展开全文
  • scrum 敏捷开发

    2019-03-06 09:32:47
    之前的博客中涉及原理和技术方面的内容较多,本篇博客主要谈一谈经常提到的敏捷开发scrum敏捷开发 相信大部分人都学过瀑布开发模型,它是以文档为驱动的,在瀑布的整个开发过程中,要写大量的文档,把需求文档...

    引言

    之前的博客中涉及原理和技术方面的内容较多,本篇博客主要谈一谈经常提到的敏捷开发和 scrum。

    敏捷开发

    相信大部分人都学过瀑布开发模型,它是以文档为驱动的,在瀑布的整个开发过程中,要写大量的文档,把需求文档写出来后,开发人员都是根据文档进行开发的,一切以文档为依据;而敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。

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

    核心原则:

    • 主张简单
    • 拥抱变化
    • 第二个目标是可持续性
    • 递增的变化
    • 令投资最大化
    • 有目的的建模
    • 多种模型
    • 高质量的工作
    • 快速反馈
    • 软件是主要目标
    • 轻装前进

    常用工具:

    • Visual Studio Team Foundation Server
    • Atlassian Jira
    • Axosoft
    • LeanKit
    • Planbox

    scrum

    Scrum是一个偏重于过程的敏捷开发的具体方式。

    Scrum开发流程中的三大角色:

    1. 产品负责人(Product Owner)

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

    1. 流程管理员(Scrum Master)

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

    1. 开发团队(Scrum Team)

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

    在这里插入图片描述

    Scrum的开发流程:

    1. 首先需要有一个 Vision ,就是所做的产品或者所做项目的愿景。这个需要所有 Team Members,包括 Product Owner 一起确定,然后大家朝着同样的目标前进。
    2. 维护 BacklogVision 出现后,Product Owner 会维护一个 Scrum 中我们提到的第一个文档,即 Backlog。它可以理解成从产品当中,从各个角度收集的需求, Product Owner 要做的事情就是维护 Product Backlog,并且将 Backlog 一条一条的按照优先级排好顺序。Product Owner 是唯一有权利维护这个列表的人。这个时候合理利用工具,就能免去写文档的的这一步,可以直接将需求通过任务的方式收集,每个需求就是一条任务,Product Owner 可以给任务打标签来标示优先级。
    3. 拆分 Sprint ,随后团队成员会针对这个 Scrum 把它拆分成一个个的 Sprint ,就是开发周期。然后将 Backlog 里面的项目添加到 Sprint 中去,成为 Sprint Backlog。每一个 Sprint 开始的时候,需要进行一个Sprint Plan。
    4. 运行 Sprint Plan,Sprint Plan 就是整个团队一起,通过 Backlog 从优先级最高的这个item 开始挑,挑出 ProductOwner 对Backlog 进行介绍。紧接着的是,大家将 Backlog 拆分成单个的Task,每一个成员在每一天的工作当中领 Task,完成 Task。
    5. 在 Scrum run 起来之后,还有一件事情是 Daily Scrum 。在 Daily Scrum 中,每个成员只需三件事情:我今天做了什么,明天要做什么,有什么是我搞不定的。Daily Scrum 一般来说会控制在15分钟之内,而且所有的成员必须要站着开会。
    6. 当 Scrum 结束后,每个成员会产出一个产出物。这个产出物在 Scrum 里面,可以是一个可以运行的软件,也可以是一个可展示的功能。之所以这么说是因为有一个Sprint Rview 的阶段,需要通过 Demo 在 Product Owner 以及其他的 Stake Holders 面前,现场演示你做好的东西。
    7. 在 Sprint Review 结束之后就是 Retrospective。整个团队的人都要坐下来聊一聊,Sprint 做得好不好,有哪些地方需要修改。

    参考

    https://baike.baidu.com/item/敏捷开发
    https://www.zhihu.com/question/19638322/answer/107371902

    展开全文
  • 敏捷思维:价值观、原则、定义;Scrum概要、框架及流程等;
  • SCRUM敏捷开发框架.ppt

    2021-03-04 09:48:32
    SCRUM敏捷开发框架.ppt
  • SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问...
  • Scrum敏捷开发.ppt

    2021-09-18 16:42:58
    Scrum敏捷开发.ppt
  • Scrum 敏捷开发

    2018-01-22 15:15:17
    Scrum 是一个用于开发和维护复杂产品的框架 Scrum 是一个用于开发和维护复杂产品的框架 ,是一个增量的、迭代的开发过程。在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint,...

    Scrum 是一个用于开发和维护复杂产品的框架

    Scrum 是一个用于开发和维护复杂产品的框架 ,是一个增量的、迭代的开发过程。在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint,每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中,使用产品Backlog来管理产品的需求,产品backlog是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中,Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表,我们称它为Sprint backlog。在每个迭代结束时,Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目,但它适用于任何复杂的或是创新性的项目。

    Scrum流程如下图:

    Scrum流程

    Scrum框架包括3个角色、3个工件、5个事件、5个价值

    3个角色

    1. 产品负责人(Product Owner)
    2. Scrum Master
    3. 开发团队

    3个工件

    1. 产品Backlog(Product Backlog)
    2. SprintBacklog
    3. 产品增量(Increment)

    5个事件

    1. Sprint(Sprint本身是一个事件,包括了如下4个事件)
    2. Sprint计划会议(Sprint Planning Meeting)
    3. 每日站会(Daily Scrum Meeting)
    4. Sprint评审会议(Sprint Review Meeting)
    5. Sprint回顾会议(Sprint Retrospective Meeting)

    5个价值

    1. 承诺 – 愿意对目标做出承诺
    2. 专注– 把你的心思和能力都用到你承诺的工作上去
    3. 开放– Scrum 把项目中的一切开放给每个人看
    4. 尊重– 每个人都有他独特的背景和经验
    5. 勇气– 有勇气做出承诺,履行承诺,接受别人的尊重

    SCRUM理论基础

    Scrum以经验性过程控制理论(经验主义)做为理论基础的过程。经验主义主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。

    Scrum 的三大支柱支撑起每个经验性过程控制的实现:透明性、检验和适应。Scrum的三大支柱如下:

    第一:透明性(Transparency)

    透明度是指,在软件开发过程的各个环节保持高度的可见性,影响交付成果的各个方面对于参与交付的所有人、管理生产结果的人保持透明。管理生产成果的人不仅要能够看到过程的这些方面,而且必须理解他们看到的内容。也就是说,当某个人在检验一个过程,并确信某一个任务已经完成时,这个完成必须等同于他们对完成的定义。

    第二:检验(Inspection)

    开发过程中的各方面必须做到足够频繁地检验,确保能够及时发现过程中的重大偏差。在确定检验频率时,需要考虑到检验会引起所有过程发生变化。当规定的检验频率超出了过程检验所能容许的程度,那么就会出现问题。幸运的是,软件开发并不会出现这种情况。另一个因素就是检验工作成果人员的技能水平和积极性。

    第三:适应(Adaptation)

    如果检验人员检验的时候发现过程中的一个或多个方面不满足验收标准,并且最终产品是不合格的,那么便需要对过程或是材料进行调整。调整工作必须尽快实施,以减少进一步的偏差。

    Scrum中通过三个活动进行检验和适应:每日例会检验Sprint目标的进展,做出调整,从而优化次日的工作价值;Sprint评审和计划会议检验发布目标的进展,做出调整,从而优化下一个Sprint的工作价值;Sprint回顾会议是用来回顾已经完成的Sprint,并且确定做出什么样的改善可以使接下来的Sprint更加高效、更加令人满意,并且工作更快乐。


    转载:http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html

    展开全文
  • Scrum 敏捷开发 中文指南,2018年最新版。
  • 用leangoo做Scrum敏捷开发。欢迎大家下载。
  • Scrum 敏捷开发ppt 实用篇
  • 正好借此机会试一下我心怡已久的Scrum敏捷开发了。郁闷的是老大表示我们有两个项目要同时进行,当下心里就想就我们技术部这点人,还要两个项目一起开发,那怎么可能,先说下我们的部门的人员情况:我,自认为技术...
  • scrum敏捷开发流程框架
  • SCRUM敏捷开发教程

    2019-07-05 16:56:38
     scrum敏捷开发,是一个美国统计学教授记录了多年工作经验,总结出来的一套简单易懂的开发方法,我接触过不少产品经理,惊奇发现不少产品经理的确是产品把控的非常好,输出的BRD,MRD,PRD等都非常专业,但是却没一套...
  • Scrum敏捷开发流程

    千次阅读 2017-05-01 14:17:41
    Scrum敏捷开发流程的要点
  • SCRUM敏捷开发规则一栏
  • Scrum敏捷开发模式;目录;培训目的;我们的背景;Scrum敏捷开发方法简介;沟通不及时之困推到角色墙组建多角色分层敏捷团队;推到角色墙组建多角色分层敏捷团队;推到角色墙组建多角色分层敏捷团队;推到角色墙组建多角色...
  • Scrum敏捷开发模式 在研发团队的应用 郑成龙 2015年8月 目录 培训目的 我们的背景 Scrum敏捷开发方法简介 Scrum敏捷开发整体解决策略 沟通不及时之困推到角色墙组建多角色分层敏捷团队 需求不稳定之困分阶段细化需求...
  • Scrum敏捷开发的关键字就是增量、迭代,他更重视项目团队之间的现场沟通,不向传统瀑布式开发那样需要万事具备,才开始开发,Scrum在大方向和小故事点确认好了后,团队就可以开动了。Scrum的团队一般都不大,一Scrum...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 20,590
精华内容 8,236
关键字:

scrum敏捷开发