敏捷开发TOSC分享(2012.3.28)

上传人:e****s 文档编号:243790554 上传时间:2024-09-30 格式:PPT 页数:35 大小:1.72MB
返回 下载 相关 举报
敏捷开发TOSC分享(2012.3.28)_第1页
第1页 / 共35页
敏捷开发TOSC分享(2012.3.28)_第2页
第2页 / 共35页
敏捷开发TOSC分享(2012.3.28)_第3页
第3页 / 共35页
点击查看更多>>
资源描述
单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,分享 敏捷开发,Scrum,目录,什么是敏捷软件开发?,敏捷方法的工程方案,敏捷工程管理和传统工程管理,为什么使用敏捷?,Scrum概述,Scrum的角色,Scrum实践和工作产品,什么是敏捷软件开发,敏捷软件开发是软件工程的一个概念框架.,有许多建立在敏捷概念上的方法,如 Scrum 和 Extreme Programming(XP).,与僵化的、重量级的、官僚式的方法形成对照,比方瀑布模型指纯粹形式的,最大限度地降低短期固定时间的迭代式软件的开发风险.,敏捷宣言2001年,人和交互胜过过程和工具.,Individuals and interactions over processes and tools,可以工作的软件胜过完备的文档.,Working software over comprehensive documents,客户协作胜过合同谈判.,Customer collaboration over contract negotiation,随时应对变化胜过遵循方案.,Responding to change over following a plan,敏捷过程的限制,敏捷软件开发过程包含过程、原那么、工具,和最重要的-人,因此,诚信是根底,没有过程能够对诚信进行有效地约束,诚信与否是有效实施敏捷过程的最大限制,比较,传统工程管理:,事先对整个工程进行估计、方案、分析,反对变更;变更需要重新估计、重新规划,严密的合同来减少风险,如果改变需求要走 CR 流程.,工程作为一个“黑盒子,对客户与供给商的可视性差.,产品化和测试阶段是别离的.,文档和方案驱动的方法.,软件交付时间晚,意识到风险的时间晚.,敏捷工程管理:,对整个工程做一个粗略的估计,每一次迭代都有详细的方案.,鼓励变化,客户价值驱动开发.,信任和赋予权力;合约使变更变得简单,增加价值.,客户和开发人员之间是紧密的连续的合作关系,每次迭代都产生可交付的软件,专注于交付软件.,第一次迭代就可交付能工作的版本,风险发现的早.,为什么采用敏捷,采用敏捷方法得当的话,可以:,更加透明;随时跟踪工程的状态和进展情况,及早发现问题和风险.,快速交付,每次迭代都能交付可运行的软件.,最高风险和最高优先级的需求,最优先进行开发.,改善应对变更能力,减少大量的重方案.,改善工程沟通.,更好的客户参与,防止错误的假设.,预期的收益,总之:,提高了生产率;减少“浪费 不需要的文档,重复工作等,工程的每次迭代都有明确的目标.,提高客户满意度;短期内产生成效,按预期交付软件,每次迭代结束产生可以运行的软件.,改善员工的满意度;团队精神,减少官僚,能够规划和管理自己的工作,减少“恐慌,稳定的工作量可持续的步伐.,敏捷方法何时有效,公司和客户一致认为应当使用敏捷方法,双方都能理解敏捷方法.,敏捷方法对需求不完整以及经常变换的工程比较有效.,工程可以划分成固定时间间隔的迭代,并且可以冻结正在进行的迭代的范围,公司和客户都有能力担当角色尤其是Product Owner 和 Scrum Master.,工程的人员结构能够分成6到10人的团队,最好每个工作地点一个小组.,团队成员能够以自组织的方式工作.,工程的合同允许变更.,固定价格的工程可以使用敏捷,但应当尽量防止。,最好在按时间和材料付费或者按月付费的工程中进行使用、,变更工程的范围不需要高级管理层的批准.,Scrum 概述,Scrum是管理软件工程的一个轻量级的敏捷方法,名字来源于橄榄球运动中的scrum 过程,简单,但高度的纪律性,依赖迭代和增量的敏捷方法.,Scrum 是一种工作管理的方法,不仅仅限于软件开发,可以用来管理其它活动.,Scrum 不包含技术方法或实践.,Scrum 工程的阶段,工程分成增量的迭代过程,在Scrum中称为迭代任务清单,通常持续2-4周的时间.,Sprint 的时间是限定好的;不能从外部改变正在进行中的sprint持续时间和范围.,每个sprint都可以产生可交付的迭代,即测试过并具备文档的的功能点,原那么上,当产品开发到一定程度时,如实现了足够的客户价值,工程可以在任何一个sprint后结束,.,如同任何工程,敏捷的工程有三个主要阶段:,产品定义(规划);运行Sprints 所需要的准备、规划、技术分析.,执行Sprints(执行):在增量时间段内实现 需求(产品需求清单).,结束:准备最终发布,结束工程,Sprint Planning Meeting:,Next Sprint Goal,Sprint Backlog,Updated Product Backlog,Daily Scrum meetings:,What did you do yesterday,What will you do today?,What obstacles are in your way?,Scrum中的三种角色,Product Owner-,产品所有者,个人:代表所有的干系人,Scrum Master:,个人:负责指导过程的执行,Scrum Team Scrum,团队,:,承诺完成工作,向干系人交付产品价值,Scrum 团队,Scrum 团队是Scrum的中心角色,产品交付要依靠团队.,Scrum 团队自我组织、自我管理,Scrum 团队是职能交叉的,包含产品交付的所有角色:开发人员、测试人员、build managers,文档编写,界面设计人员.,Scrum 团队中的角色是不分等级的;不应当出现“我是开发人员我不作测试.,团队按照最有利于工程的原那么来分担责任(如组件的所有权等).,敏捷是建立在信任和授权的根底上,因此团队是自发组织的,组员选择自己的任务,而不是别人强制加以分配的.,另一方面,Scrum团队有交付的责任,他们需要能够自我鼓励和对工作目标进行承诺.,团队最正确规模:6-10 人,主要职责,参与迭代任务清单的创立,执行为干系人创造价值的工作,根据团队的承诺完成所需的各项任务,将工作中的各项障碍迅速与Scrum Master 进行沟通,全面参与所有的各项会议,更新任务状态,自发选择任务,标识任务的完成,标识发现的新的任务,与其它团队共同进行工作,Scrum Master,Scrum Master不是一个管理者,而是一个教练和推动者-Scrum团队是一种自发的组织,是自我管理的.,Scrum Master的角色通常由工程组的成员担当,组长或者工程经理。Scrum Master 应当是工程中的成员.,主要职责:,评价过程的健康状况,加强过程,消除障碍,促进过程改进,支持团队开发,Scrum Master 的主要工作是做决策、消除障碍,保证团队能顺利交付产品,Scrum Master 还有如下责任,与其它角色配合.,训练团队,提高生产率.,培训产品所有者和干系人,确保Scrum流程的执行,确保一切工作按照既定的标准来运行.,规划并进行必要的改进.,推动会议的召开.,维护障碍列表,维护Scrum过程改进列表,优秀的 Scrum Master 应当是专注的,、有决心的、有领导才能.,Product Owner,产品所有者代表投资方的利益,确保交付的产品与期望的一致 提供更好的投资回报).,Product Owner决定产品具有哪些功能.,Product Owners的主要责任是创立和维护产品需求清单,即管理工程的范围.,Product Owner不断的把产品需求清单按优先级进行排序,使得最重要的功能能优先实现.,对于团队来说,只有一个需求集。所有的需求申请都归口到Product Owner,管理商业价值投资回报,Product Owner 还有如下责任:,方案工程的发布,什么时间、向什么人等.,对每次Sprint的结果进行评审和批准,参与Scrum会议,迭代方案会议,团队进展跟踪会议,迭代评审和回忆会议,能够随时答复团队工作中产生的各项和产品/业务相关的问题,Product Owner 的角色一般由客户担当,作为效劳提供商的公司无法设定优先级,产品需求清单 Product Backlog,根本上,产品需求清单是为了实现产品的功能所需要的工作的列表,包括:,功能方面的需求;功能点.,非功能方面的需求,如性能改进.,要修改的Bug;上一版本的错误.,新技术,如支持新的操作系统或者平台.,问题;日后的不确定项,如新的功能.,产品需求清单是不断完善的.,PO在工程进行过程中可以随时更新:增加、删除、修改功能,变更优先级等.,下一次迭代中要包含较高优先级的需求.,产品需求清单也可称为User Stories(用例),因为它们能够给产品的用户带来价值.,在一次迭代中要能够实现产品需求清单,如果不能全部实现要进行分解.,产品需求清单 构成,Product Owner负责创立最初的产品需求清单,一开始是不完整的.,最初的清单应当包含足够的需求.,清单应当包含多少需求,取决于定价模型(black-box,更多的方案时间).,产品需求清单来源于:,客户;标书,需求规格说明等.,Scrum团队的想法;增强型新功能等.,现有产品的迭代增量;错误,技术问题等.,比较好的做法是Product Owner、Scrum团队、客户/管理以及其它相关方如相关的Scrum团队举行一次或者屡次研讨会,Scrum Master 或者 Product Owner 来促成会议的召开,必须要有人来做.,要有效率、要围绕主题、沟通良好、防止不同的假设,,承诺并且共通合作,确定优先级.,产品需求清单 估计,Scrum,团队对产品需求清单的每一项的规模提供初步的估计,通常采用事件点作为单位,Story Points(,模糊的,).,也可采用人天或者人小时作为单位,但容易混淆:,a),实际的规模,b),时间的单位,.,精确的估计值可以在,Sprint,规划时给出,当前阶段没有足够的信息,.,规模的相对值才有意义,.,这个估计值有助于确定优先级,;,所需时间,团队速度,产品规模,产品需求清单 优先级,优先级是产品需求清单中的主要问题.,优先级不但反映了客户的价值也反映了风险.,产品所有者-PO 设定优先级.,清单中的每一项的优先级是唯一的,但可以对它们进行分类,优先级可以在工程的任何时候进行更改;如新的重要的功能可以直接给较高的优先级.,确定优先级考虑:,价值,风险,依赖关系,Priority,ID,like in any,requirements,document,Description of the item=User Story,These will likely end,up in the first Sprint,迭代任务清单规划,迭代任务清单规划 的主要目的是从产品任务清单中挑选高优先级的任务包含在下一次迭代中,即确定迭代的范围.,至于能够包含多少产品任务清单中的任务取决于Scum团队能够承诺完成多少.,迭代的范围在迭代任务清单中描述;团队设定优先级.,产品所有者 PO 定义每个迭代的任务说明mission statement,目标(sprint goal),使迭代更具有针对性,如.“实现一个可扩展的列表控件,其工程是可以选择的,Sprint 迭代方案 输入和输出,Sprint Planning,Meeting,Product Backlog,Team Capabilities,Business Conditions,Technology,Current Product,Sprint Backlog,Product Owner,Scrum Team,Management,Customers,Sprint Goal,一天,一头猪和一只鸡在路上散步,鸡看了一下猪说,“嗨,我们合伙开一家餐馆怎么样?,猪回头看了一下鸡说,“好主意,那你准备给餐馆卖什么呢?,鸡想了想说“餐馆卖火腿和鸡蛋怎么样?,“我不这么认为,猪说,“我全身投入,而你只是参与而已,迭代任务清单规划 逻辑,迭代任
展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 商业管理 > 商业计划


copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!