敏捷开发介绍.ppt
- 文档编号:18688807
- 上传时间:2023-09-12
- 格式:PPT
- 页数:81
- 大小:6.71MB
敏捷开发介绍.ppt
《敏捷开发介绍.ppt》由会员分享,可在线阅读,更多相关《敏捷开发介绍.ppt(81页珍藏版)》请在冰点文库上搜索。
PSST质量与成本管理部/系统工程部,华为敏捷软件开发解读,2009年06月N.001,Page2,关于管理者和软件开发相关人员掌握敏捷知识的要求为落实敏捷软件开发在我司的顺利推行,使广大软件开发管理者和开发人员深刻领会敏捷核心理念,熟练掌握敏捷实践方法,从而达到增强应对需求变化的能力、提高产品质量、提升开发效率和缩短交付周期等方面的目标。
为此,特提出如下要求:
PM及以上管理者要深刻领会敏捷核心理念、理解我司敏捷推行策略、了解各种敏捷实践。
软件开发相关人员(含PL、软件开发人员、软件测试人员、软件架构人员、系统分析人员、与软件相关的资料人员和研发质量人员)要深刻理解敏捷理念、掌握敏捷实践、了解我司敏捷推行策略。
通过敏捷相关知识的考试是软件开发相关人员任职资格的基本要求。
考试试题分为管理者版本和员工版本,分别针对管理者和员工应知应会的知识进行考试。
敏捷学习参考材料包括:
华为敏捷开发解读及相关附件。
目录,敏捷概述正确理解敏捷我司敏捷开发实施策略我司敏捷案例,Page4,业界敏捷浪潮,ISO9000(09版)标准将在原来八大原则的基础上新增敏捷原则2000年美国军方软件开发标准(DOD5000.2)推荐迭代为软件开发优选模式世界影响最大的美国波多里奇国家质量奖将敏捷作为核心的十一大原则之一,Page5,软件作坊,软件过程控制,重型过程,2001今敏捷正在流行,软件规模小,以作坊式开发为主;硬件飞速发展,软件规模和复杂度激增,引发软件危机;引入成熟生产制造管理方法,以“过程为中心”分阶段来控制软件开发(瀑布模型),一定程度上缓解了软件危机;软件失败的经验促使过程被不断增加约束和限制,软件开发过程日益“重型化”,开发效率降低、响应速度变慢;随着信息时代到来,需求变化更快,交付周期成为企业核心竞争力,轻量级的,更能适应变化的敏捷软件开发方法被普遍认可并迅速流行。
软件危机,20世纪60年代,80年代,90年代,软件开发顺应时代变化,从重型过程转向轻量型敏捷,70年代,敏捷诞生的历史背景,Page6,敏捷宣言揭示更好的软件开发方法,敏捷宣言(2001年)是敏捷起源的基础,由上述4个简单的价值观组成,敏捷宣言的签署推动了敏捷运动敏捷宣言本质是揭示一种更好的软件开发方式,启迪人们重新思考软件开发中的价值和如何更好的工作,敏捷宣言,Page7,软件更像一个活着的植物,软件开发是自底向上逐步有序的生长过程,类似于植物自然生长敏捷开发遵循软件客观规律,不断的进行迭代增量开发,最终交付符合客户价值的产品,传统开发,敏捷开发,敏捷更符合软件开发规律,Page8,敏捷对生产率、质量、满意度、成本有明显改进,82%的项目生产率有提高,78%的项目质量有提高,78%的项目客户满意度有提高,37%的项目成本有降低,*以上数据来自DDJ2008由ScottAmbler发起的网上调查结果,目录,敏捷概述正确理解敏捷统一敏捷认识敏捷理念解读敏捷实践解读我司敏捷开发实施策略我司敏捷案例,Page10,对敏捷的常见误解,误解一:
敏捷开发意味着可以不需要文档、设计和计划误解二:
敏捷只是一些优秀实践,或者是优秀实践的结合误解三:
敏捷只适用于小项目开发误解四:
敏捷只会对研发产生改变误解五:
管理者不需要亲自了解敏捷,只需要管理上支持就可以了误解六:
引入敏捷只需要按照既定的步骤去做就可以了误解七:
敏捷是CMM的替代品,是另一种流程误解八:
敏捷只注重特性的快速交付,在敏捷下架构不重要了,Page11,统一认识:
敏捷=理念+优秀实践+具体应用,理念,优秀实践,具体应用,理念(敏捷核心思想)敏捷包括3个层次优秀实践(敏捷的经验积累)具体应用(能够结合自身灵活应用才是真正敏捷),Page12,理念:
聚焦客户价值(Value),消除浪费,软件业:
45%的软件特性客户没有使用,Source:
StandishGroup来自5万个软件开发项目的调查,Source:
中国电信总工韦乐平在华为公司工程与技术大会上的讲话,Source:
如何提升软件开发效率08年统计,电信业:
“电信级”带来的浪费,“价值”在“敏捷宣言”中的体现,产品商业成功为目标,聚焦客户价值、围绕价值流消除浪费,我司:
研发版本废弃特性,07.1-08.6年某产品线所有产品中重要特性无应用的比例达22%(需求变更和分析不足占63%),Page13,理念:
激发团队(Team)潜能,加强协作,我司试点开发测试拉通,效率质量改善明显,团队是价值的真正创造者,应加强团队协作、激发团队潜能软件开发是一种团队活动,首先应做到提升沟通效率降低交流成本,Source:
08年测试行业超过30个项目试点,Source:
经济学家2003&DeMarco研究报告,“团队”在“敏捷宣言”中的体现,研究表明面对面的沟通最有效业界调查:
一个50人开发团队,每人平均30%时间用于编码,70%的时间用于与其他成员交流。
研究表明1981年来自不同公司的优秀程序员生产率之比是7:
1,而2007年最新的研究数据,则是40:
1。
人是软件开发的决定因素,Page14,理念:
不断调整以适应(Adapting)变化,麦当劳是简单可预测生产过程,人月神话:
软件开发是人类最复杂工作之一,软件具有四个属性:
复杂性、一致性、可变性和不可见性。
软件开发是不可重复、探索性的、演进的,适应性过程。
随软件规模增长,需求变化呈非线性增长,软件开发是复杂不可预测的经验控制过程,“适应变化”在“敏捷宣言”中的体现,不断的根据经验调整,最终交付达到业务目标的产品,软件开发规律再审视,Page15,优秀实践:
业界敏捷优秀实践概览,结对编程,测试驱动开发,客户参与验收,计划游戏,代码集体所有,每日站立会议,产品backlog(带优先级的需求清单),燃烧图,迭代计划会议,回顾会议,ScrumMaster,ProductOwner,Anatomy(系统解剖),OneTrack,Systemakut(缺陷管理和决策),重构,完整团队,稳定开发节奏,Lagomising(需求决策),隐喻,电信业偏重大规模产品实践、Scrum偏重项目管理,XP偏重编程实践,电信业,Scrum,XP,持续集成,迭代交付,Page16,开发团队一,具体应用:
因地制宜选择适合的敏捷实践,团队在透彻理解敏捷理念的基础上,可以灵活选择最适合自己的实践,避免教条化,站立会议,排序的工作列表,持续集成,持续集成,重构,持续集成,结对编程,迭代开发,+,+,迭代开发,+,+,+,+,+,+,+,开发团队三,敏捷理念,开发团队二,敏捷理念,敏捷理念,Page17,敏捷转型是系统性工程,敏捷转型7个方面优先级,Source:
CutterAgileTransformation(JimHighsmith大师),敏捷转型是系统工程,覆盖7个方面:
实践、绩效考核、组织、过程、文化、管控、技术和业务对齐敏捷在敏捷转型不同阶段,敏捷转型框架的7个方面引入的优先级不一样,初期以实践为主,Numbersrepresenttypicalrelativeimportanceateachstage.,目录,敏捷概述正确理解敏捷统一认识敏捷敏捷理念解读敏捷实践解读我司敏捷开发实施策略我司敏捷案例,Page19,深入理解敏捷理念,深入理解“适应变化”认请“客户是逐步发现真正需求”小批量是快速交付的关键通过迭代计划不断调整以适应需求变化应持续保持良好的软件架构利用多层次反馈不断调整以逼近目标,深入理解“激发团队”认清团队的基本事实敏捷方式下管理者的转变敏捷方式下团队成员的转变,深入理解“聚焦客户价值”标识和消除软件开发中的浪费交付刚刚好的系统随时构建质量,不容忍缺陷及时消除技术债务,持续保持快速响应,Page20,聚焦客户价值,标识和消除软件开发中的浪费,Source:
精益软件开发,Page21,当质量、进度、资源冲突时,能改变的只有项目范围,即选择“交付刚刚好的系统”产品交付前,客户往往期望多而全的功能,产品交付后,客户把稳定的质量放在首位,尤其在电信领域,客户对产品质量要求是Alwayswork,不是Sometimes。
与其为了满足多而全的功能导致交付延迟,质量不稳定,不如按时交付刚刚好的系统,保证其高质量运行。
交付刚刚好的系统,基于对客户需求的深入理解,并花时间了解细节,简化(simplify)需求(降低复杂性)而不是简单地拒绝需求(delete)。
做到“交付刚刚好的系统”,同时需要管理者有足够的勇气和果断决策,聚焦客户价值,交付刚刚好的系统,在项目明显超负荷时,管理者简单地期望靠团队workharder来解决,最终导致:
质量下降项目延期客户不满意团队疲劳埋下长期隐患,Page22,缺陷遗留带来高额成本:
对单独质量保证活动(如后端测试)的依赖,容易形成缺陷可以遗留到下个阶段的心理,导致缺陷发现成本升高(系统测试阶段缺陷定位和解决成本是开发阶段的10倍)例1:
E公司开发阶段和测试阶段发现缺陷的比例为7:
3,而我司大量缺陷集中在后端发现,带来高额成本。
例2:
我司顾问指出:
华为测试和开发“相隔1000英里”。
聚焦客户价值,随时构建质量,不容忍缺陷,从项目一开始就随时构建质量:
形成零缺陷文化,不要容忍缺陷:
发现缺陷应立即停下来解决,以保证在坚实的质量基础上前行。
开发和测试紧密协作:
测试人员参与到设计和开发过程中,共同预防缺陷的产生。
例如:
持续集成暴露的问题需立即解决,Page23,聚焦客户价值,及时消除技术债务,持续保持快速响应,为什么会有技术债务:
为满足短期商业目标,不影响其外部表现的情况下,会在技术方面进行一定的让步,这种让步虽对当前版本的质量影响甚微,但会严重影响后续版本响应客户需求的能力,从而形成技术债务。
对待技术债务的态度:
技术债务是有成本的,如不及时偿还,会随时间积累利息变高,导致开发效率大幅下降,从而降低客户响应能力。
因此对待技术债务的态度是加以管理并及时偿还(如及时重构)。
常见技术债务:
日益腐烂的架构、圈复杂度高的代码、低的测试自动化率、不及时清除的静态检查告警等。
Page24,激发团队,认清团队的基本事实,Source:
JeffCSMTrainingmaterial,信任是高绩效团队的基石,信任,承诺,冲突,创新,关于团队激励:
当团队自管理时效率最高人们对自己做出的承诺比别人要求的承诺更认真人们会尽力做到最好在强大的压力下努力工作,人们会自然而然地降低对质量的要求关于团队绩效:
当团队成员不被打扰时,工作效率最高当团队解决自我问题时,提升最快广泛的、面对面的交流是团队工作最高效的方式关于团队构建:
团队生产率大于相同数目的个体生产率之和当不同技能领域的人员组成团队并聚焦于工作时,产品更健壮,Page25,激发团队,敏捷方式下管理者的转变,管理者努力“控制”团队:
制定详细的工作计划,并做出详细的工作安排指令性工作方式监控过程基于复杂规则的管理,管理者努力“激发”团队:
通过目标来牵引团队自主工作帮助团队提供资源,排除障碍营造团队自我管理的工作氛围作为教练辅导团队进步基于简单原则的管理,原则简单但必须被遵守,敏捷方式下对管理者最大的挑战是学会放松”控制”(loosecontrol),传统方式,敏捷方式,Page26,激发团队,敏捷方式下团队成员的转变,团队成员是“听从安排的独立贡献者”:
被动等待主管下指令安排工作独立工作为主,协作少以文档和邮件为主要沟通方式只关注个体任务“做完”,不关注团队目标能力相对单一,学习动力不足,敏捷方式的管理者,从被动到主动的心态转变是团队成员适应敏捷开发的关键,团队成员是“全方位的积极参与者”:
共同参与计划制定和任务安排团队协作贯穿工作始终面对面交流是主要沟通方式关注团队目标,共担责任能力要求更广,主动学习适应岗位要求,传统方式,敏捷方式,Page27,残酷现实客户是逐步发现他真正要的东西开发人员逐步发现如何开发产品满足客户需求在这个过程中随时可能发生变化,美好愿望客户知道自己要的是什么开发人员知道如何开发来满足客户需求在开发过程中需求不会发生变化,期望客户一开始就想清楚他们真正要的东西是不现实的。
我们应当通过不断的向客户交付可用的产品,启发客户逐步的发现真正的需求。
我们认识到,适应变化,认清“客户是逐步发现真正需求”,Page28,适应变化,小批量是快速交付的关键,我们首先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。
经常性的交付可以工作的软件,交付的间隔可以从几个星期到几个月,交付的时间间隔越短越好。
摘自敏捷软件的十二个原则,在需求响应周期相同的情况下,批量(一次开发的需求量)越小,资源利用率更高。
在资源利用率相同的情况下,批量越小,交付周期更短。
减小批量不仅带来缩短交付周期,而且还带来提高质量、促进创新、降低管理成本、更高的效率等其他好处,大幅提升商业价值。
减少批量的好处,Source:
CraigLarman,减小批量,1.减少排队,3.缩短交付周期,2.加快反馈,4.增强质量,5.改善创新,6.降低管理成本,7.更高的效率,$,排队理论:
小批量与缩短交付周期、人员有效产出的关系,Page29,适应变化,通过迭代计划不断调整以适应需求变化,正确做计划方法在每一轮迭代开始,只详细确定本次迭代的工作内容,并严格执行,对后续较远的迭代内容只做粗略的计划,避免浪费。
项目范围常发生变化需求出现了增加、删除、优先级调整(如图E、O、P、J)工作量在需求细化后发现离原始工作量估计有偏差,引发计划调整;(如图中I)客户使用了产品后,发现有些需求已不再需要(如图中D、G),变化无法一次性预测,一开始制作大而全的计划易造成浪费应根据迭代积累的经验和需求变化的情况对计划不断调整和细化,Page30,适应变化,应持续保持良好的软件架构,良好软件架构是适应变化的基石电信软件的特点是庞大、复杂、生命周期长,因此需要良好架构来保证长期的演进,避免大规模的返工;优秀的架构通过可扩展性来很好地适应需求的变化,对敏捷起到支持作用,相反拙劣的架构会阻碍敏捷;良好架构使系统部件处于松耦合状态,有助于制定出合适的增量开发/集成计划,使分层分级的持续集成更加容易实施。
软件架构需要尽早验证和持续维护新产品开发通过早期迭代来实现和验证架构,有利于架构的尽早稳定;增量开发需识别影响架构的需求,优先实现,规避架构风险;通过重构及时维护和优化架构(偿还技术债务),使架构保持生命力。
Page31,适应变化,利用多层次反馈不断调整以逼近目标,结对编程,单元测试,持续集成,站立会议/回顾会议,客户验收,对代码质量的反馈,对单元功能的反馈,对团队运作的反馈,对系统功能的反馈,对客户需求的反馈,利用多层次反馈手段,在变化的环境中让团队准确地了解与目标的差距,不断调整自身行为,并逐步逼近靶心,多层次反馈手段,目录,敏捷概述正确理解敏捷统一认识敏捷敏捷理念解读敏捷实践解读我司敏捷开发实施策略我司敏捷案例,Page33,敏捷实践概览,技术实践,迭代计划会议每日站立会议可视化管理迭代验收迭代回顾会议,管理实践,产品Backlog(需求清单)迭代Backlog完成标准,敏捷团队角色ProductOwner(PO)ScrumMasterTeam完整团队实践,团队,用户故事结对编程TDD(测试驱动开发)持续集成Anatomy系统解剖,工作件,敏捷软件开发是以短周期迭代为核心,包含团队、工作件、管理和技术优秀实践的集合,迭代开发,Page34,敏捷软件开发典型场景,PO和开发团队对产品业务目标形成共识PO建立和维护产品需求列表(需求会不断新增和改变),并进行优先级排序PO每轮迭代前,Review需求列表,并筛选高优先级需求进入本轮迭代开发开发团队细化本轮迭代需求,并按照需求的优先级,依次在本轮迭代完成开发团队每日站立会议、特性开发、持续集成,使开发进度真正透明PO对每轮迭代(24周)交付的可工作软件进行现场验收和反馈回到第3步,开始下一轮迭代,Page35,什么是迭代式开发迭代开发将整个软件生命周期分成多个小的迭代(一般2-4周),每一次迭代都由需求分析、设计、实现和测试在内的多个活动组成,每一次迭代都可以生成一个稳定和被验证过的软件版本。
迭代式开发的好处通过将高技术风险的需求在早期迭代里实现,有助于尽早暴露问题和及时消除风险通过提供功能渐增的产品,持续从客户获得反馈,根据反馈及时调整,使最终产品更加符合客户的需要通过小批量减少排队,提供更灵活、快速的交付能力平滑人力资源的使用,避免出现瓶颈,迭代式开发的关键要点每一次迭代都建立在稳定的质量基础上,并做为下一轮迭代的基线,整个系统的功能随着迭代稳定地增长和不断完善。
每次迭代要邀请用户代表(外部或内部)验收,提供需求是否满足的反馈迭代推荐采用固定的周期(2-4周),迭代内工作不能完成,应当缩减交付范围而不是延长周期,敏捷软件开发核心迭代开发,迭代开发是有节奏地小步快跑,但建立在坚实的质量基础上,Page36,敏捷团队包括3个核心角色:
PO(ProductOwner)、ScrumMaster(Scrum教练)和Team(开发产品),敏捷团队的三个核心角色,Marketing,用户,用服,管理,.etc,利益相关人,SM,SM,SM,SM:
ScrumMasterPO:
ProductOwner,Page37,敏捷团队的角色职责,Page38,什么是完整团队敏捷开发中,以Story为单位的持续交付要求系统组、开发和测试等跨功能团队进行密切协同,相互独立的功能团队难以应对。
完整团队是跨功能领域(需求分析师、设计师、开发人员、测试人员、资料人员等)的人员组成一个团队,坐在一起工作,团队成员遵循同一份计划,服从于同一个项目经理。
完整团队的好处有助于团队成员形成共同目标和全局意识,促进各功能领域的拉通和融合;通过面对面沟通提升沟通效率。
实现团队成员的高度协同,支撑高密度地、持续地、短周期的交付。
完整团队的关键要点成员来自多功能领域:
团队拥有完成目标所需的各职能成员;坐在一起办公:
团队成员无障碍地沟通;团队保持相对稳定:
临时组建的团队生产效率较低,团队稳定非常关键。
完整团队聚焦客户需求交付,提高协作效率,敏捷团队实践:
完整团队,Page39,产品Backlog关键要点清楚表述列表中每个需求任务对用户带来的价值,做为优先级排序的重要参考;动态的需求管理而非“冻结”方式,PO持续地管理和及时刷新需求清单,在每轮迭代前,都要重新筛选出高优先级需求进入本轮迭代;迭代的需求分析过程,而非一次性分析清楚所有需求(只对近期迭代要做的需求进行详细分析,其它需求停留在粗粒度)。
敏捷工作件:
产品Backlog,什么是产品Backlog经过优先级排序的动态刷新的产品需求清单,用来制定发布计划和迭代计划。
产品Backlog的好处通过需求的动态管理应对变化,避免浪费;易于优先交付对用户价值高的需求。
产品Backlog是需求动态管理的载体,Page40,什么是迭代Backlog迭代Backlog是团队在一轮迭代中的“任务”(Task)清单,是团队的详细迭代开发计划;当团队接收从产品Backlog挑选出要在本轮迭代实现的需求时,召开团队迭代计划会议,将需求转化为具体的“任务”;每项任务信息包括当前剩余工作量和责任人。
敏捷工作件:
迭代Backlog,迭代Backlog的好处将需求分解成更细小的任务,利于对迭代内进度进行精确控制;剩余工作量可用来实时跟踪团队当前进展。
迭代Backlog关键要点“任务”由团队成员自己分解和定义,而不是上级指派,支撑需求完成的所有工作都可以列为任务;任务要落实到具体的责任人;任务粒度要小,工作量大于两天的任务要进一步分解;用小时做为任务剩余工作量的估计单位,并每日重估计和刷新。
迭代Backlog提供精细的迭代开发计划,任务,责任人,状态,剩余工时,日期,Page41,敏捷工作件:
完成标准(DefinitionofDone),什么是完成标准基于“随时可向用户发布”的目标制定衡量团队工作是否已完成的标准,由团队和PO形成共识;,完成标准的好处共同协商的完成标准是团队的自我承诺,团队会更认真;用于准确评估团队工作进展;清晰和明确的完成标准保证了每次迭代是高质量的。
完成标准的关键要点团队自协商:
团队根据项目实际情况来定义完成标准,并严格遵守;有层次:
一般分为三个层次:
Story级别,迭代级和发布级,每个级别都有各自的完成标准。
Story完成标准样例,迭代完成标准样例,发布完成标准样例,代码合入主干,代码符合规范,代码100%检视,通过验收测试,通过迭代验收,系统测试用例100%通过,通过性能测试,所有Story完成,通过回归测试,所有缺陷解决,更新配套资料,完成标准的样例,代码100%通过单元测试,持续集成无错误,完成标准确保团队每一步前进都奠定在坚实的质量基础之上,Page42,敏捷管理实践:
迭代计划会议,什么是迭代计划会议每轮迭代启动前,团队共同讨论本轮迭代详细开发计划的过程,输入是产品Backlog,输出是团队迭代Backlog;多团队迭代计划会议要分层召开版本迭代计划会议:
将产品Backlog(需求)分配给团队;团队迭代计划会议:
将选取的产品Backlog需求转换成迭代Backlog(任务),分配给团队成员;迭代计划会议内容:
澄清需求、对“完成标准”达成一致工作量估计、根据团队能力确定本轮迭代交付内容;细化、分配迭代任务和初始工作计划。
迭代计划会议的好处通过充分讨论,使团队成员对任务和完成标准理解一致;团队共同参与,促进团队成员更认真对待自己的承偌。
迭代计划会议的关键要点充分参与:
ScrumMaster确保PO和Team充分参与讨论,达成理解一致;相互承诺:
Team承诺完成迭代Backlog中的需求并达到”完成标准“,PO承诺在短迭代周期不增加需求(2-4周);确定内部任务:
Team和PO协商把一些内部任务放入迭代中(例如重构、持续集成环境搭建等),由PO考虑并与其他外部需求一起排序。
迭代计划会议由团队共同确定迭代交付内容和完成标准,Page43,敏捷管理实践:
每日站立会议,什么是每日站立会议每日工作前,团队成员的例行沟通机制,由ScrumMaster组织,Team成员全体站立参加聚焦在下面的三个主题:
我昨天为本项目做了什么?
我计划今天为本项目做什么?
我需要什么帮助以更高效的工作?
每日站立会议的关键要点准时开始:
按计划会议制定的时间地点开会,形成团队成员的自然习惯;高效会议:
会议限时15分钟,每个人都保持站立,依次发言,不讨论与会议三个主题无关的事情(如技术解决方案等);问题跟踪:
ScrumMaster应该记录下所有的问题并跟踪解决;,每日站立会议的好处增加团队凝聚力,产生积极的工作氛围及时暴露风险和问题;促进团队内成员的沟通和协调。
每日站立会议促进团队沟通协调,及时暴露问题,Page44,敏捷管理实践:
可视化管理,可视化管理的好处简单,一目了然,降低管理成本;实时状态显示,及时暴露问题;信息同源使团队理解一致,提升团队凝聚力;激励先进,鞭策后进,增强团队进取心。
什么是可视化管理将项目状态(进度、质量等)通过物理实体(如白板,大屏幕)实时展示,让团队所有成员直观地获取当前项目进展信息。
可视化管理的关键要点物理实体:
可视化一定要做到物理上的实体化,大家在公开场所都容易看到,触摸到,(存在电脑中的文件不是可视化的);内容精简,易懂:
信息展示一目了然,切实对团队有帮助,切忌贪多求全,难以分辨;实时刷新:
延迟的信息拖延问题暴露,降低运作效率。
可视化管理及时暴露问题,激励团队,Story墙(展示Story进度),缺陷走势图(展示缺陷解决进展),Anatomy视图(展示系统集成进展),Page45,敏捷管理实践:
迭代验收,什么是迭代验收每次迭代开发结束时举行,通过演示可工作的软件检查需求是否满足客户要求;由ScrumMaster组织,PO和用户代表(外部或内部利益相关人)负责验收、Team负责演示可工作软件。
迭代验收的好处通过演示可工作的软件来确认
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 敏捷 开发 介绍