Scrum敏捷软件开发过程.ppt
《Scrum敏捷软件开发过程.ppt》由会员分享,可在线阅读,更多相关《Scrum敏捷软件开发过程.ppt(85页珍藏版)》请在得力文库 - 分享文档赚钱的网站上搜索。
1、Copyright 2008 TietoEnator CorporationScrum敏捷软件开发过程2008-12-03Jinghua LiQuality ManagerTietoEnator CorporationT&M MDR MIDjinghua.Copyright 2008 TietoEnator Corporation目录什么是敏捷软件开发?敏捷方法的项目计划敏捷项目管理和传统项目管理为什么使用敏捷?Scrum概述 Scrum的角色 Scrum实践和工作产品 敏捷开发中的估计方法测试驱动开发Scrum应用支持工具和模版一些常见的误解2Copyright 2008 TietoEnat
2、or Corporation敏捷开发方法Copyright 2008 TietoEnator Corporation什么是敏捷软件开发?敏捷软件开发是软件项目的一个概念框架.有许多建立在敏捷概念上的方法,如 Scrum 和 Extreme Programming(XP).与僵化的、重量级的、官僚式的方法形成对照,比如瀑布模型(指纯粹形式的)最大限度地降低短期固定时间的迭代式软件的开发风险.4Copyright 2008 TietoEnator Corporation敏捷宣言(2001年)人和交互胜过过程和工具.Individuals and interactions over processe
3、s and tools可以工作的软件胜过完备的文档.Working software over comprehensive documents客户协作胜过合同谈判.Customer collaboration over contract negotiation随时应对变化胜过遵循计划.Responding to change over following a plan5Copyright 2008 TietoEnator Corporation敏捷过程的限制敏捷软件开发过程包含过程、原则、工具,和最重要的-人因此 诚信是基础没有过程能够对诚信进行有效地约束 诚信与否是有效实施敏捷过程的最大限制
4、6Copyright 2008 TietoEnator Corporation使用敏捷方法的项目计划Product Backlog(Features)521385832Initial SizeEstimatesAs Story PointsLong term planning(best guess at the moment):32 SP of functionality,Team Velocity 8 SP/Sprint 4 SprintsTarget Sprint for each PBL item set,feasible implementationOrder.Sprint Backl
5、og(Tasks)85831“Sprintful”of top-priority PBL to thenext SprintMore accurate estimatesas man hours Short term planning(commitment by Team):May be constantlyupdatedScope frozen new PBL items to next Sprint7Copyright 2008 TietoEnator Corporation敏捷项目管理和传统项目管理传统项目管理:事先对整个项目进行估计、计划、分析反对变更;变更需要重新估计、重新规划严密的
6、合同来减少风险,如果改变需求要走 CR 流程.项目作为一个“黑盒子”,对客户与供应商的可视性差.产品化和测试阶段是分离的.文档和计划驱动的方法.软件交付时间晚,意识到风险的时间晚.敏捷项目管理:对整个项目做一个粗略的估计,每一次迭代都有详细的计划.鼓励变化,客户价值驱动开发.信任和赋予权力;合约使变更变得简单,增加价值.客户和开发人员之间是紧密的连续的合作关系每次迭代都产生可交付的软件专注于交付软件.第一次迭代就可交付能工作的版本,风险发现的早.8Copyright 2008 TietoEnator Corporation为什么采用敏捷?预期的收益 采用敏捷方法得当的话,可以:更加透明;随时跟
7、踪项目的状态和进展情况,及早发现问题和风险.快速交付,每次迭代都能交付可运行的软件.最高风险和最高优先级的需求,最优先进行开发.改善应对变更能力,减少大量的重计划.改善项目沟通.更好的客户参与,避免错误的假设.总之:提高了生产率;减少“浪费”(不需要的文档,重复工作等),项目的每次迭代都有明确的目标.提高客户满意度;短期内产生成效,按预期交付软件,每次迭代结束产生可以运行的软件.改善员工的满意度;团队精神,减少官僚,能够规划和管理自己的工作,减少“恐慌”,稳定的工作量(可持续的步伐).9Copyright 2008 TietoEnator Corporation敏捷方法何时有效?公司和客户一致
8、认为应当使用敏捷方法,双方都能理解敏捷方法.敏捷方法对需求不完整以及经常变换的项目比较有效.项目可以划分成固定时间间隔的迭代,并且可以冻结正在进行的迭代的范围公司和客户都有能力担当角色尤其是Product Owner 和 Scrum Master.项目的人员结构能够分成6到10人的团队,最好每个工作地点一个小组.团队成员能够以自组织的方式工作.项目的合同允许变更.固定价格的项目可以使用敏捷,但应当尽量避免。最好在按时间和材料付费或者按月付费的项目中进行使用、变更项目的范围不需要高级管理层的批准.10Copyright 2008 TietoEnator Corporation警告!敏捷开发过程是
9、一个艰苦的过程Agile Work is Hard Work这种状态也许会存在很长时间!不舒服疑惑有挫折感11Copyright 2008 TietoEnator CorporationScrum 概述Copyright 2008 TietoEnator CorporationScrum 概述(1/3)Scrum是管理软件项目的一个轻量级的敏捷方法,名字来源于橄榄球运动中的scrum 过程简单,但高度的纪律性依赖迭代和增量的敏捷方法.Scrum 是一种工作管理的方法,不仅仅限于软件开发,可以用来管理其它活动.Scrum 不包含技术方法或实践.13Copyright 2008 TietoEnat
10、or CorporationScrum 概述(2/3)项目的阶段项目分成增量的迭代过程,在Scrum中称为迭代任务清单,通常持续2-4周的时间.Sprint 的时间是限定好的;不能从外部改变正在进行中的sprint持续时间和范围.每个sprint都可以产生可交付的迭代,即测试过并具备文档的的功能点原则上,当产品开发到一定程度时,如实现了足够的客户价值,项目可以在任何一个sprint后结束,.如同任何项目,敏捷的项目有三个主要阶段:产品定义(规划);运行Sprints 所需要的准备、规划、技术分析.执行Sprints(执行):在增量时间段内实现 需求(产品需求清单).结束:准备最终发布,结束项目
11、14Copyright 2008 TietoEnator CorporationScrum 概述(3/3)Sprint Planning Meeting:Next Sprint GoalSprint BacklogUpdated Product BacklogDaily Scrum meetings:What did you do yesterdayWhat will you do today?What obstacles are in your way?Source:Daily ScrumSprintRetrospectiveShippableProduct Increment15Copyr
12、ight 2008 TietoEnator CorporationScrum角色、实践和工作产品Copyright 2008 TietoEnator CorporationScrum中的三种角色Product Owner-产品所有者个人:代表所有的干系人Scrum Master:个人:负责指导过程的执行Scrum Team Scrum团队:承诺完成工作,向干系人交付产品价值17Copyright 2008 TietoEnator CorporationScrum 角色 Scrum 团队Scrum 团队是Scrum的中心角色,产品交付要依靠团队.Scrum 团队自我组织、自我管理Scrum 团队
13、是职能交叉的,包含产品交付的所有角色:开发人员、测试人员、build managers,文档编写,界面设计人员.Scrum 团队中的角色是不分等级的;不应当出现“我是开发人员我不作测试”.团队按照最有利于项目的原则来分担责任(如组件的所有权等).敏捷是建立在信任和授权的基础上,因此团队是自发组织的,组员选择自己的任务,而不是别人强制加以分配的.另一方面,Scrum团队有交付的责任,他们需要能够自我激励和对工作目标进行承诺.团队最佳规模:6-10 人18Copyright 2008 TietoEnator CorporationScrum 角色 Scrum 团队主要职责参与迭代任务清单的创建执行
14、为干系人创造价值的工作根据团队的承诺完成所需的各项任务将工作中的各项障碍迅速与Scrum Master 进行沟通全面参与所有的各项会议更新任务状态自发选择任务标识任务的完成标识发现的新的任务与其它团队共同进行工作19Copyright 2008 TietoEnator CorporationScrum 角色 Scrum MasterScrum Master不是一个管理者,而是一个教练和推动者-Scrum团队是一种自发的组织,是自我管理的.Scrum Master的角色通常由项目组的成员担当,组长或者项目经理。Scrum Master 应当是项目中的成员.主要职责:评价过程的健康状况加强过程消除
15、障碍促进过程改进支持团队开发Scrum Master 的主要工作是做决策、消除障碍,保证团队能顺利交付产品20Copyright 2008 TietoEnator CorporationScrum 角色 Scrum MasterScrum Master 还有如下责任与其它角色配合.训练团队,提高生产率.培训产品所有者和干系人,确保Scrum流程的执行确保一切工作按照既定的规范来运行.规划并进行必要的改进.推动会议的召开.维护障碍列表维护Scrum过程改进列表优秀的 Scrum Master 应当是专注的,、有决心的、有领导才能.21Copyright 2008 TietoEnator Corp
16、orationScrum 角色 Product Owner产品所有者代表投资方的利益,确保交付的产品与期望的一致(提供更好的投资回报).Product Owner决定产品具有哪些功能.Product Owners的主要责任是创建和维护产品需求清单,即管理项目的范围.Product Owner不断的把产品需求清单按优先级进行排序,使得最重要的功能能优先实现.对于团队来说,只有一个需求集。所有的需求申请都归口到Product Owner管理商业价值(投资回报)Product Owner 还有如下责任:计划项目的发布,什么时间、向什么人等.对每次Sprint的结果进行评审和批准22Copyright
17、 2008 TietoEnator CorporationScrum 角色 Product Owner参与Scrum会议迭代计划会议团队进展跟踪会议迭代评审和回顾会议能够随时回答团队工作中产生的各项和产品/业务相关的问题Product Owner 的角色一般由客户担当,作为服务提供商的公司无法设定优先级.23Copyright 2008 TietoEnator CorporationScrum 角色 客户与管理层客户和管理的角色是可选的,需要时才设立客户:是产品的最终用户 通过 Product Owner来设定对产品的期望把当前的业务传达给项目.管理层:公司高级管理层,代表公司在项目中的利益.
18、通过Product Owner来传达公司的利益和优先级(priorities)24Copyright 2008 TietoEnator Corporation产品需求清单 Product Backlog(1/4)概论基本上,产品需求清单是为了实现产品的功能所需要的工作的列表,包括:功能方面的需求;功能点.非功能方面的需求,如性能改进.要修改的Bug;上一版本的已知错误.新技术,如支持新的操作系统或者平台.问题;日后的不确定项,如新的功能.产品需求清单是不断完善的.Product Owner 在项目进行过程中可以随时更新:增加、删除、修改功能,变更优先级等.下一次迭代中要包含较高优先级的需求.产
19、品需求清单也可称为User Stories(用例),因为它们能够给产品的用户带来价值.在一次迭代中要能够实现产品需求清单,如果不能全部实现要进行分解.25Copyright 2008 TietoEnator Corporation产品需求清单(2/4)构成Product Owner负责创建最初的产品需求清单,一开始是不完整的.最初的清单应当包含足够的需求.清单应当包含多少需求,取决于定价模型(black-box,更多的计划时间).产品需求清单来源于:客户;标书,需求规格说明等.Scrum团队的想法;增强型新功能等.现有产品的迭代增量;已知错误,技术问题等.比较好的做法是Product Owne
20、r、Scrum团队、客户/管理以及其它相关方(如相关的Scrum团队)举行一次或者多次研讨会Scrum Master 或者 Product Owner 来促成会议的召开,必须要有人来做.要有效率、要围绕主题、沟通良好、避免不同的假设,承诺并且共通合作,确定优先级.26Copyright 2008 TietoEnator Corporation产品需求清单(3/4)估计Scrum团队对产品需求清单的每一项的规模提供初步的估计,通常采用事件点作为单位Story Points(模糊的).也可采用人天或者人小时作为单位,但容易混淆:a)实际的规模 b)时间的单位.精确的估计值可以在Sprint 规划时
21、给出,当前阶段没有足够的信息.规模的相对值才有意义.这个估计值有助于确定优先级;所需时间所需时间团队速度团队速度产品规模产品规模27Copyright 2008 TietoEnator Corporation产品需求清单(4/4)优先级优先级是产品需求清单中的主要问题.优先级不但反映了客户的价值也反映了风险.产品所有者-PO 设定优先级.清单中的每一项的优先级是唯一的,但可以对它们进行分类优先级可以在项目的任何时候进行更改;如新的重要的功能可以直接给较高的优先级.确定优先级考虑:价值风险依赖关系28Copyright 2008 TietoEnator Corporation产品需求清单 示例P
22、riorityID,like in any requirements documentDescription of the item=User StoryThese will likely endup in the first Sprint29Copyright 2008 TietoEnator Corporation版本发布计划在 Scrum中,不是 每个Sprints 都要发布一个版本.迭代的结果主要是要实现功能的演示,不一定就是发布的版本.版本发布计划决定了每次迭代应当包含产品需求清单的哪些功能.根据现有的信息制定的项目总体的长期的计划.根据产品需求清单和团队的进度来决定(实施的范围/迭
23、代,e.g.in Story Points).Scrum团队参与版本发布计划的制定;架构、风险、依赖性决定了可行的实现顺序.版本发布计划很大程度上依赖于客户的时间表和发布周期,即什么时候客户的产品需要包含我们的模块(交付物).版本发布计划不是一成不变的;每个迭代结束后都可以更改.30Copyright 2008 TietoEnator Corporation完成的定义 当迭代任务清单上的任务都完成时,变为“已完成”状态定义“已完成”的含义是非常重要的,例如:如何记录软件的变化.使用什么样的代码分析工具,发现的问题应当如何处理.进行了什么样的测试,结果是如何记录的,通过标准(如覆盖率、修正的错误
24、)是什么.定义“已完成”意味着定义质量上的需求.“已完成”是0/1变量:完成或者未完成.所有的任务(task)都完成了迭代任务才算完成.在第一个迭代开始之前应该定义好,因为它会影响工作量,而且必须文档化,这样团队和产品所有者的理解是一致的.31Copyright 2008 TietoEnator Corporation完成的定义完成的范围随着团队的成熟程度会逐渐发生变化计划计划分析分析架构架构设计设计开发开发测试测试性能指标性能指标验收验收试运行试运行代码评审代码评审支持文档支持文档集成集成用户文档用户文档32Copyright 2008 TietoEnator Corporation完成的定
25、义-Example完成的定义 遵循编码规范能在模拟器上演示 使用PCLint 进行静态代码分析具有EUnit 测试套件的通过率 和执行率.或者使用结对编程,或者进行代码走查33Copyright 2008 TietoEnator Corporation迭代任务清单规划(1/5)总论迭代任务清单规划 的主要目的是从产品任务清单中挑选高优先级的任务包含在下一次迭代中,即确定迭代的范围.至于能够包含多少产品任务清单中的任务取决于Scum团队能够承诺完成多少.承诺总是来自于内部,不能从外部强加.迭代不应当有空闲时间,因此规划迭代范围时要保证工作量是稳定的(进度是持续的速度).依赖多个因素;团队的能力,
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Scrum 敏捷 软件 开发 过程
限制150内