scrum敏捷_scrum敏捷开发 - CSDN
精华内容
参与话题
  • 敏捷其实很简单3---敏捷方法之scrum

    万次阅读 2017-11-17 09:09:43
    可以说敏捷开发的所有理念,思想,方法都来源于敏捷宣言,所有想要实施敏捷,要先理解敏捷宣言。那么经过上面的文章,我们大家都知道了敏捷实际上是一种理念,一种思想的转变,从传统的开发模式进入到新的以价值为...

    通过上图我们可以看到Scrum作为各种敏捷实践方法中最为常用的一种,今天我们也来聊一聊Scrum。

    Scrum的历史可以追溯到1986年《哈佛商业评论》中的一篇文章《新型的新产品开发策略》(The New New Product Development Game,竹内弘高、野中郁次郎,1986)。这篇文章描述了像本田、佳能、富士施乐这样的公司是如何通过可伸缩、基于团队的并行产品开发方式开发出了世界一流的产品。文章同时强调了授权、自组织团队的重要性,并概要描述了管理在开发过程中发挥的作用。

    当然,SCRUM这个词没有什么标准的中文解释,它是来源于橄榄球中的一个争球的动作,如下图。

    竹内弘高和野中郁次郎在New New Product Development Game文章首次提到将Scrum应用与产品开发,他们指出:传统的“接力式”的开发模式已经不能满足快速灵活的市场需求,而整体或“橄榄球式”的方法——团队作为一个整体前进,在团队的内部传球并保持前进,这也许可以更好的满足当前激烈的市场竞争。



    上图是SCRUM的一个典型架构图,我们可以看到里面有很多要素,下面我们一一介绍这些要素。




    Scrum的3355



    3个角色



    Product Owner:产品负责人,清楚的知道产品的愿景,需要对产品待办列表的梳理,优化,优先级排序等负责。决定团队每个冲刺要完成哪些任务。对于团队非常重要,决定Why和What。一般可以对应为现有的产品经理和BA的角色。



    Scrum Master:Scrum MasterScrum教练和团队带头人,确保团队合理的运作Scrum,并帮助团队扫除实施中的障碍。



    Team:可以认为是开发团队,但是一个跨职能的团队,能够交付一个端到端的真正对客户有价值的产品。


    3个工件



    Product Backlog:是指产品待办事项的集合,其中事务有优先级判断,先处理优先级高的事项。产品待办列表源自于Scrum方法。在Scrum中,产品主管(Product Owner)收集来自于各方的需要、期望、诉求等等到产品待办列表中,给定优先级;当冲刺计划会议上,团队从产品待办列表中挑选其中事项组成冲刺待办列表。常见的待办事项表达形式是用户故事



    Sprint Backlog:每个迭代的功能开发列表,PO会根据团队的能力并按照产品待办列表中的优先级来选取每个冲刺要做的事情。团队可以专注在每个迭冲刺要走的事情上而不被打断。



    Burndown chart:燃尽图,在每个迭代显示剩余工作时间和任务完成情况。


    5个价值观



    专注:每个迭代只专注于迭代要完成的事情,团队和个人的能力和精力是有限的,在有限的时间内专注于最有价值的事情,以取得好的结果。

    勇气:要有勇气去面对各种挑战。

    公开:团队所有的进展,问题,阻碍都是对所有人可视化,透明的。这样的团队才是彼此尊重。同时也能暴露问题。

    承诺:作为一个自组织团队,在迭代开始的时候做出承诺,并在迭代中全力完成。

    尊重:团队是长期坐到一起,并且稳定的,有助于加深彼此的了解和沟通。


    5种工件



    Sprint:冲刺,一个固定的时间周期(通常为2w-4w),团队要尽可能在这个周期内交付可以工作的软件给客户

    sprint planning meeting:冲刺开始的时候,PO会和团队一起从PB中选择本次要做的任务/故事,并且会对团队提出的疑问进行解释和澄清。同时团队会估算故事并分解成任务,最后会形成本次的Sprint Backlog.

    daily standupo meeting:每日站会,scrum为了加强团队沟通,每天团队都要选择一个时间站在一起,互相交流彼此的进展和问题,以便及时解决出现的问题,同时也能让团队随时了解我们离冲刺目标还有多远。

    sprint review:在sprint周期最后,需要进行一次评审会议,让团队向产品负责人和利益相关者展示已完成的功能。sprint审核的大部分实践用于团队成员展示功能、回答利益相关者对展示的疑问并记录所期望的更改。评审会议可以吸引相关利益者的关注,让其他人了解团队在做些什么,并得到重要反馈。做演示也会迫使开发团队真正完成一些工作。

    retrospective meeting:回顾会议,通常在reivew会议之后开始,有团队成员在冲刺结束之后对上个迭代进行总结,同时提出一些改进方案,这是一个持续改进的过程。


    SCRUM的其他一些要素:

    user story:用户故事,因为敏捷要求每个特性都是对客户有价值的,所以以用户故事的方式来设计特性,通常是作为客户,我要实现A功能,以至于我可以达到什么目的的结构。

    task:每个迭代中为了开发一个user story,将其分解为一些task,比如说我要开发一个协议,其中需要几个task,包括搭建服务器,找一些开源代码,搭建自动化测试框架,编码,测试任务,便于更小粒度的track每个迭代的进展。

    release planning:在某些大型组织,可能更关注release级别的产品交付,所以每个release之前要进行整个release的plan,决定这个release的PB。

    points:故事点数,代表用户故事的大小,要记住,这里的大小不代表开发时间,只是一个相对的用户故事的复杂度,工作量大小。因为很难理解,所以scrum team要建立一个基准的user story,作为一个points,然后其他的user story和它进行相对比较。这个points大部分时间用来作为评估team的交付能力。


    SCRUM开发流程



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


    SCRUM各个角色之间的关系和作用:

    PO和team的关系:一个人拿到了客户的一个项目,开发一个产品,他就是PO,他想找一个团队开做这个产品,但是现在有A团队和B团队,A团队跟PO说,ok,交给我吧,3个月后你过来,我们把产品给你.而B团队说,我们每个月都可以让你看一下我们的产品,但是可能一开始功能不完善,但是可以工作的,然后你可以把我们的产品给客户看,如果运气好的话客户可能先给你点钱呢。

    如果你作为PO,你会选择哪个团队呢?对了,A就是传统的开发团队,而B则是我们的scrum team.

    scrum master和team还有PO的关系:


    个人给SM有以下几个定义:



    Team Coach: 不仅在在流程上辅导团队,还要帮助大家接受敏捷开发理念,推动团队按照敏捷价值观和原则所倡导的方法来做出决策。

    Servant Leader:Scrum Master服务于团队,帮助团队解决工作中的困难,引导团队自组织的高效完成每日工作,但是并不是团队的管理者。

    Team Protector: 作为团队保护者,SM7要敢于说不,尽量保证团队在每个冲刺中不被打扰,如果发现有影响团队工作的临时任务,一定要站出来保护团队。


    SCRUM大事表:

    Jeff Sutherland在 1993年首次在Easel公司定义了用于了软件开发行业的Scrum流程,并开始实施

    1995年Jeff Sutherland和Ken Schwaber规范化了Scrum框架,并在OOPSLA 95上公开发布。

    2001年 敏捷宣言及原则发布、敏捷联盟成立,Scrum是其中一种敏捷方法。

    2001年,Ken Schwaber和Mike Beedle推出第一本Scrum书籍《Scrum敏捷软件开发》。

    2002年Ken Schwaber 和Mike Cohn共同创办了Scrum联盟。

    展开全文
  • 敏捷开发之Scrum扫盲篇 现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP...   为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来...

    敏捷开发之Scrum扫盲篇

    现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP...

     

    为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum中的各个环节,主要目的有两个,一个是进行知识的总结,另外一个是觉得网上很多学习资料的讲述方式让初学者不太容易理解;所以我决定写一篇扫盲性的博文,同时试着也与园内的朋友一起分享交流一下,希望对初学者有帮助。

     

     什么是敏捷开发?

    敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

    怎么理解呢?首先,我们要理解它不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成项目的开发;而这种开发方式的主要驱动核心是人;它采用的是迭代式开发;

     

    为什么说是以人为核心?

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

     

    什么是迭代?

    迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

     

    关于Scrum和XP

    前面说了敏捷它是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是实际中,两者是结合一起应用的,这里我主要讲Scrum。

     

    什么是Scrum?

    Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;把一个开发流程的名字取名为Scrum,我想你一定能想象出你的开发团队在开发一个项目时,大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它,你一定会感到非常兴奋的。

    而Scrum就是这样的一个开发流程,运用该流程,你就能看到你团队高效的工作。

     

    【Scrum开发流程中的三大角色】

    产品负责人(Product Owner)

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

     

    流程管理员(Scrum Master)

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

     

    开发团队(Scrum Team)

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

     

     

    Scrum流程图

     

    //------------------------

    下面,我们开始讲具体实施流程,但是在讲之前,我还要对一个英文单词进行讲解。

    什么是Sprint?

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

     

    如何进行Scrum开发?

    1、我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;

    2、Scrum Team根据Product Backlog列表,做工作量的预估和安排;

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

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

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

    6、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;

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

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

     

     

    下面是运用Scrum开发流程中的一些场景图:

    上图是一个 Product Backlog 的示例。

     

    上图就是每日的站立会议了,参会人员可以随意姿势站立,任务看板要保证让每个人看到,当每个人发言完后,要走到任务版前更新自己的燃尽图。



    任务看版包含 未完成、正在做、已完成 的工作状态,假设你今天把一个未完成的工作已经完成,那么你要把小卡片从未完成区域贴到已完成区域。


     

    每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度出现了什么问题(成员人数最好是5~7个,这样每人可以使用一种专用颜色的标签纸,一眼就可以从任务版看出谁的工作进度快,谁的工作进度慢)

     

     

     上图可不是扑克牌,它是计划纸牌,它的作用是防止项目在开发过程中,被某些人所领导。

    怎么用的呢?比如A程序员开发一个功能,需要5个小时,B程序员认为只需要半小时,那他们各自取相应的牌,藏在手中,最后摊牌,如果时间差距很大,那么A和B就可以讨论A为什么要5个小时...



    敏捷开发中XP与SCRUM的区别


    区别之一:  迭代长度的不同

    XP的一个Sprint的迭代长度大致为1~2周, 而Scrum的迭代长度一般为 2~ 4周.

    区别之二: 在迭代中, 是否允许修改需求

    XP在一个迭代中,如果一个User Story(用户素材, 也就是一个需求)还没有实现, 则可以考虑用另外的需求将其替换,替换的原则是需求实现的时间量是相等的。 而Scrum是不允许这样做的,一旦迭代开工会完毕, 任何需求都不允许添加进来,并有Scrum Master严格把关,不允许开发团队受到干扰

    区别之三: 在迭代中,User Story是否严格按照优先级别来实现

    XP是务必要遵守优先级别的。 但Scrum在这点做得很灵活, 可以不按照优先级别来做,Scrum这样处理的理由是:如果优先问题的解决者,由于其它事情耽搁,不能认领任务,那么整个进度就耽误了。 另外一个原因是,如果按优先级排序的User Story #6和#10,虽然#6优先级高,但是如果#6的实现要依赖于#10,则不得不优先做#10.

    区别之四:软件的实施过程中,是否采用严格的工程方法,保证进度或者质量

    Scrum没有对软件的整个实施过程开出工程实践的处方。要求开发者自觉保证,但XP对整个流程方法定义非常严格,规定需要采用TDD, 自动测试, 结对编程,简单设计,重构等约束团队的行为。因此,原作者认为,这点上,XP的做法值得认同的,但是却把敏捷带入了一个让人困惑的矛盾, 因为xp的理念,结合敏捷模式,表达给团队的信息是“你是一个完全自我管理的组织, 但你必须要实现TDD, 结对编程, ...等等”

    不难发现,这四个区别显见的是: Scrum非常突出Self-Orgnization, XP注重强有力的工程实践约束

    作者建议, 在管理模式上启用Scrum, 而在实践中,创造一个适合自己项目组的XP


    展开全文
  • Scrum敏捷项目管理

    千次阅读 2017-04-29 03:56:32
    敏捷的背景与动机软件危机及软件工程的出现 速度是企业竞争致胜的关键因素,软件项目的最大挑战在于 一方面要应付变动中的需求 一方面要在紧缩的时程内完成项目 传统的软件工程难以满足这些要求 所以软件团队...

    敏捷的背景与动机

    软件危机及软件工程的出现
    速度是企业竞争致胜的关键因素,软件项目的最大挑战在于
    一方面要应付变动中的需求
    一方面要在紧缩的时程内完成项目
    传统的软件工程难以满足这些要求
    所以软件团队除了在技术上必须日益精进,更需要运用有效的开发流程,以确保团队能够发挥综效。这正是Agile Process (敏捷的软件开发流程)于近年来兴起的主要原因。

    软件项目的复杂性

    横轴代表需求的复杂度!
    纵轴表示技术的复杂度
    还有人力资源的复杂度
    这里写图片描述

    解决复杂性问题需要采用经验式方式

    解决问题的两种方式:
    预定义过程控制(富士康流水线生产)
    经验性过程控制(摸着石头过河)
    如果复杂度超过预定义方式的能力范围,应该采用经验性方式
    经验性方式的三大支柱:可见性、检查及适应

    敏捷的历史

    敏捷软件开发又称敏捷开发,
    从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。
    2001年初,因观察到许多的软件团队身陷不断扩大的流程之中的困境,一群业界专家聚集在一起,勾勒出一些能让软件团队迅速工作,以及响应变化的价值观和原则。他们自称为Agile Alliance。
    之后的七个月里,他们创造具有价值的声明,也就是敏捷软件的开发宣言。
    十五人中包括:大名鼎鼎的Kent Beck(XP,TDD的创始人,Junit的创始人之一)、Ward Cunningham(Wiki概念的发明者)、Martin Fowler(《企业应用架构模式》作者)、Robert C. Martin、Ken Schwaber

    敏捷价值观之敏捷宣言

    这里写图片描述
    敏捷开发的核心思想是:以人为本,适应变化
    个体和交互胜过过程和工具:
    1、人是软件项目获得成功最为重要的因素
    2、合作、沟通能力以及交互能力比单纯的软件编程能力和工具更为重要
    3、方法和工具是死的,人是活的,人要是太“面”或者协作不好,再强大的方法和工具都是白扯;

    可以工作的软件胜过面面俱到的文档:
    1、过多的面面俱到的文档往往比过少的文档更糟
    2、软件开发的主要和中心活动是创建可以工作的软件
    3、直到迫切需要并且意义重大时,才进行文档编制
    4、编制的内部文档应尽量短小并且主题突出

    客户合作胜过合同谈判:
    1、客户不可能做到一次性地将他们的需求完整清晰地表述在合同中
    2、为开发团队和客户的协同工作方式提供指导的合同才是最好的合同

    响应变化胜过循环计划:
    1、变化是软件开发中存在的现实
    2、计划必须有足够的灵活性与可塑性
    3、短期的迭代的计划比中长期计划更有效

    敏捷开发的12个原则

    1. 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
    2. 即使到了开发的后期,也欢迎改变需求。
    3. 经常性地交付可以工作的软件,交付的间隔可以从几周到几个月,交付的时间间隔越短越好 。
    4. 在整个项目开发期间,业务人员和开发人员必须天天都在一起工作。
    5. 围绕被激励起来的个人来构建项目。
    6. 在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。
    7. 工作的软件是首要的进度度量标准。
    8. 敏捷过程提倡平稳的开发节奏;发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
    9. 不断地关注优秀的技能和好的设计会增强敏捷能力。
    10. 简单化是根本(不做过度设计和预测)。
    11. 最好的构架、需求和设计出自于自组织的团队。
    12. 每隔一定时间,团队会在如何才能更有效地工作方面进行反思并对自己的行为进行相应调整。

    什么是敏捷方法?

    敏捷方法是一类软件开发流程的泛称;
    敏捷方法是相对于传统的瀑布式软件过程提出的;
    敏捷方法可以用敏捷宣言(4条)、敏捷原则(12条)来概括;
    敏捷原则通过一系列的敏捷实践来体现出来;
    敏捷方法有很多种。

    敏捷的方法

    1. Extreme Programming (XP)极限编程
    2. Scrum
    3. Adaptive Software Development (ASD)自适应软件开发
    4. Crystal Clear and Other Crystal Methodologies水晶方法
    5. Dynamic Systems Development Method (DSDM)动态系统开发方法 等

    敏捷方法 VS. 瀑布模型

    瀑布模型
    固定的、没有弹性的。
    很困难去达到互动。
    假如说需求没有完全的被了解,或是可能需要完全地改变项目的需求,瀑布式的model是比较不适合的。
    敏捷方法
    完整地开发,每少数几周或是少数几个月里可以测试功能。
    强调在获得最简短的可执行功能的部分,能够及早给予企业价值。
    在整个项目的生命周期里,可以持续的改善、增加未来的功能。
    瀑布模型:
    瀑布模型
    敏捷方法:
    敏捷方法

    敏捷项目管理VS传统项目管理

    传统项目管理:

    1. 事先对整个项目进行估计、计划、分析
    2. 反对变更; 变更需要重新估计、重新规划
    3. 严密的合同来减少风险, 如果改变需求要走 CR 流程.
    4. 项目作为一个“黑盒子” ,对客户与供应商的可视性差.
    5. 文档和计划驱动的方法.
    6. 软件交付时间晚, 意识到风险的时间晚.
    7. WBS,甘特图,关键路径分析

    敏捷项目管理:

    1. 对整个项目做一个粗略的估计,每一次迭代都有详细的计划.
    2. 鼓励变化, 客户价值驱动开发.
    3. 信任和赋予权力;合约使变更变得简单,增加价值.
    4. 客户和开发人员之间是紧密的连续的合作关系
    5. 每次迭代都产生可交付的软件
    6. 专注于交付软件.
    7. 第一次迭代就可交付能工作的版本,风险发现的早.

    敏捷 与CMMI双剑合璧

    CMMI更加关注于流程,敏捷更加关注于人
    CMMI自顶向下,敏捷自底向上
    敏捷并不排斥必要的文档
    敏捷的很多实践是对CMMI的一种实现,比如sprint计划会议就是PP的实现,每日例会就是在做PMC
    很多CMMI4~5级的公司也在应用敏捷,比如说宝信、华为
    项目级的敏捷实践通过CMMI可以在组织级得以重用

    这里写图片描述

    eXtreme Programming

    XP我们一般称为极限编程,是最轻量级的开发流程。
    最主要的精神是
    『在客户有系统需求时,给予及时满意的可执行程序』,所以最适合需求快速变动的项目。
    它强调客户所要的是
    workable的执行码,所以把与撰写程序无关的工作降至最低,并要求客户与开发人员最好以side-by-side的方式一起工作。
    XP的实践包括:
    完整团队、计划游戏、客户测试
    简单设计、结对编程、测试驱动开发
    改进设计、持续集成、集体代码所有权
    编码标准、隐喻、可持续的速度
    这里写图片描述

    Scrum开发流程

    这里写图片描述

    为什么采用敏捷? –预期的收益

    采用敏捷方法得当的话,可以:

    1. 更加透明; 随时跟踪项目的状态和进展情况,及早发现问题和风险 .
    2. 快速交付, 每次迭代都能交付可运行的软件.
    3. 最高风险和最高优先级的需求,最优先进行开发.
    4. 改善应对变更能力, 减少大量的重计划.
    5. 改善项目沟通.
    6. 更好的客户参与, 避免错误的假设.

    总之:

    1. 提高了生产率; 减少“浪费” (不需要的文档,重复工作等) ,项目的每次迭代都有明确的目标.
    2. 提高客户满意度; 短期内产生成效, 按预期交付软件, 每次迭代结束产生可以运行的软件.
    3. 改善员工的满意度; 团队精神,减少官僚,能够规划和管理自己的工作,减少“恐慌” ,稳定的工作量(可持续的步伐).

    敏捷关键实践1——增量迭代

    1. 每个迭代有一个大约为1~4周的时间框,在SCRUM里称为一次冲刺(超过1个月的详细计划往往偏差很大)
    2. 每次迭代都应该有明确的目标
    3. 每次迭代都应该有明确的可演示的工作成果
    4. 迭代过程中项目团队应该尽量免受打扰
    5. 迭代可以将项目的压力分解到每个小的阶段,风险也能同时分解

    这里写图片描述

    敏捷关键实践2——测试驱动开发 TDD

    什么是测试驱动?

    1. 首先创建测试用例,然后开发软件通过测试(在开发代码前,首先编写测试代码)
    2. 一种设计软件的方法,而不仅仅是一种测试方法
    3. 所创建的测试用例用来指导和约束项目中的各项工作,对未来的各项工作提供一个安全的保护
    4. 不需要测试的工作不需要完成
    5. 所创建的测试用例通常替代详细的业务和技术需求定
    6. 测试也有效地驱动设计,使设计更加趋向于可行的设计
    7. 通常情况下需要自动测试的支持 (EUnit, JUnit etc.).
    8. 对于UI软件应用TDD方法有一定的困难

    敏捷关键实践3——持续集成

    极限编程称为“每日构建”
    持续集成一般利用ANT、MAVEN等工具
    日构建的好处:
    将集成风险降到最低
    降低质量风险
    提升士气
    日构建可以看做是项目的心跳,冒烟测试就像是听诊器
    日构建必须至少:成功编译、打包、发布;不含有任何明显的缺陷;通过冒烟测试

    敏捷关键实践4——面对面交流

    虽然如今通讯工具花样繁多,但面对面交流在某些场合下仍然是不可替代的;
    敏捷开发把交流缺失问题考虑在内,要求团队成员彼此直接协作,尽量创造面对面交流的机会;
    尤其当业务分析师和软件开发人员一起工作的时候,面对面的交流是很重要的。
    匿名共享需求文档只会打开曲解和误解之门,更不用说书面信息比口头交流还要慢很多。

    敏捷方法的其它实践

    1. 结对编程
    2. 每日立会
    3. 用户故事
    4. 团队工作室
    5. 频繁发布
    6. 自组织团队
    7. 重构
      这里写图片描述
      这里写图片描述
      这里写图片描述
      这里写图片描述

    重构——改善既有代码的设计

    Martin Fowler提出
    代码的坏味道
    Martin Fowler和Kent Beck列举了22种坏味道:冗余代码、冗长的方法、巨大的类、过多的参数等等
    重构可以弥补设计的不足
    简单设计的思想
    重构与测试驱动的关系
    TDD是重构的脚手架
    IDE已经对主要的重构模式提供了自动化支持:Rename, extract method, move field等等
    简单设计>>测试用例>>实现再说>>(重构>>回归测试)*

    这里写图片描述

    Scrum何时更有效?

    公司和客户一致认为应当使用敏捷方法,双方都能理解敏捷方法.
    敏捷方法对需求不完整以及经常变换的项目比较有效.
    项目可以划分成固定时间间隔的迭代, 并且可以冻结正在进行的迭代的范围
    公司和客户都有能力担当角色尤其是Product Owner 和 Scrum Master.
    项目的人员结构能够分成6到10人的团队,最好每个工作地点一个小组.(Scrum of Scrums,Scrum的扩展)
    团队成员能够以自组织的方式工作.
    项目的合同允许变更.
    固定价格的项目可以使用敏捷,但应当尽量避免。
    最好在按时间和材料付费或者按月付费的项目中进行使用、
    变更项目的范围不需要高级管理层的批准.

    敏捷特别强调人的因素

    相对于过程与工具,敏捷更强调“人”的因素。

    诚信是基础

    没有过程能够对诚信进行有效的约束

    诚信与否是有效实施敏捷过程的最大限制

    Scrum框架

    这里写图片描述

    Scrum角色

    这里写图片描述

    Scrum角色之Product Owner

    产品负责人(Product Owner)的职责如下:
    确定产品的功能。
    决定发布的日期和发布内容。
    为产品的profitability of the product (ROI)负责。
    根据市场价值确定功能优先级。
    每个Sprint,根据需要调整功能和优先级(每个Sprint开始前调整)。
    接受或拒绝接受开发团队的工作成果。

    Scrum角色之ScrumMaster

    作为Team Leader和Product owner紧密地工作在一起,他可以及时地为团队成员提供帮助。他必须:

    1. 保证团队资源完全可被利用并且全部是高产出的。
    2. 保证各个角色及职责的良好协作。
    3. 解决团队开发中的障碍。
    4. 做为团队和外部的接口,屏蔽外界对团队成员的干扰。
    5. 保证开发过程按计划进行,组织 Daily Scrum, Sprint Review and Sprint Planning
      meetings。

    Scrum角色之Scrum Team

    一般情况人数在5-9个左右
    团队要跨职能
    (包括开发人员、测试人员、用户界面设计师等)
    团队成员需要全职。
    (有些情况例外,比如数据库管理员)
    在项目向导范围内有权利做任何事情已确保达到Sprint的目标。
    高度的自我组织能力。
    向Product Owner演示产品功能。
    团队成员构成在sprint内不允许变化。

    Scrum 流程

    这里写图片描述

    Sprints(冲刺)

    Scrum的项目过程有一系列的Sprint组成。
    Sprint的长度一般控制在2-4周。
    通过固定的周期保持良好的节奏。
    产品的设计、开发、测试都在Sprint期间完成。
    Sprint结束时交付可以工作的软件。
    在Sprint过程中不允许发生变更。

    Scrum仪式之Sprint计划会议

    这里写图片描述

    Scrum仪式之Sprint计划会议

    这里写图片描述

    Scrum仪式之每日Scrum会议(Daily Scrum)

    每日Scrum会议,即团队每日例会,条件允许的话,每天都应该在同样的时间和地点,组织所有成员站立进行。
    最好是每天早晨开,一般15分钟左右,时间比较短,也有利于团队成员安排好当天的工作。
    只有团队成员可以在例会上发言,其他人员有兴趣可以参加,但只能旁听,不能发言。(小猪和小鸡的故事)
    每日Scrum会议由Scrum Master主持, Scrum团队所有成员轮流回答以下3个问题:
    昨天我完成了什么工作?
    今天我打算做什么?
    我在工作中遇到了什么困难?
    这里写图片描述

    Scrum 任务板(Task Board)

    任务板(墙)展现了在Sprint过程中所有要完成的任务。在Sprint过程中我们要不断的更新它。如果某个开发人员想到了一个任务他就可以把这个任务写下来放在任务墙上。 无论每日站会过程中或者之后,如果估计发生了变化,任务会根据变化在任务墙上做相应的调整。通常的任务板是下面这个样子:

    这里写图片描述

    Scrum仪式之Sprint评审会议

    Sprint评审会用来演示在这个Sprint中开发的产品功能给Product Owner. Product Owner会组织这阶段的会议并且邀请相关的干系人参加。
    团队展示Sprint中完成的功能
    一般是通过现场演示的方式展现功能和架构
    不要太正式
    不需要PPT
    一般控制在2个小时
    团队成员都要参加
    可以邀请所有人参加

    Scrum仪式之Sprint回顾会议

    团队的定期自我检视,发现什么是好的,什么是不好的。
    一般控制在15-30分钟
    每个Sprint都要做
    全体参加
    Scrum Master
    产品负责人
    团队
    可能的客户或其它干系人

    Scrum物件之产品订单(Product Backlog)

    一个需求的列表。
    一般情况使用用户故事来表示backlog条目
    理想情况每个需求项都对产品的客户或用户有价值
    Backlog条目按照商业价值排列优先级
    优先级由产品负责人来排列
    在每个Sprint结束的时候要更新优先级的排列

    Scrum物件之产品订单(Product Backlog)

    这里写图片描述

    Scrum物件之冲刺订单(Sprint Backlog)

    这里写图片描述

    Sprint Backlog 示例

    这里写图片描述

    Scrum物件之冲刺订单(Sprint Backlog)

    管理Sprint的backlog:
    团队成员自己挑选任务,而不是指派任务
    对每一个任务,每天要更新剩余的工作量估算
    每个团队成员都可以修改Sprint backlog,增加、删除或者修改任务

    Scrum物件之燃尽图(Burn Down Chart)

    这里写图片描述

    扩展Scrum

    一般情况一个团队的人数控制在5-9人
    大型项目可以采用多团队,通过team of teams来扩展Scrum。
    影响扩展的因素
    团队规模
    项目类型
    项目周期
    团队分布
    Scrum曾被用于超过1000人团队规模的项目。

    Scrum Of Scrums

    这里写图片描述

    Scrum项目之估计

    Scrum团队对产品需求清单的每一项的规模提供初步的估计,通常采用事件点作为单位Story Points (模糊的).
    也可采用人天或者人小时作为单位,但容易混淆: a) 实际的规模 b) 时间的单位.
    精确的估计值可以在Sprint 规划时给出, 当前阶段没有足够的信息.
    规模的相对值才有意义.
    这个估计值有助于确定优先级;
    可以采用估算扑克
    这里写图片描述

    完成的定义

    当迭代任务清单上的任务都完成时,变为“已完成”状态
    定义“已完成”的含义是非常重要的, 例如:
    如何记录软件的变化.
    使用什么样的代码分析工具 ,发现的问题应当如何处理.
    进行了什么样的测试, 结果是如何记录的, 通过标准(如覆盖率、修正的错误)是什么.
    定义“已完成”意味着定义质量上的需求.
    “已完成”是0/1变量:完成或者未完成. 所有的任务(task)都完成了迭代任务才算完成.
    在第一个迭代开始之前应该定义好,因为它会影响工作量, 而且必须文档化,这样团队和产品所有者的理解是一致的.

    完成的定义 - Example

    完成的定义
    遵循编码规范
    能在模拟器上演示
    使用PCLint 进行静态代码分析
    具有EUnit 测试套件的通过率 和执行率.
    或者使用结对编程,或者进行代码走查

    障碍

    基本上,任何阻止团队正常工作的,都可称之为障碍,例如:
    无法访问信息系统.
    所需要的信息不能及时提供或者提供的不正确,如界面规格或者其它软件模块不到位或不正确
    开发环境或者原型系统出现问题
    其他的任务分配:培训,售前支持
    缺乏必要的信息或者相应的知识

    对于团队提出的各项障碍,Scrum Master要以列表形式进行记录,

    谁来清除障碍?

    每个人
    自我管理、自我组织的团队
    Scrum Master
    产品所有者
    管理层
    其他相关的干系人

    Scrum Master 负责确定障碍已经清除,不一定亲自自己清除

    清除障碍

    某些障碍是浪费
    部分地完成工作
    额外的过程
    额外的功能
    任务转换
    等待
    缺陷

    这里写图片描述

    浪费产生的原因

    多问几个“为什么”
    对于每个标识的障碍或者浪费,问一问“为什么”浪费会存在
    多问几个“为什么”,找到造成浪费的根本原因

    这里写图片描述

    SCRUM实践

    研发部2009年开始在几个项目当中进行了SCRUM项目管理的尝试:
    营销综合停电系统开发
    FLEX-ADP开发
    海颐OA项目

    SCRUM看板

    这里写图片描述

    SCRUM燃尽图

    这里写图片描述

    SCRUM带来的改善

    项目的计划性更强了,将项目按SPRINT进行分解,每个SPRINT要进行计划和总结,每天也有立会来进行简短的总结和计划;

    引入SCRUM以后,项目团队的沟通比以往更有效,项目看板为项目团队沟通提供了一个统一的项目视图,每日立会是项目团队沟通的有效通道;

    项目的阶段性比以前更明确,通过SPRINT将项目划分成阶段,通过SPRINT演示等活动将项目整体的压力分解到每个SPRINT,这样可以有效降低项目的整体风险。

    一些常见的误解

    敏捷是拯救任何项目的银弹.
    敏捷方法只有运用得当才有效果.
    敏捷意味着 ad-hoc hacking ,不需要任何文档.
    敏捷是有严格要求的,也是面向质量的
    根据沟通的需要产生相应的文档.
    敏捷只是开发者的问题
    基本的开发方法与传统相比有显著不同, 影响项目的各个方面: 合同, 角色, 定价模型, 项目管理等.
    采用敏捷方法的开发组/项目不需要制定计划
    敏捷项目需要经常制定计划,但是不需要试图超前制定项目计划,通常这也是不可能的.
    敏捷项目的范围可以随时改变.
    变更可以等到下一次迭代开始,当前正在进行中的迭代不能变更
    只对小项目适用
    在中型和大型的项目中一样取得了成功

    总结

    Agile Software Development是软件开发所强调的一个精神,而不是一个方法。
    遵循Agile Alliance所提的四个价值观与12个原则。
    最常见的开发方式
    XP
    SCRUM
    敏捷开发过程是一个艰苦的过程,重在实践
    即使非敏捷的项目中也可以应用敏捷的实践经验
    CMMI应该与敏捷实现融合,双剑合璧

    参考ppt:
    http://download.csdn.net/detail/qq1137623160/9828941

    展开全文
  • Scrum敏捷初识

    千次阅读 2018-05-29 17:08:53
    一、Scrum的初识 软件市场发展越来越迅速和成熟,传统瀑布式开发模式存在一定的限制,敏捷从而有了更广阔的的平台与机遇。Scrum作为在敏捷中使用最常用的一种方案,受到众多的关注。 下图是典型的Scrum执行架构图...

    一、Scrum的初识

        软件市场发展越来越迅速和成熟,传统瀑布式开发模式存在一定的限制,敏捷从而有了更广阔的的平台与机遇。Scrum作为在敏捷中使用最常用的一种方案,受到众多的关注。

        下图是典型的Scrum执行架构图。


        其中,涉及很多的要素,以下部分将一一说明。

        这其中,加入自我的理解,整体运作,主要在与两个关键环节:1,需求收集整理;2,研发流程控制。作为小小的产品经理,似乎有点想把自己的位置更凸显一点。那么,这环节中最重要的就是 需求管理!

    二、Scrum的详解【3355】

    1、3角色

    Product Owner:决定每个冲刺的任务,决定选择做什么和为什么做这些。

    Scrum Master:Scrum团队教练和带头人,扫除实施障碍。

    Team:是任务执行团队,可以是研发团队,也可以是跨职能团队,能够切实提供一个可用产品的团队。


    2、3工件

    Product Backlog:产品待办事项集合,我理解也是 用户故事,相当于当前版本所要做的所有需求。

    Sprint Backlog:迭代功能开发列表,理解为一个冲刺目标阶段内的需求列表。例举如,当前版本总共要完成40需求,是我们的Product Backlog;我们把当前版本拆分4个冲刺阶段,即是4个Sprint。第一个Sprint需要完成10个需求,则这10个需求为当前Sprint的Sprint Backlog。

    Burndown chart:燃尽图,确定需求实现阶段后,随时间往后推进,时间剩余消耗,同时任务列表也随工作的推进而消耗。即是,迭代显示剩余工作时间和任务的完成情况。


    3、5价值观

    Focus 专注:将故事拆解为冲刺阶段,目标细化,同时也是集中绝对的团队能力,解决既定目标,体现当前的专注,也排除其他插入时间的消耗。

    Courage 勇气:在整个敏捷过程中,需要效率的提升,同时,面临的技术、环境、团队等一系列的问题并不会变少,就需要有勇气,有决断的阔步向前,用最优势的精力、资源解决当前最迫切的问题。

    Openness 公开:团队内信息的完全公开,让问题无所隐藏,同时也让优秀和战绩能够很好地展示及引导,公开,从而大家平等,从而大家尊重。

    Respect 尊重:在敏捷过程中,因为公开我们搭建了尊重的基础;同时因为效率的要求和冲刺任务的明确性,我们做自己最擅长的事情,从而让整体效率最大化。尊重他人,信任他人。

    Commitment 承诺:构筑团队内部共同解决问题,最高效率突击任务环境,是因为我们信守承诺,敢于给出承诺;同时,也因为我们为别人为团队的承诺,我们必须是最好的处理我们的任务,对于我们承担的责任敢于承诺,也直面承诺的责任。


    4、5工作

    sprint planning meeting:冲刺前计划会议,决定并生成sprint Backlog。---类似需求评审

    sprint:冲刺,由冲刺会议决定了我们的目标,从而确定了冲刺的阶段,人员及任务安排。---类似于计划

    daily standupdo meeting:每日站会,主要用于跟进进度,确定当前任务的情形,同时沟通是否有异常情况。要将异常在开始阶段进行良好控制。

    sprint review:冲刺回顾。一个冲刺完成,对冲刺进行回顾,整理有益处,执行良好的部分;规划检查不好的地方,可以做的更好的方面。优化中不断前行。

    retrospective meeting:回顾会议。完成当前版本,需要对整体进行回顾,对经历经验进行整理归档,形成有效的成长型文档,便于团队更好的成长。

    深深触动,本科的专业总结了一句话:先控制,后碎部,步步检核。学科本身的内核或许是有相似之处的。

    在自我的理解中,Scrum中,Product Owner 和 Scrum Master是两个核心关键人物,ProductOwner 决定产品的需求,算是高级的产品经理(PM),Scrum Master是教练,也是整个团队良性运行的核心人物。


    三、自思考

    下图是Scrum执行流程的概述


    如前文所述,Scrum敏捷开发工作中,最核心的是两个环节:需求收集整理,研发流程控制。其实,这两个环节在整个研发过程中也依旧很重要。需求池和版本树中依据自己的思想,整理出来进行需求池管控,由需求池输出软件版本,每个版本完成进行结版总结,形成良性循环。构成整个研发的生命周期,往后需要继续细化每个执行步骤,让一切更有序,更高效率化。


    下图是,对Scrum的初识整理:


    mind原件下载



    在一件事上做到60分靠经验和常识就可以,把一件事情做到80分靠技术和方法就行,要做到90分以上靠的只能是艺术了。



    展开全文
  • 八分钟敏捷开发(scrum)扫盲

    千次阅读 2018-08-20 16:54:42
    敏捷开发(scrum)是一种软件开发的流程,强调快速反应、快速迭代、价值驱动。 Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;运用该流程,你就能看到你团队高效的工作。 敏捷开发的特点就是...
  • 现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP... 什么是敏捷开发? 敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。 怎么理解呢?首先,我们要理解它不是一门...
  • Scrum 基于试验性过程控制理论,借鉴了精益思想、时间盒、模块化设计等,并完整地体现了敏捷宣言和敏捷原则。Scrum 采用一种迭代、增量式的方法来优化对未来的预测和管理风险,建立组织响应变化的敏捷能力,从而达致...
  • 什么是CSM?...Scrum Master是Scrum团队中的服务型领导,帮助Scrum团队外的人员了解他们如何与Scrum团队交互是有益的,通过改变他们与Scrum团队的互动方式来最大化Scrum团队所创造的的价值。据不完全统...
  • CSM,即Certified ScrumMaster,是Scrum联盟发起的Scrum认证。CSM可以帮助团队正确使用Scrum,从而提高项目整体成功的可能性。CSMs深刻理解Scrum的价值观、实践以及Scrum框架。CSM是“服务型领导”,帮助Scrum团队...
  • 软件开发模式之敏捷开发(scrum

    万次阅读 多人点赞 2018-08-08 19:25:59
    这几年关于敏捷开发在互联网企业中越来越广泛被使用到,运用的比较多的当属scrum敏捷开发和xp敏捷开发,人人都在谈论敏捷开发。那什么才是敏捷开发呢? 目录 什么是敏捷开发? 传统的开发模式和敏捷开发模式的...
  • 敏捷Scrum项目管理汇总(思维导图)

    千次阅读 2015-03-09 16:48:22
    敏捷Scrum项目管理汇总(思维导图):
  • scrum敏捷开发的几款工具

    千次阅读 2019-03-07 11:14:37
    此篇介绍我们在scrum敏捷开发中发掘的几款工具,方便更多新加入的开发者上手。 1. Leangoo Leangoo(中文名:领歌)是一款基于看板的项目协作工具!是由国内最权威的scrum中文网精心打造,融入了先进的敏捷管理...
  • 随着敏捷开发越来越流行,人人都在谈敏捷,人人也都在学习scrum敏捷开发方法。。。
  • Scrum敏捷开发之角色

    万次阅读 热门讨论 2014-02-22 23:56:44
    Scrum中有三种角色:产品负责人Product Owner,Scrum Master和Scrum团队,他们的职责分别是: 产品负责人(Product Owner) 确定产品的功能和完成时间;对产品的收益负责;根据市场需求确定产品功能的优先级;...
  • 经过上面总结的两篇博文敏捷开发实践(一)–谈谈我对敏捷开发的理解和敏捷开发实战(二)–你真的了解Scrum吗?,我们已经对Scrum进行了整体的认识和学习,这篇博文我们一起讨论和学习,我在实施敏捷的过程发现的一...
  • 敏捷小圈子里,不难发现很多小伙伴都是从Scrum Master开始入行,如何从0起步,通过学习成为一名专业的敏捷人呢,今天我就和大家分享一下适合Scrum Masters充电的优质书籍30本。我本人已经阅读完了这30本书,也在...
  • 我和敏捷开发的故事--敏捷角色-SM

    万次阅读 2015-09-29 22:21:25
    通过上篇文章我们已经知道了敏捷角色中PO的角色内容,接下来的一个敏捷角色在敏捷开发中非常关键,但是往往很多项目实践中都没有很好的把控好这个角色,让他或多或少的没有起到相应的作用,这个角色就是ScrumMaster. ...
  • 何为Agile,何为Scrum

    千次阅读 2019-01-07 21:26:53
    什么是敏捷敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。 首先,我们要理解它不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成...
  • 使用Scrum进行敏捷项目管理

    千次阅读 2018-12-27 13:33:56
    Scrum是一种敏捷方法,旨在指导团队进行产品的迭代和增量交付。通常被称为“敏捷项目管理框架”,其重点是使用经验过程,使团队能够快速,有效,有效地做出改变。传统的项目管理方法确定了需求,以控制时间和成本; ...
  • 敏捷开发——SCRUM

    万人学习 2018-10-22 21:38:02
    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。
1 2 3 4 5 ... 20
收藏数 19,942
精华内容 7,976
关键字:

scrum敏捷