精华内容
下载资源
问答
  • Scrum敏捷游戏开发

    2017-08-12 14:05:37
    比较完整的项目敏捷实验
  • 第一章:业界状态 游戏行业三大危机:创作保守,内容缩水,加班繁重 第二章:敏捷开发 大型游戏项目特点:开发过程...敏捷模式拥抱变化,每一次迭代都更明确游戏所需的核心乐趣,这意味着敏捷模式制作游戏将会...

    第一章:业界状态

    游戏行业三大危机:创作保守,内容缩水,加班繁重

     

    第二章:敏捷开发

    大型游戏项目特点:开发过程中容易产生‘新增特性’,任务复杂度高>评估准确性低,demo阶段不确定性高。------ 变化多

    瀑布模式难以应付大型项目‘变化多’的特点,且难以在计划阶段就明确游戏产品多核心乐趣。

    敏捷模式拥抱变化,每一次迭代都更明确游戏所需的核心乐趣,这意味着敏捷模式制作游戏将会降低返工(成本)或以降低质量来维持原计划的风险。

    敏捷特征:敏捷宣言

     

    第三章:Scrum模式

    Scrum主要由PB和SB组成,在jira中PB直接叫backlog,SB直接叫sprint。

    SB以一个阶段小产品为目标在PB中抽取PBI,由PO确定。

    PO负责scrum团队每个sprint中抽取的PBI的优先级排序,确保ROI,确保整个团队目标一致。

    SM负责协助团队建设(包括评审会等),减少工作中的障碍,指导团队成员Scrum原则,协调团队内部沟通及团队与外部(相关方等)的沟通。

     

    第四章:Sprint

    典型sprint流程应该在sprint会议前举行优先级会议,先确定当前冲刺目标,再确定抽取PBI的优先级,并将选取的PBI拆分或者合并成合适大小的PBI。

    sprint计划会需要将暂定抽取的PBI(史诗/用户故事)分解成任务,并估算故事点以及确定CoS(满意条件)。

    评审会:相关方参与

    回顾会:停止,开始,持续;confluence中默认为‘需要做的更好的(停止)', '做的好的(持续)', '要改进的行动(开始)'.

    燃尽图:以故事点为计量燃尽图可以反应sprint速率,在sprint中途就可以预估,时间到而未燃尽需要删除部分PBI或者加班,或者重置sprint。

    Scrum流程:需求梳理会,PO梳理PB(按需召开) ——> 故事研讨会+sprint优先级会议和计划会(优先级会议排优先级,确定潜在sprint目标,以及合并或分解PBI) ——> 站会 ——> 评审会 ——> 回顾会

    研讨会:写故事,团队共同讨论

    计划会:拆子任务,估时,认领

    评审会:showcase展示,相关方意见

    回顾会:检查,总结

     

    第五章:User Story

    用户故事目的是让所有人都理解这个故事的目标。

    用户故事优先级排序的时候需要在统一标准下评估。

    故事应该遵循INVEST原则:

    Independent独立的

    Negotiable可商讨的

    Valuable有价值的

    Estimable可估算的

    Sized appropriately大小合适的

    Testable可测试的

    完成字段可以配置词典

     

    第六章:敏捷计划

    敏捷计划是小而短贯穿整个项目,分阶段制定。

    敏捷模式会根据实际情况以迭代和变更的方式做计划。

    敏捷计划的制定会以优先高价值的交付,可控(时间,成本)为标准。

    发布计划:每个发布都应该是一个可交付的产品(可玩的游戏),一个发布中包含多个sprint,类似瀑布模式里的里程碑。

     

    第七章:游戏项目管理

    kanban模式(精益)与scrum模式(敏捷)同级,侧重流程控制(可视化),优化流程减少资源(时间,人力等)浪费(精益理念)。

    Jira上可创建两种面板,一种是Scrum面板(敏捷面板)一种是kanban面板(精益面板)。

    共享资源类(依赖)岗位可以单独成立团队,可为这类团队按精益理念使用kanban,理想情况下应为各独立团队制作符合其工作内容的专属kanban流程,需要通过个人时间窗计算循环时间,再对比步骤花费时间,然后配给人员或者设置缓冲等方法使流程平滑,进度可估。

    游戏项目管理模式可以混合,如scrum和kanban结合,或者原型阶段敏捷>制作阶段瀑布.

     

    第八章:团队

    团队应具备的属性:有共同愿景和目标,共同承担责任,重点在于自我管理和自我组织。

    规模化Scrum团队可以组建SoS(Scrum of Scrums)。

    小团队类型:

    特性团队(针对一类交付任务,LeSS体系推荐),功能团队(针对共用功能,通常为底层基础功能),制作团队(内容创作团队),公共结构团队(支持服务团队),工具团队(制作工具的支持服务团队)资源成团队(内部外包),集成团队(大型特性团队)组件团队(业务线团队)

    SoS中小团队sprint可以同步也可以不同步,同步的好处在于评审功能更完整。

    SoS中可以为同样职能的队员组建非正式社区,社区可以快速有效的交流信息沟通。

     

    第九章:迭代

    迭代是增量开发的过程,Scrum中每一次sprint可以算一次迭代,迭代开销主要来自变更。

    当前各团队不影响其他分支的单独sprint可以看作是个人迭代(更新),对其他分支有影响需要上传主线变更共有资源的sprint可以看作是版本迭代(做版本)。

    版本迭代(1.1,1.2,1.3之类)和发布(1.0,2.0等)不同,版本迭代是一个阶段性的增量开发过程,发布是一个里程碑(准交付产品,可玩的游戏)。

     

    第十章:敏捷技术

    不确定性导致变更成本高,约后期改动越大,敏捷则可以在发现问题的初期尽量解决减少变更成本。

    敏捷不应该做太多预想却不是当前切实的需求,构建需求只要考虑当前需要的功能,不要考虑太多未来可能会添加的功能。

    敏捷中应该尽量减少BUG fix债务,QA发现错误后,如果和当前sprint相关并小到可以修复应该加入到当前sprint中作为一个任务,如果不会影响到当前sprint,则可以放在PB中作为一个用户故事。

     

    第十一章:敏捷美术&音频

    美术人员通常不纳入跨职能业务线,但也可以有部分人员加入业务线,然后以社团的形式非正式交流。

    美术人员和跨职能的业务线之间容易产生理解偏差,需要双方增进了解。

    音频人员工作大多在收尾阶段,为了避免启动阶段的时间浪费,可以采取合作生产的模式,音频人员也可以同步业务线开展工作,在不需要进行音频制作的时候可以旁听其他业务线的工作内容,以及辅助一些相关性的工作。

     

    第十二章:敏捷设计

    游戏行业设计岗大多数是策划,所以策划作为PO会更合适,策划作为PO也更容易把握共同愿景。

    用户故事债务积攒到一定程度需要集成方式清楚债务(将多个类似的零件故事组成一个故事)。

    基于集合的设计可以在短时间内找到最好的解决方案:取技术可能性,美术可能性,设计可能行的交集作为一个方案。

     

    第十三章:敏捷QA&制作

    QA的数量取决于需要。前期可以共用,后期最好可以做到每个业务线都有专属QA。

    QA在Scrum中应该贯穿整个项目而不是集中在发布前测试,因为Scrum每个sprint都具有潜在可交付成果。

    QA应该具有玩家视角,需要在版本测试阶段进行体验测试。

    错误数据库:将识别的错误收入一个错误数据库,在后期(发布阶段)维护的时候每个业务线可以将需要修复的bug提出加入到PB排序后加入当前SB。

    制作人也适合SM和PO。

     

    第十四章:Scrum的神话与挑战

    Scrum并未适用所有团队或个人。

    Scrum崇拜问题:强行依照Scrum流程而拒绝变化是伪Scrum。

    Scrum并非没有计划,迭代也是有序的迭代。

    Scrum会议表面上占据很多时间,但实际上有效的会议可以降低风险或提前发现问题,最终等于提高效率。

    Scrum并非解决问题的框架,更大的作用是提前暴露问题。

    Scrum应该注重工作增加的价值而不是工作中完成的任务。

     

    第十五章:开发商和发行商

    发行商和第三方开发商之间的信任危机,合同间往往会隐瞒缺陷,需要建立信任,可以采用敏捷合同的方式。

    第一方开发商也存在与发行商之间的矛盾,第一方需要降低发行商的干预程度,可以让发行商有限地参与到开发过程,如双PO模式(发行商PO和开发商PO)。

    敏捷合同的核心有两点:1、优先创造价值更高的目标;2、尽量减少债务,避免推迟还债。

    敏捷前期制作阶段可以采用阶段性评审(两个绿灯):

    1、概念绿灯:发行商评审完游戏项目的概念,计划和原型后决定是否可以进入研发阶段;

    2、生产绿灯:发行商在评审完玩法和和资源的计划安排后决定是否可以进入制作阶段。

    阶段性评审可以让团队更加注重游戏品质而非计划。

     

    第十六章:启动Scrum

    Scrum可以划分成三个阶段:学徒阶段,熟练阶段,大师阶段。

    学徒阶段的团队成员在进行Sprint的时候更多的是当作一个小型瀑布模式去执行,对Sprint的目标(价值)不够关心,对任务完成度较为关心。一个版本的多个Sprint直到最后一个或几个Sprint才开始测试调优,因此容易产生债务积压。且学徒阶段的团队站会容易变成汇报会议,注意不可使用工具代替站会。

    熟练阶段的团队需要注意集中办公环境,一个是安排相同职能相同团队的人员坐在一起,另一个尽可能取消隔断(常见互联网类型),还需要根据实际工作内容安排方位(如程序需要在安静的区域),在Sprint上要避免固化:在Sprint中包含过多“未完成”的任务,需要修改“完成”的定义。团队会关注游戏的好玩程度,这会带来:后期工作任务可能不会增加多少,但是价值增加却会很多。

    大师阶段的团队能够自我组织并持续改进,这样的团队的共同点有:归属感,领导力,核心专家,团队合作,培养性的工作室文化。该阶段团队队Scrum本质有深刻认识,有更适合团队本身的定制化流程,不再被Scrum常规流程框架束缚。

    推广Scrum:

    第一步组建桥头堡团队:先选取部分意向高队人组成团体使用Scrum,取得成果后分三种方式推广:

    1、分裂种子式:将桥头堡团队每个成员作为种子组建新团队;

    2、分裂重构式:将桥头堡团队对半分再分别补充人员组成新团队;

    3、全面部署式:依照桥头堡团队成功的模式全面推广。

     

    展开全文
  • Scrum敏捷开发.pdf

    2019-12-15 17:26:51
    介绍敏捷思想,scrum核心内容,scrum总结,scrum相关技术等内容,敏捷开发是互联网大厂程序员必备的基本功之一。建议重点掌握。
  • 敏捷游戏开发Scrum)——Agile Game Development with Scrum
  • SCRUM敏捷开发教程

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

    大家好,我是煎饼哥,本期向大家介绍一个关于敏捷开发的方法,叫做scrum,相信资深的产品经理都接触过类似的项目管理方法。

      scrum敏捷开发,是一个美国统计学教授记录了多年工作经验,总结出来的一套简单易懂的开发方法,我接触过不少产品经理,惊奇发现不少产品经理的确是产品把控的非常好,输出的BRD,MRD,PRD等都非常专业,但是却没一套很好的项目管理方法。

      干货分享第一期:10分钟教会你SCRUM敏捷开发 干货第一期微信号:terrydengbin

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

      首先欢迎大家关注本公众号,持续会输出原创内容,谢谢。

      (点击图片可以查看大图)

      

      scrum是有效管理未知因素和不断变化的产品需求,结束混乱,着重于如何驱动项目实现最高的投资回报。

      scrum材料准备:一个白板,n张便条纸,一张a4纸打印燃尽表(手绘也可以),一只笔。

      

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

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

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

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

      

      Scrum 步骤一:

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

      

      Scrum 步骤二:

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

      前面基本是最耗时间的,product owner和开发团队一来一回好多次。

      

      Scrum 步骤三:

      神马原型,ui设计都不是在步骤二完成的,刚才只是开始,步骤三后面才是scrum的精华部分,把任务量化,包括,原型,logo设计,ui设计,前端开发等。

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

      把每个任务都贴在白板上面,白板上分三部分

      (1)to do待完成

      (2)in progress 进展中

      (3)done 完成。

      

      如何估算时间:玩poker game(扑克游戏)这个方法估算出来的工作时间比较准,参与扑克游戏的最好有专家和开发涉及到的人员(杜绝阿猫阿狗,酱油男等参与)

      扑克游戏玩法:

      (1)每个人发一些便条纸, 针对具体任务,每个人根据经验写出时间(不公开写)

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

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

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

      注意事项,如果参与的人不懂该任务流程,参与投票就会影响准确率。

      

      Scrum 步骤四:

      好吧,经过大家纠结讨论了好久,终于把任务量化到具体多少时间完成了!

      恭喜!接下来,把n个任务按照开发的重要度,组合成n个sprint( 冲刺),每次执行一个sprint.

      

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

      

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

      

      在burn down chart 里面,不管任务是否按时完成都必须记录。

      

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

      

      在白板上面当前sprint 每天肯定都是在变的,scrum master 赶快把每天更新工作量吧!更新后算出剩余时间,就画在burn down chart上。

      

      关于bugs... ...

      每个sprint 都必须测试,尽量大家一起测试吧,如果太多bug就开一个sprint来修复bugs.

      

      每天要做的是,要开standing meeting ,因为大家的时间都是非常紧张的,一般是站着开的,一般10分钟左右.

      

      会议就问开发团队每个人三个问题:

      (1)你今天做了什么

      (2)明天打算做什么

      (3)有没遇到什么困难?

      scrum master 要解决开发团队的困难,让项目快速进展下去。

      每周一次周会,product owner最好在场。 每个月一次月会,product owner最好在场,指出产品开发是否在product owner期待范围内。

      

      好吧, 如此重复下去,直到开发完成!

      Scrum 步骤五:

      最后一个步骤,评估。

      product owner 和其团队/用户会对产品进行评估,可能还会有各种揪心的事,但是product owner是给钱的主,他要改还是要改的,建立一个bugs sprint吧,把产品做到product owner最想要为止!

      

      写在最后的话

      SCRUM也有缺点一直被人诟病,就是对团队要求高,团队成员相互信任度高,团队的人有能力,而且不会相互推搪责任,归根到底对应新团队使用该方法开始是各种问题的!请多多磨合吧!

      

      作者微信:terrydengbin

      最后直接送上干货ppt, keynote, pdf! 编写该教程我是使用了keynote 里面文字少,基本都是动画哦!!有mac的童鞋有福啦,我也转成了ppt格式,动画肯定会损失的,还有pdf可以下载。

      大家关注“今日发现”微信公众号,输入“SCRUM"即可获得下载地址!

    展开全文
  • 【课程目标】:快速学习、应用Scrum敏捷开发方法   【课程呈现形式】:PPT课件+讲解   【课程特点】: 1)课程体系结构清晰,课程内容丰富,在课程内容中插入了部分实际工作场景和真实的项目案例。 2)以...
  • Scrum敏捷开发

    2020-07-15 10:34:45
    敏捷开发(Agile)是一种以人为核心、迭代、循序渐进的开发方法。 在敏捷开发中,软件项目的构建被切分成多个阶段,各个阶段的成果都经过测试,具备集成和可运行的特征。 简单地来说,敏捷开发并不追求前期完美的...

    scu程序设计实践-2

    瀑布模式

    在这里插入图片描述

    敏捷开发

    什么是敏捷开发

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

    在敏捷开发中,软件项目的构建被切分成多个阶段,各个阶段的成果都经过测试,具备集成和可运行的特征。

    简单地来说,敏捷开发并不追求前期完美的设计、完美编码,而是力求在很短的周期内开发出产品的核心功能,尽早发布出可用的版本。然后在后续的生产周期内,按照新需求不断迭代升级,完善产品。

    敏捷宣言

    在这里插入图片描述

    敏捷开发分类

    在这里插入图片描述

    Scrum

    Scrum是敏捷众多方法中最流行的一种。是一种开发创新产品和服务的敏捷(Agile)方法。

    Scrum基本术语

    在这里插入图片描述

    Sprint:

    冲刺周期,通俗的讲就是实现一个“小目标”的周期。一般需要2-6周时间。

    User Story:

    用户的外在业务需求。拿银行系统来举例的话,一个Story可以是用户的存款行为,或者是查询余额等等。也就是所谓的小目标本身。

    Task:

    由User Story 拆分成的具体开发任务。

    Backlog:

    需求列表,可以看成是小目标的清单。分为Sprint Backlog和Product Backlog。

    Daily meeting:

    每天的例会,用于监控项目进度。有些公司直接称其为Scrum。

    Sprint Review meeting:

    冲刺评审会议,让团队成员们演示成果。

    Sprint burn down:

    冲刺燃尽图,说白了就是记录当前周期的需求完成情况。

    Rlease:

    开发周期完成,项目发布新的可用版本。

    Scrum团队架构

    Scrum开发工作由一个或多个Scrum团队组成,每个团队由三个Scrum角色组成:产品负责人(Product Owner),Scrum Master 和 开发团队。 在使用Scrum时可能还有其他角色,但Scrum框架只需要这里列出的三个。

    产品负责人负责敲定要开发什么、以什么顺序开发。 Scrum Master负责指导团队在通用的Scrum框架上建立并遵循自己的流程。 开发团队负责确定如何交付产品负责人要求的内容。

    如果您是经理,请不要担心“经理”在下图中不会出现; 管理人员在使用Scrum的组织中仍然发挥着重要作用。 Scrum框架仅定义了特定于Scrum的角色,而不是在使用Scrum的组织中可以存在的所有角色。

    在这里插入图片描述

    产品负责人(Product Owner)

    产品所有者是有授权的产品领导力的中心点。 他是唯一有权决定要构建哪些特性并以何种顺序构建这些特性的人。对于Scrum团队要实现的目标,产品负责人要保持一个清晰的构想并把他传达给每一位参与者。产品负责人的身份决定着他要面对正在开发或维护的解决方案全面负责。

    这里所说的产品可以是外部产品,也可以是内部应用程序。产品负责人还有责任确保总能完成价值最高的工作,这些工作也可能包含偏技术的工作。为了确保开发团队快速构建产品负责人需要的产品,产品负责人要与Scrum Master和开发团队积极合作,及时解答Scrum Master和开发团队提出的问题。

    Scrum Master

    ScrumMaster帮助每个参与者理解并乐于接受价值观、原则和实践。 她充当教练,在过程中方面发挥教导作用,帮助Scrum团队及组织的其他人制定合适的高绩效、有组织特色的Scrum方式。 同时,在采用Scrum时,可能有一个充满挑战的变革管理过程,Scrum Master要帮助组织顺利适应这个过程。

    作为辅助者,Scrum Master要帮助团队解决问题和改进Scrum的使用状况。他还有责任保护团队不受外界干扰,(在个人无法有效解决遇到的障碍时)发挥领导作用,清除阻碍团队生产率的障碍。ScrumMaster没有权限控制团队,这个角色不同于项目经理或开发经理等传统角色。Scrum Master担任的是领导者,不是管理者。

    开发团队(Development Team)

    传统的软件开发方法论述的是各种类型的职位,例如架构师,程序员,测试人员,数据库管理员,UI设计者等。 Scrum定义的是开发团队的角色,这是一个由几种职位的人组成的多样化跨职能团队,负责产品的设计、构建和测试。

    开发团队自行组织,确定采用哪种最佳方式来实现产品负责人设定的目标。开发团队一般是5-9个人,团队成员作为一个整体,必须具有多种技能以构建高质量、可工作的软件。当然,如果开发工作需要一个大型的团队,也可以使用Scrum。比如一个大型Scrum团队,比如有35人,不太可能让一个Scrum团队拥有35人,而是分为4个或4个以上的Scrum团队,每个团队不超过9个人。

    整体流程

    在项目启动之前,会由团队的产品负责人(Product owner)按照需求优先级来明确出一份Product Backlog,为项目做出整体排期。

    随后在每一个小的迭代周期里,团队会根据计划(Sprint Plan Meeting)确定本周期的Sprint Backlog,再细化成一个个Task,分配给团队成员,进行具体开发工作。每一天,团队成员都会进行Daily meeting,根据情况更新自己的Task状态,整个团队更新Sprint burn down chart。

    当这一周期的Sprint backlog全部完成,团队会进行Spring review meeting,也就是评审会议。一切顺利的话,会发布出这一版本的Release,并且进行Sprint回顾会议(Sprint Retrospective Meeting)。

    迭代

    在这里插入图片描述

    在敏捷方法中,首先要开发产品列表(Product backlog) - 一个按优先级排列的、成功开发产品所需的特性及其他功能的列表。 在产品列表的指导下,我们总是先做最重要或优先级最高的条目。 当资源耗尽(例如时间)时,所有未完成的工作的优先级将低于已完成的工作。

    工作本身是在一些短期的、时长固定的迭代中完成的,每次迭代时间通常为1周到一个月。 在每次迭代中,自组织,跨职能的团队完成所有必需的工作 - 例如设计,构建和测试 - 产生完整的、可工作的、可以放入产品的特性。

    通常,产品列表中的工作量远远不是团队在一次短期迭代中能够完成的。所以,在每次迭代开始时,团队需要制定计划,说明在下一个迭代中要创建产品列表中哪一个高优先级子集。 例如,在上图中,团队已经同意它可以创建功能A,B和C。

    在迭代结束时,团队与利益干系人一起评审已完成的功能,获取他们的反馈。 根据反馈,**产品负责人(Product Owner)和团队(Team)**即可对下一步工作内容进行修改,也可以修改以前的工作方式。 例如,如果利益干系人在看到一个完成的特性时,意识到自己没有考虑到另一个必须包含在产品中的特性,此时,产品负责人只需建立一个代表该特性的新条目并把它以适当的优先顺序插入产品列表,留到后面的迭代中迭代完成。

    在每次迭代结束时,团队应该有一个潜在可交付的产品(或产品的增量),如果业务上合适,就可以发布。 如果不适宜在每次迭代后发布,可以把多个迭代的一组特性合并在一起发布。

    在每次迭代结束后,从规划下一个迭代开始,重新开始整个过程。

    Scrum优势

    在这里插入图片描述

    Scrum活动与工件详细

    在这里插入图片描述
    从图的左边开始,沿着最大的环形箭头(Sprint)顺时针介绍。

    产品负责人建立产品愿景(图中大立方体)。因为这个立方体可能很大,所以要通过梳理活动分解为一组特性并收集到列表按优先级排序的列表中。

    Sprint (冲刺)首先是Sprint 计划(也称冲刺计划),在Sprint过程(也称Sprint执行)包含开发工作,最后是评审和回顾。Sprint由图最大的环形箭头表示。产品列表中的条目可能超过开发团队一个Sprint中可以完成的工作量。因此,在每个Sprint开始时,开发团队必须把自己认为能够完成的PBI的子集确定下来–这个活动成为Sprint规划会(sprint planning)

    接下来是Sprint执行(Sprint execution),开发团队执行一些必要的任务,以实现所选功能。 在sprint执行中的每一天,团队成员都要进行同步、检查与调整计划,通过**每日例会(standup meeting)**这种活动来帮助管理工作流。 在Sprint执行结束时,团队产出一个潜在的可发布产品增量,体现产品负责人所构想的部分产品,并不是全部。

    Scrum团队在Sprint结束后要执行两个“检视与调整”活动。第一个,称为sprint评审(sprint review),利益干系人和Scrum团队检视正在构建的产品。 第二个活动称为sprint回顾(sprint retrospective),Scrum团队在这个活动中检视构建产品时所用的Scrum过程。 这些活动带来的结果可能对产品列表或团队开发部分过程进行适应性调整。

    此时再次重复进行scrum sprint的循环过程,在重新开始时开发团队要确定能够完成的下一批最重要的PBI(产品列表条目)。在完成适当的Sprint之后,就可以实现产品负责人的构想并发布解决方案。

    产品列表(Product Backlog Item/PBI

    在使用scrum时,我们总是先做最有价值的工作。产品负责人结合Scrum团队其他成员与利益干系人的意见,最终负责确定和管理工作顺序,并采取产品列表(按优先级排列/排序的列表)的形式传达给别人。在开发新产品时,PBI在刚开始时是为满足产品负责人的设想而需要开发的特性。对于正在开发的产品,产品列表也可能包含新特性、对现有特性的变更、需要修复的缺陷以及技术改进点等。

    产品负责人与内外部利益干系人合作收集并定义PBIO接下来确保PBI是以正确的顺序(使用类似于价值、成本、知识和风险之类的因子)放置的,使高价值条目出现在产品列表的顶部,低价值条目出现在底部。产品列表是一个不断演进的工件。在业务环境发生变化或Scrum团队(通过Sprint获取对软件的反馈)深入了解产品后,可以添加、删除或修改其中的条目。
    在这里插入图片描述
    总体来说,建立和优化PBI、估算并确定他们的优先顺序,这样的活动成为**“梳理”**。

    在这里插入图片描述
    在确定好优先顺序、排好序或者说是安排好产品列表之前,还需要知道产品列表中每个条目的大小

    在这里插入图片描述
    条目大小等同于成本,为了合理确定条目的优先级,产品负责人需要知道条目的成本。Scrum没有规定PBI的大小要用哪种方法来测量。在实践中,很多团队使用相对大小测量,例如故事点(story point)或理想天数。在使用相对大小测量表达项目的整体大小时,不考虑绝对值,而是考虑一个条目与其他条目的相对值。例如,在上图中,特性C的大小是2,特性E的大小是8。由此可以得出结论,特性E的大小大约是特性C的4倍。

    Sprint(冲刺)

    在Scrum中,工作在不超过一个月的迭代或循环中进行,这个迭代被成为Sprint(冲刺)。每个Sprint完成的工作应当创建一些对客户或用户来说具有明确价值的东西。
    在这里插入图片描述
    冲刺是有一定时间范围的,总是有固定的开始和结束日期,而且一般来说冲刺的持续期应当都是相等的。前一个冲刺结束后马上就会开始一个新冲刺。在一个冲刺中通常不允许改变范围内的目标或是更换人员,不过,有时业务需求使我们无法遵守这个规则。

    Sprint 计划(Sprint Planning)

    产品列表体现的可能是多周或多个月的工作,是一个短期的冲刺根本无法完成的。为了确定下一个冲刺要构建的PBI最重要的子集,产品负责人、开发团队和ScrumMaster需要做冲刺规划。

    在做冲刺规划期间,产品负责人和开发团队要对当前冲刺准备实现的冲刺目标达成一致意见。针对这个目标,开发团队要对产品列表进行评审,确定在以可持续的节奏工作时根据实际情况在当前冲刺中能够完成的高优先级条目一一一可持续的节奏指的是开发团队能够轻松、长时间保持的工作节奏。
    在这里插入图片描述
    为了获得完成工作的信心,很多开发团队都会把每个需要完成的特性分解为一组任务。这组任务及其相关的PBI组成了第二个列表,称为“冲刺列表”。
    在这里插入图片描述
    接下来,开发团队给出完成每项任务所需工作量的估算值(通常以小时计)。把PBI分解为任务是一种设计形式,是适时(just-in-time)制定特性完成计划。
    大多数Scrum团队在执行一个两周到一个月的冲刺时,都尽量在大约4到8小时内完成冲刺规划。一个一周的冲刺中,用于计划的时间应当不超过几个小时(或许还应当更短)。此时有几种方法可以使用。

    最常用的方法是遵照一个简单的循环:选择一个PBI(尽可能选择由产品负责人定义的下一个最重要的条目),把条目分解成任务,确定把所选择的项目放到冲刺中是否合适(要和同一个冲
    刺中的其他条目结合起来考虑)。如果合适并且还有更多的能力完成工作,可以重复这个循环过程,直到团队没有能力再做更多的工作为止。另外一个方法是由产品负责人和团队一次选择所有目标PBIO由开发团队自己独立分解任务,确认团队是否确实可以交付所有选定的PBI。

    Sprint 执行(Sprint Execution)

    在Scrum团队完成冲刺计划并就下一个冲刺的内容达成一致意见后,开发团队就要在ScrumMaster的指导下,执行为了完成特性而所需的所有任务级的工作,此处所说的“完成”指
    的是非常有信心地认为对于产出高质量特性所需的所有工作都己完成了。

    当然,团队要执行哪些类型的任务,取决于工作特点。例如,我们是在构建软件吗,构建的是什么类型的软件?或者我们是在制造硬
    件吗?或者这是一个市场推广工作吗?没有人告诉开发团队在完成一个冲刺列表的这段时间中以什么顺序、什么方式执行任务级的工作。相反,团队成员要定义自己的任务级工作,然后按照自认为最好的方式进行自组织并实现冲刺目标。
    在这里插入图片描述

    每日例会(Daily Scrum)

    在冲刺期间的每一天,理想的做法是在每天同一时间,开发团队举行一定时间范围内的每日例会。这个检视与调整活动有时也称为“每日站会”,因为大家站着开会可以使会议简明扼要。
    在这里插入图片描述
    举行每日例会的一个常见做法是ScrumMaster负责确保会议更顺畅,每个团队成员都要轮流回答三个问题,让其他团队成员了解情况。

    在上次每日例会之后我完成了什么?
    在下次每日例会之前我计划做什么工作?
    有什么障碍让我无法取得进展?

    通过回答这些问题,每个人都能了解全局,知道发生了什么事情,实现冲刺目标的进展如何,对当天的工作,是否需要修改计划,有什么需要处理的问题。每日例会是必不可少的,能够帮助团队管理一个冲刺内快速、灵活的工作流。

    每日例会不是用来解决问题的。相反,很多团队会选择把问题的讨论放到每日例会之后和一小部分感兴趣的人讨论。每日例会也不是传统意义上的状态会议,尤其不是以前那种由项目经理召集、为了解项目最新状态而举行的会议。不过每日例会对于开发团队成员交流冲刺列表条目的状态也是可能有帮助的。每日例会主要是一个检视、同步、适应性制定每日计划的活动,以帮助组织团队更好地完成工作。

    完成

    在scrum中,我们把冲刺的成果称为“潜在可发布产品增量”,意思是按照大家一致同意的“完成"的定义来看,scrum团队同意做的所有东西都做完了。这个定义明确说明了要有信心确保完成的工作是高质量的、潜在可发布的。例如,在开发软件时,“完成”的最低限度的定义是应当产出一个完整的产品功能,经过设计、构建、集成、测试并且编写了文档。
    在这里插入图片描述
    “完成”最激进的一个定义是当业务部门想要交付(或部署、发布)时,能够确定每个冲刺中要为内外部客户构建什么。

    需要明确一点,“潜在可发布”并不是说构建的东西必须实际交付。交付是一个业务上的决策,经常受其他因素的影响,比如“我们是否开发了足够的特性或足够的客户工作流来满足客户的部署要求?”或者“我们两星期前才给过客户一个版本,他们能够消化另外一次修改吗?”

    “潜在可发布”最好理解为对冲刺中实际构建的产品的一种信心,意味着如果业务部门想要交付的话,那么我们在交付这个冲刺的结果之前,不需要再做其他重要工作(比如重要的测试和集成等)。

    在实际应用时,随着时间的推移,有些团队可能会修改完成的定义。例如,在游戏开发早期,提交一些潜在可发布物在经济上不可行或是不可取(因为游戏开发的早期是探索性质的)。在这些情况中,“完成”的一个适当的定义可以是完成一部分产品功能,提供的功能和可以使用的程度足以用来反馈,让团队确定下一个Sprint需要做什么、如何完成。

    Sprint评审(Sprint Review)

    在Sprint技术时还有两个**sprint评审(sprint review)**和 **sprint回顾(sprint retrospective)**活动,这个活动的目的是检查与调整正在构建的产品。这个活动很重要的一点是在参与者之间进行的交谈,包括scrum团队、利益干系人、发起人、客户和其他团队中感兴趣的成员。交谈的重点是在把刚刚做完的特性放到整体开发工作的背景下进行讨论。每个参与者都能清楚了解现状,都有机会指导下一步开发工作,以确保产出最合适的解决方案。

    成功的冲刺评审会议可以促成双方充分交流信息。非Scrum团队的人员能够跟上开发工作并帮助指导开发方向。同时,在与业务部门一起交付满足客户或用户需要的产品时,经常收到反馈可以使scrum团队进一步理解产品的业务和市场。因此,冲刺评审是一个预先安排的检查与调整活动。在实践中,非scrum团队的人员可以在冲刺之间进行特性评审并提供反馈,帮助Scrum团队更好地实现冲刺目标。
    在这里插入图片描述

    Sprint回顾(Sprint Retrospective)

    冲刺评审是检视和调整产品的时间,而冲刺回顾则是检视并调整过程的时机。在进行冲刺回顾时,开发团队、ScrumMaster和产品负责人聚到一起讨论scrum及相关技术实践中哪些是可行的、哪些是不可行的。重点关注的是必要的持续过程改进,帮助优秀的Scrum团队成长为卓越的团队。在冲刺回顾活动结束时,Scrum团队应当找出数量适中的过程改进项并承诺在下一个冲刺中采用。在完成冲刺回顾之后,再次重复整个过程一一开始时是下一个冲刺规划会议,举行这个会议的目的是确定当前团队必须关注的价值最高的工作。
    在这里插入图片描述

    展开全文
  • 敏捷游戏开发

    2011-10-03 15:59:48
    敏捷游戏开发Agile.Game.Development.with.Scrum.pdf
  • Scrum敏捷项目管理

    千次阅读 2017-04-29 03:56:32
    敏捷的背景与动机软件危机及软件工程的出现 速度是企业竞争致胜的关键因素,软件项目的最大挑战在于 ...这正是Agile Process (敏捷的软件开发流程)于近年来兴起的主要原因。软件项目的复杂性横轴代表需求的复杂度!

    敏捷的背景与动机

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

    万人学习 2015-08-20 14:22:02
    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问...
  • 敏捷全球之旅2012 中国 @深圳敏捷部落   主 题:导入创业精神-专治大公司病 讲 师:王晓明(敏思特咨询首席合伙人,腾讯高级管理顾问,组织转型导师,创新工场特聘导师, 华为首位敏捷组织转型咨询师...
  • 敏捷开发已经成为常态化,随着计算机与网络技术的日渐成熟,互联网以及以互联网为平台的各种网上应用如火如荼,在给传统产业带来无限商机的同时,也带来更多的挑战。首先,经历多年的激烈竞争历程,企业之间的竞争已...
  • 敏捷开发——SCRUM

    万人学习 2014-12-02 16:34:35
    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。
  • 极限编程(XP)和SCRUM大概是2种最著名的敏捷开发方法。二者有啥区别呢? 一、XP的特点 1、迭代周期更短,并强调持续反馈 2、测试驱动,自动化测试 3、项目初期迅速生成总体计划,之后迭代发展和完善 4、持续演化 5...
  • 上周公司安排参加了2天的Scrum认证培训,感觉收获不少,总结一下。 之前公司也安排参加过不少外训,项目管理的、领导力的都有,总的来说这次课程感觉有一些不一样。 课程是Scrum中文网主办的,老师是来自瑞典的一...
  • 敏捷开发Scrum扫盲篇

    千次阅读 2017-03-18 19:50:13
    现在敏捷开发是越来越火了,人人都在谈敏捷,人人都在学习Scrum和XP...   为了不落后他人,于是我也开始学习Scrum,今天主要是对我最近阅读的相关资料,根据自己的理解,用自己的话来讲述Scrum中的各个环节,主要...
  • 典型的敏捷开发方法:SCRUM和XP — 笔记整理自 北京理工大学 计算机学院 典型敏捷方法之SCRUM 来源于橄榄球比赛的英语, scrum vi.参加并列争球 vt.抛(球)开始并列争球 n.扭打, 混乱, 并列争球 团队成员像打橄榄球...
  • 他所服务过的客户遍及金融、保险、通讯、互联网、游戏开发、软件外包等多个行业领域的百余家知名企业,典型客户包括中国移动、甲骨文、招商银行、中科院物联网研究所、中国银行、交通银行、中国银联、平安陆金所、...
  • 之前已经说过很多关于敏捷开发的东西,过多的鸡汤就不再鳌述。其实,敏捷开发已经成为常态化,随着计算机与网络技术的日渐成熟,互联网以及以互联网为平台的各种网上应用如火如荼,在给传统产业带来无限商机的同时,...
  • scrum实战免费课
  • Scrum硬币游戏和the-scrum-penny-game-a-modification中都介绍了这个硬币游戏,我觉得不错,如果游戏者真正参与进来,应该能够体会到较多的敏捷思想。而最近项目组也来了很多新的MM,她们对敏捷不太清楚,而这个...
  • scrum进行游戏开发 It's never surprised me that scrum has a bit of a controversial reputation. While some praise scrum for its effective and straightforward approach to software development, there ...
  • 使用Scrum进行敏捷项目管理

    万次阅读 2018-12-27 13:27:25
    Scrum是一种敏捷方法,旨在指导团队进行产品的迭代和增量交付。通常被称为“敏捷项目管理框架”,其重点是使用经验过程,使团队能够快速,有效,有效地做出改变。传统的项目管理方法确定了需求,以控制时间和成本; ...
  • 一本scrum方面的大部头, 很多内容讲的比较细, 也比较全, 很多地方都涉及到项目管理的知识, 当然还有敏捷相关的知识, 不过较少, 有选择性的看了看, 算是其他scrum书籍的一个补充吧. ----------------我是读书.....
  • 图解敏捷教练和 ScrumMaster

    千次阅读 多人点赞 2018-04-12 10:41:39
    敏捷教练和 Scrum Master 是一种专业的职业。其职责是帮助团队和组织做到更好(本课程视 Scrum Master 和敏捷教练为同一职业的不同发展阶段)。敏捷能力的培养并不是简单了解后就可以速成的,但如同任何其他职业一样...
  • SCRUM敏捷开发

    2016-07-31 07:18:48
    由于团队最近计划执行不顺利,项目经理在知道我经历过敏捷开发的流程后,让我给团队内部的各个小组分享SCRUM敏捷开发相关的知识,并负责推动团队敏捷开发计划的建设。  scrum 是一种迭代增量软件开发方法,通过该...
  • 敏捷开发Scrum稍有了解的都知道Scrum来源于橄榄球,但你知道为何要以这项球类运动的术语来命名这个敏捷开发方法论吗? Scrum与橄榄球对应关系 Scrum 一词源于英式橄榄球运动,是指双方球员对阵争球。双方前锋肩靠...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,890
精华内容 1,156
关键字:

scrum敏捷游戏开发