Scrum敏捷软件开发过程Word格式文档下载.docx
- 文档编号:20033239
- 上传时间:2023-01-16
- 格式:DOCX
- 页数:28
- 大小:1.06MB
Scrum敏捷软件开发过程Word格式文档下载.docx
《Scrum敏捷软件开发过程Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《Scrum敏捷软件开发过程Word格式文档下载.docx(28页珍藏版)》请在冰豆网上搜索。
•对整个项目做一个粗略估计,每一次迭代都有详细计划.
•鼓励变化,客户价值驱动开发.
•信任和赋予权力;
合约使变更变得简单,增加价值.
•客户和开发人员之间是紧密连续合作关系
•每次迭代都产生可交付软件
•专注于交付软件.
•第一次迭代就可交付能工作版本,风险发现早.
为什么采用敏捷?
–预期收益
•采用敏捷方法得当话,可以:
•更加透明;
随时跟踪项目状态和进展情况,及早发现问题和风险.
•快速交付,每次迭代都能交付可运行软件.
•最高风险和最高优先级需求,最优先进行开发.
•改善应对变更能力,减少大量重计划.
•改善项目沟通.
•更好客户参与,避免错误假设.
•总之:
•提高了生产率;
减少“浪费”(不需要文档,重复工作等),项目每次迭代都有明确目标.
•提高客户满意度;
短期内产生成效,按预期交付软件,每次迭代结束产生可以运行软件.
•改善员工满意度;
团队精神,减少官僚,能够规划和管理自己工作,减少“恐慌”,稳定工作量(可持续步伐).
敏捷方法何时有效?
•公司和客户一致认为应当使用敏捷方法,双方都能理解敏捷方法.
•敏捷方法对需求不完整以及经常变换项目比较有效.
•项目可以划分成固定时间间隔迭代,并且可以冻结正在进行迭代范围
•公司和客户都有能力担当角色尤其是ProductOwner和ScrumMaster.
•项目人员结构能够分成6到10人团队,最好每个工作地点一个小组.
•团队成员能够以自组织方式工作.
•项目合同允许变更.
•固定价格项目可以使用敏捷,但应当尽量避免。
•最好在按时间和材料付费或者按月付费项目中进行使用
•变更项目范围不需要高级管理层批准.
Scrum概述
Scrum概述(1/3)
•Scrum是管理软件项目一个轻量级敏捷方法,名字来源于橄榄球运动中scrum过程
•简单,但高度纪律性
•依赖迭代和增量敏捷方法.
•Scrum是一种工作管理方法,不仅仅限于软件开发,可以用来管理其它活动.
•Scrum不包含技术方法或实践.
Scrum概述(2/3)–项目阶段
•项目分成增量迭代过程,在Scrum中称为迭代任务清单,通常持续2-4周时间.
•Sprint时间是限定好;
不能从外部改变正在进行中sprint持续时间和范围.
•每个sprint都可以产生可交付迭代,即测试过并具备文档功能点
•原则上,当产品开发到一定程度时,如实现了足够客户价值,项目可以在任何一个sprint后结束.
•如同任何项目,敏捷项目有三个主要阶段:
•产品定义(规划);
运行Sprints所需要准备、规划、技术分析.
•执行Sprints(执行):
在增量时间段内实现需求(产品需求清单).
•结束:
准备最终发布,结束项目
Scrum概述(3/3)
Scrum流程
1、将整个产品Backlog分解成SprintBacklog,按照目前人力物力条件可以完成。
2、召开Sprint计划会议,划分、确定这个Sprint内需要完成任务,标注任务优先级并分配给每个成员。
注意这里任务是以小时计算,并不是按人天计算,长度不超过8小时。
3、进入Sprint开发周期,每个Sprint迭代周期为连续30个日例日(2-4周)。
在这个周期内,每天需要召开每日Scrum简会,时间为15分钟。
在会议中每个团队成员仅就以下三点发言:
自上次Scrum会议后你做了什么?
从现在到下次Scrum会议时间里你准备做什么?
你在工作中遇到了哪些困难?
4、整个Sprint周期结束,召开Sprint评审会议(Sprintreviewmeeting),将成果演示给ProductOwner,该会议限定时间为4小时。
5、团队成员最后召开冲刺回顾会议(Sprintretrospectivemeeting),总结问题和经验,该会议限定时间为3小时。
6、这样周而复始,按照同样步骤进行下一次Sprint。
Scrum角色、实践和工作产品
Scrum中三种角色
•ProductOwner-产品所有者
•个人:
代表所有干系人
•ScrumMaster:
负责指导过程执行
•ScrumTeam–Scrum团队:
•承诺完成工作,向干系人交付产品价值
◆Scrum角色–Scrum团队
•Scrum团队是Scrum中心角色,产品交付要依靠团队.
•Scrum团队自我组织、自我管理
•Scrum团队是职能交叉,包含产品交付所有角色:
开发人员、测试人员、buildmanagers,文档编写,界面设计人员.
•Scrum团队中角色是不分等级;
不应当出现“我是开发人员我不作测试”.
•团队按照最有利于项目原则来分担责任(如组件所有权等).
•敏捷是建立在信任和授权基础上,因此团队是自发组织,组员选择自己任务,而不是别人强制加以分配.
•另一方面,Scrum团队有交付责任,他们需要能够自我激励和对工作目标进行承诺.
•团队最佳规模:
6-10人
•主要职责
•参与迭代任务清单创建
•执行为干系人创造价值工作
•根据团队承诺完成所需各项任务
•将工作中各项障碍迅速与ScrumMaster进行沟通
•全面参与所有各项会议
•更新任务状态
•自发选择任务
•标识任务完成
•标识发现新任务
•与其它团队共同进行工作
◆Scrum角色–ScrumMaster
•ScrumMaster不是一个管理者,而是一个教练和推动者-Scrum团队是一种自发组织,是自我管理.
•ScrumMaster角色通常由项目组成员担当,组长或者项目经理。
ScrumMaster应当是项目中成员.
•主要职责:
•评价过程健康状况
•加强过程
•消除障碍
•促进过程改进
•支持团队开发
•ScrumMaster主要工作是做决策、消除障碍,保证团队能顺利交付产品
•ScrumMaster还有如下责任
•与其它角色配合.
•训练团队,提高生产率.
•培训产品所有者和干系人,确保Scrum流程执行
•确保一切工作按照既定规范来运行.
•规划并进行必要改进.
•推动会议召开.
•维护障碍列表
•维护Scrum过程改进列表
•优秀ScrumMaster应当是专注,、有决心、有领导才能.
◆Scrum角色–ProductOwner
•产品所有者代表投资方利益,确保交付产品与期望一致(提供更好投资回报).
•ProductOwner决定产品具有哪些功能.
•ProductOwner’s主要责任是创建和维护产品需求清单,即管理项目范围.
•ProductOwner不断把产品需求清单按优先级进行排序,使得最重要功能能优先实现.
•对于团队来说,只有一个需求集。
所有需求申请都归口到ProductOwner
•管理商业价值(投资回报)
•ProductOwner还有如下责任:
•计划项目发布,什么时间、向什么人等.
•对每次Sprint结果进行评审和批准
•参与Scrum会议
•迭代计划会议
•团队进展跟踪会议
•迭代评审和回顾会议
•能够随时回答团队工作中产生各项和产品/业务相关问题
•ProductOwner角色一般由客户担当,作为服务提供商公司无法设定优先级.
◆Scrum角色–客户与管理层
•客户和管理角色是可选,需要时才设立
•客户:
•是产品最终用户
•通过ProductOwner来设定对产品期望
•把当前业务传达给项目.
•管理层:
•公司高级管理层,代表公司在项目中利益.
•通过ProductOwner来传达公司利益和优先级(priorities)
产品需求清单ProductBacklog
概论
•基本上,产品需求清单是为了实现产品功能所需要工作列表,包括:
•功能方面需求;
功能点.
•非功能方面需求,如性能改进.
•要修改Bug;
上一版本已知错误.
•新技术,如支持新操作系统或者平台.
•问题;
日后不确定项,如新功能.
•产品需求清单是不断完善.
•ProductOwner在项目进行过程中可以随时更新:
增加、删除、修改功能,变更优先级等.
•下一次迭代中要包含较高优先级需求.
•产品需求清单也可称为UserStories(用例),因为它们能够给产品用户带来价值.
•在一次迭代中要能够实现产品需求清单,如果不能全部实现要进行分解.
构成
•ProductOwner负责创建最初产品需求清单,一开始是不完整.
•最初清单应当包含足够需求.
•清单应当包含多少需求,取决于定价模型(black-box,更多计划时间).
•产品需求清单来源于:
•客户;
标书,需求规格说明等.
•Scrum团队想法;
增强型新功能等.
•现有产品迭代增量;
已知错误,技术问题等.
•比较好做法是ProductOwner、Scrum团队、客户/管理以及其它相关方(如相关Scrum团队)举行一次或者多次研讨会
•ScrumMaster或者ProductOwner来促成会议召开,必须要有人来做.
•要有效率、要围绕主题、沟通良好、避免不同假设,
•承诺并且共通合作,确定优先级.
估计
•Scrum团队对产品需求清单每一项规模提供初步估计,通常采用事件点作为单位StoryPoints(模糊).
•也可采用人天或者人小时作为单位,但容易混淆:
a)实际规模b)时间单位.
•精确估计值可以在Sprint规划时给出,当前阶段没有足够信息.
•规模相对值才有意义.
•这个估计值有助于确定优先级;
优先级
•优先级是产品需求清单中主要问题.
•优先级不但反映了客户价值也反映了风险.
•产品所有者-PO设定优先级.
•清单中每一项优先级是唯一,但可以对它们进行分类
•优先级可以在项目任何时候进行更改;
如新重要功能可以直接给较高优先级.
•确定优先级考虑:
•价值
•风险
•依赖关系
示例
版本发布计划
•在Scrum中,不是每个Sprints都要发布一个版本.
•迭代结果主要是要实现功能演示,不一定就是发布版本.
•版本发布计划决定了每次迭代应当包含产品需求清单哪些功能.
•根据现有信息制定项目总体长期计划.
•根据产品需求清单和团队进度来决定(实施范围/迭代,e.g.inStoryPoints).
•Scrum团队参与版本发布计划制定;
架构、风险、依赖性决定了可行实现顺序.
•版本发布计划很大程度上依赖于客户时间表和发布周期,即什么时候客户产品需要包含我们模块(交付物).
•版本发布计划不是一成不变;
每个迭代结束后都可以更改.
完成定义
•当迭代任务清单上任务都完成时,变为“已完成”状态
•定义“已完成”含义是非常重要,例如:
•如何记录软件变化.
•使用什么样代码分析工具,发现问题应当如何处理.
•进行了什么样测试,结果是如何记录,通过标准(如覆盖率、修正错误)是什么.
•定义“已完成”意味着定义质量上需求.
•“已完成”是0/1变量:
完成或者未完成.所有任务(task)都完成了迭代任务才算完成.
•在第一个迭代开始之前应该定义好,因为它会影响工作量,而且必须文档化,这样团队和产品所有者理解是一致.
•完成范围随着团队成熟程度会逐渐发生变化
完成定义-Example
•完成定义
•遵循编码规范
•能在模拟器上演示
•使用PCLint进行静态代码分析
•具有EUnit测试套件通过率和执行率.
•或者使用结对编程,或者进行代码走查
迭代任务清单SprintBacklog
总论
•迭代任务清单规划主要目是从产品任务清单中挑选高优先级任务包含在下一次迭代中,即确定迭代范围.
•至于能够包含多少产品任务清单中任务取决于Scum团队能够承诺完成多少.
•承诺总是来自于内部,不能从外部强加.
•迭代不应当有空闲时间,因此规划迭代范围时要保证工作量是稳定(进度是持续速度).
•依赖多个因素;
团队能力,技术成熟度,当前迭代增量情况等.
•迭代范围在迭代任务清单中描述;
团队设定优先级.
•产品所有者PO定义每个迭代任务说明(missionstatement),目标(sprintgoal),使迭代更具有针对性,如.“实现一个可扩展列表控件,其项目是可以选择”
输入和输出
逻辑
•迭代任务清单规划是“铁三角”法则另一个例子
•在Scrum,边界是一个变量,因为:
•资源(Scrum团队)是确定.
•进度表(迭代时间)是不能变.
•质量是无法协商
•团队在一个迭代内能完成任务,可以用团队进度来衡量(StoryPoints/Sprint).
•如果可能话利用同一个团队上个迭代进度,“yesterday’sweather”.
规划会议
•召开迭代任务清单规划会议目是确定迭代边界.
•时间是限定,最长时间是一个工作日(对持续4个星期迭代,迭代持续时间越短,用在规划上时间也应该越少.
•由ScrumMaster推动会议.
•由于会议时间有限,ProductOwner和Scrum团队都应该事前进行准备.
•前提:
产品需求清单是有效(valid);
最新,标注了优先级并且表述清楚.
•规划会议要解决两个问题:
•下次迭代要做什么.
•确定迭代目标,包含产品需求清单上高优先级功能.
•给Bug修改留一定余地
•怎么样实现下次增量所需要功能.
•改进设计以实现产品需求清单上功能.
工作流程
•产品所有者向团队介绍起草产品需求清单和迭代目标.
•产品所有者传达迭代起止日期.
•Scrum团队从产品需求清单中选取高优先级功能作为迭代任务,如果有必要,更新其规模估计.
•Scrum团队改进架构和设计以便能够实现提出产品需求.
•Scrum团队把产品需求清单每一项划分成小任务,并估算每个任务要花费小时数.
•“扑克规划”方法是估算工作量有效方法.
•Scrum团队决定一个迭代中能够实现产品需求清单多少功能
•产品所有者和Scrum团队明确了各自要承担义务.
SprintBacklog示例
执行迭代任务清单
•执行迭代任务清单意味着团队在迭代期间自行开发.
•团队清楚要达到什么目标以及怎样达到目标.
•每人每一时间只有一个任务
•团队是自发组织;
成员自己挑选任务,ScrumMaster提供指导并清除障碍.
•不能从外部改变迭代范围或者迭代周期.
•为了达到迭代目标,团队可以增加、删除任务或者改变其优先次序.
•如果要重新设定迭代范围时需要产品所有者配合.
•迭代周期短,意味着工期紧;
应该把重点放在剩余工作和风险消除,要区分任务优先级,重要事情应当先做.
•迭代应当达到项目质量要求(definitionof“done”);
没有独立测试阶段.
迭代进度图-BurndownChart
•Scrum注重成果,它关心是要花多少时间达到目标,而不是已经花费时间;
.
•团队能否在既定时间达到迭代目标,可以查看要完成产品需求清单功能所剩余工作
•Remainingwork=EstimatetoComplete(ETC).
•描述剩余工作量和时间关系图表称为SprintBurndown图,是Scrum中非常重要控制方法(controlmeasure).
•给Scrum团队和产品所有者提供直观信息.
•术语burndown表明Scrum团队在迭代过程中消耗剩余工作能力;
迭代结束时其值为0.
•每个任务(task)工作量由Scrum团队来估计.
•每天都要进行估计,以便进行跟踪.
•可以使用电子表格或者专门工具(如ScrumWorks)
Scrum每日例会
小鸡和猪故事
•Achickenandapigaretogetherwhenthechickensays,"
Let'
sstartarestaurant!
“
•Thepigthinksitoverandsays,"
Whatwouldwecallthisrestaurant?
“
•Thechickensays,"
Hamn'
Eggs!
•Thepigsays,"
Nothanks.I'
dbecommitted,butyou'
donlybeinvolved!
•InaDailySprint,onlyScrumMasterandScrumTeamarecommitted,andthusallowedtospeak.Othersareonlyinvolved.
概述
•例会最长15分钟,在整个迭代过程中每天同一时间召开.
•团队成员之间交流信息.
•了解项目真实进展情况
•交流风险和存在问题.
•面对面会议加强了承诺.
•ScrumMaster负责整个会议(会议地点,邀请等).
•其他人可以参与,但只允许ScrumMaster和Scrum团队成员讲话(小鸡和猪).
•例会之前团队要更新工作量估计,使进度表保持最新.
形式
•为使会议简短而富有成效,要遵循严格规程
•每个成员向其他人汇报以下内容:
•上次会议以后所做工作?
•下次会议之前要做工作?
•工作中是否有什么障碍?
•如果出现其它问题(如设计问题),应当在会议后处理.
•纪录会议纪要,例如wiki.
•要养成良好会议习惯
障碍
•基本上,任何阻止团队正常工作,都可称之为障碍,例如:
•无法访问信息系统.
•所需要信息不能及时提供或者提供不正确,如界面规格或者其它软件模块不到位或不正确
•开发环境或者原型系统出现问题
•其他任务分配:
培训,售前支持
•缺乏必要信息或者相应知识
•对于团队提出各项障碍,ScrumMaster要以列表形式进行记录,
谁来清除障碍?
•每个人
•自我管理、自我组织团队
•ScrumMaster
•产品所有者
•管理层
•其他相关干系人
•ScrumMaster负责确定障碍已经清除,不一定亲自自己清除
清除障碍
•某些障碍是浪费
•部分地完成工作
•额外过程
•额外功能
•任务转换
•等待
•缺陷
•清除障碍过程是团队和组织学习过程
浪费产生原因
•多问几个“为什么”
•对于每个标识障碍或者浪费,问一问“为什么”浪费会存在
•多问几个“为什么”,找到造成浪费根本原因
迭代中同步工作
•每次迭代不是小瀑布项目
•而是,每件事情同时都做一点
迭代非正常终止
•在Scrum中,结束正在进行迭代是一种极端行为,只有在万不得以情况下才能这么做.
•有时候确实需要停下来重新规划,而不是一味蛮干(bangingyourheadagainstthewall).
•迭代终止可能由下面人发起:
•Scrum团队,如果他们认为达不到目标或者目标不清楚.
•ScrumMaster,如果迭代没有进展,或者无法克服某个困难.
•客户/管理层,如果目标已经陈旧/过时(目标产品被取消,平台过时),或者其它原因(资源问题等).
•迭代终止以后,启动新迭代计划.
•导致迭代终止原因不应该在新迭代中再次出现.
•要考虑到合同方面问题,如时间表变更等.
迭代评审会议
•迭代评审,在迭代结束后进行,展示迭代成果(功能运行).
•确保成果与预期一致,收集反馈
•为项目提供一个参考点,根据目前位置计划下一期旅程
•为下次迭代提供输入(改正、修改、新想法à
可以由产品所有者添加到产品需求清单.
•与其它Scrum会议一样,ScrumMaster主持迭代评审会议,Scrum团队负责演示.
•参加会议其他人包括:
产品所有者ProductOwner(必须参加)、客户、管理人员,以及其它感兴趣人,例如其他Scrum团队(注意保密协议要求).
•评审会议时间是固定:
最长4个小时.
•评审会议应当是非正式、创造性,不用幻灯片等正式东西.
迭代评审–流程
•在评审会议召开之前,团队要做好准备:
•有组织、有效地进行演示,不要超过4个小时.
•谁来演示,演示什么,怎样演示?
•计划准备时间不要超过一个小时.
•迭代评审流程一个例子:
•ScrumMaster介绍本次迭代总体情况.
•目标和清单vs.实际结果,如果存在差距,原因是什么.
•Scrum团队简要介绍所涉及技术问题,如架构及其变更.
•Scrum团队演示已经实现功能:
•演示并进行功能说明
•在场人能够亲自尝试使用不同功能.
•ScrumMaster推动自由讨论,集思广益.
•迭代评审应当是互动;
有问题提出,问题解答,并欢迎提出想法和建议.
迭代评审–可能措施
•产品所有者根据评审结果可能采取如下行动:
•更新产品需求清单,重新设定优先级:
•包含没有按计划实现功能(进度比预期要慢,任务未完成).
•不在计划中当却已经实现功能
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Scrum 敏捷 软件 开发 过程