Scrum敏捷软件开发过程.ppt

Copyright 2008 TietoEnator CorporationScrum敏捷软件开发过程2008-12-03Jinghua LiQuality ManagerTietoEnator CorporationT&M MDR MIDjinghua.Copyright 2008 TietoEnator Corporation目录什么是敏捷软件开发？敏捷方法的项目计划敏捷项目管理和传统项目管理为什么使用敏捷？Scrum概述 Scrum的角色 Scrum实践和工作产品 敏捷开发中的估计方法测试驱动开发Scrum应用支持工具和模版一些常见的误解2Copyright 2008 TietoEnator Corporation敏捷开发方法Copyright 2008 TietoEnator Corporation什么是敏捷软件开发?敏捷软件开发是软件项目的一个概念框架.有许多建立在敏捷概念上的方法，如 Scrum 和 Extreme Programming(XP).与僵化的、重量级的、官僚式的方法形成对照，比如瀑布模型（指纯粹形式的）最大限度地降低短期固定时间的迭代式软件的开发风险.4Copyright 2008 TietoEnator Corporation敏捷宣言（2001年）人和交互胜过过程和工具.Individuals and interactions over processes and tools可以工作的软件胜过完备的文档.Working software over comprehensive documents客户协作胜过合同谈判.Customer collaboration over contract negotiation随时应对变化胜过遵循计划.Responding to change over following a plan5Copyright 2008 TietoEnator Corporation敏捷过程的限制敏捷软件开发过程包含过程、原则、工具，和最重要的-人因此 诚信是基础没有过程能够对诚信进行有效地约束 诚信与否是有效实施敏捷过程的最大限制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 Backlog(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敏捷项目管理和传统项目管理传统项目管理：事先对整个项目进行估计、计划、分析反对变更;变更需要重新估计、重新规划严密的合同来减少风险,如果改变需求要走 CR 流程.项目作为一个“黑盒子”，对客户与供应商的可视性差.产品化和测试阶段是分离的.文档和计划驱动的方法.软件交付时间晚,意识到风险的时间晚.敏捷项目管理:对整个项目做一个粗略的估计,每一次迭代都有详细的计划.鼓励变化,客户价值驱动开发.信任和赋予权力;合约使变更变得简单，增加价值.客户和开发人员之间是紧密的连续的合作关系每次迭代都产生可交付的软件专注于交付软件.第一次迭代就可交付能工作的版本，风险发现的早.8Copyright 2008 TietoEnator Corporation为什么采用敏捷?预期的收益 采用敏捷方法得当的话，可以：更加透明;随时跟踪项目的状态和进展情况，及早发现问题和风险.快速交付,每次迭代都能交付可运行的软件.最高风险和最高优先级的需求，最优先进行开发.改善应对变更能力,减少大量的重计划.改善项目沟通.更好的客户参与,避免错误的假设.总之:提高了生产率;减少“浪费”（不需要的文档，重复工作等），项目的每次迭代都有明确的目标.提高客户满意度;短期内产生成效,按预期交付软件,每次迭代结束产生可以运行的软件.改善员工的满意度;团队精神，减少官僚，能够规划和管理自己的工作，减少“恐慌”，稳定的工作量（可持续的步伐）.9Copyright 2008 TietoEnator Corporation敏捷方法何时有效？公司和客户一致认为应当使用敏捷方法，双方都能理解敏捷方法.敏捷方法对需求不完整以及经常变换的项目比较有效.项目可以划分成固定时间间隔的迭代,并且可以冻结正在进行的迭代的范围公司和客户都有能力担当角色尤其是Product Owner 和 Scrum Master.项目的人员结构能够分成6到10人的团队，最好每个工作地点一个小组.团队成员能够以自组织的方式工作.项目的合同允许变更.固定价格的项目可以使用敏捷，但应当尽量避免。最好在按时间和材料付费或者按月付费的项目中进行使用、变更项目的范围不需要高级管理层的批准.10Copyright 2008 TietoEnator Corporation警告！敏捷开发过程是一个艰苦的过程Agile Work is Hard Work这种状态也许会存在很长时间！不舒服疑惑有挫折感11Copyright 2008 TietoEnator CorporationScrum 概述Copyright 2008 TietoEnator CorporationScrum 概述(1/3)Scrum是管理软件项目的一个轻量级的敏捷方法,名字来源于橄榄球运动中的scrum 过程简单，但高度的纪律性依赖迭代和增量的敏捷方法.Scrum 是一种工作管理的方法，不仅仅限于软件开发，可以用来管理其它活动.Scrum 不包含技术方法或实践.13Copyright 2008 TietoEnator CorporationScrum 概述(2/3)项目的阶段项目分成增量的迭代过程，在Scrum中称为迭代任务清单,通常持续2-4周的时间.Sprint 的时间是限定好的;不能从外部改变正在进行中的sprint持续时间和范围.每个sprint都可以产生可交付的迭代,即测试过并具备文档的的功能点原则上,当产品开发到一定程度时，如实现了足够的客户价值，项目可以在任何一个sprint后结束,.如同任何项目，敏捷的项目有三个主要阶段:产品定义(规划);运行Sprints 所需要的准备、规划、技术分析.执行Sprints(执行):在增量时间段内实现 需求(产品需求清单).结束:准备最终发布，结束项目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 Increment15Copyright 2008 TietoEnator CorporationScrum角色、实践和工作产品Copyright 2008 TietoEnator CorporationScrum中的三种角色Product Owner-产品所有者个人：代表所有的干系人Scrum Master:个人：负责指导过程的执行Scrum Team Scrum团队:承诺完成工作，向干系人交付产品价值17Copyright 2008 TietoEnator CorporationScrum 角色 Scrum 团队Scrum 团队是Scrum的中心角色，产品交付要依靠团队.Scrum 团队自我组织、自我管理Scrum 团队是职能交叉的，包含产品交付的所有角色:开发人员、测试人员、build managers,文档编写,界面设计人员.Scrum 团队中的角色是不分等级的;不应当出现“我是开发人员我不作测试”.团队按照最有利于项目的原则来分担责任(如组件的所有权等).敏捷是建立在信任和授权的基础上，因此团队是自发组织的，组员选择自己的任务，而不是别人强制加以分配的.另一方面，Scrum团队有交付的责任，他们需要能够自我激励和对工作目标进行承诺.团队最佳规模：6-10 人18Copyright 2008 TietoEnator CorporationScrum 角色 Scrum 团队主要职责参与迭代任务清单的创建执行为干系人创造价值的工作根据团队的承诺完成所需的各项任务将工作中的各项障碍迅速与Scrum Master 进行沟通全面参与所有的各项会议更新任务状态自发选择任务标识任务的完成标识发现的新的任务与其它团队共同进行工作19Copyright 2008 TietoEnator CorporationScrum 角色 Scrum MasterScrum Master不是一个管理者，而是一个教练和推动者-Scrum团队是一种自发的组织，是自我管理的.Scrum Master的角色通常由项目组的成员担当，组长或者项目经理。Scrum Master 应当是项目中的成员.主要职责:评价过程的健康状况加强过程消除障碍促进过程改进支持团队开发Scrum Master 的主要工作是做决策、消除障碍，保证团队能顺利交付产品20Copyright 2008 TietoEnator CorporationScrum 角色 Scrum MasterScrum Master 还有如下责任与其它角色配合.训练团队，提高生产率.培训产品所有者和干系人，确保Scrum流程的执行确保一切工作按照既定的规范来运行.规划并进行必要的改进.推动会议的召开.维护障碍列表维护Scrum过程改进列表优秀的 Scrum Master 应当是专注的,、有决心的、有领导才能.21Copyright 2008 TietoEnator CorporationScrum 角色 Product Owner产品所有者代表投资方的利益，确保交付的产品与期望的一致（提供更好的投资回报).Product Owner决定产品具有哪些功能.Product Owners的主要责任是创建和维护产品需求清单,即管理项目的范围.Product Owner不断的把产品需求清单按优先级进行排序，使得最重要的功能能优先实现.对于团队来说，只有一个需求集。所有的需求申请都归口到Product Owner管理商业价值（投资回报）Product Owner 还有如下责任:计划项目的发布，什么时间、向什么人等.对每次Sprint的结果进行评审和批准22Copyright 2008 TietoEnator CorporationScrum 角色 Product Owner参与Scrum会议迭代计划会议团队进展跟踪会议迭代评审和回顾会议能够随时回答团队工作中产生的各项和产品/业务相关的问题Product Owner 的角色一般由客户担当，作为服务提供商的公司无法设定优先级.23Copyright 2008 TietoEnator CorporationScrum 角色 客户与管理层客户和管理的角色是可选的，需要时才设立客户:是产品的最终用户 通过 Product Owner来设定对产品的期望把当前的业务传达给项目.管理层:公司高级管理层,代表公司在项目中的利益.通过Product Owner来传达公司的利益和优先级（priorities）24Copyright 2008 TietoEnator Corporation产品需求清单 Product Backlog(1/4)概论基本上，产品需求清单是为了实现产品的功能所需要的工作的列表，包括:功能方面的需求;功能点.非功能方面的需求,如性能改进.要修改的Bug;上一版本的已知错误.新技术,如支持新的操作系统或者平台.问题;日后的不确定项,如新的功能.产品需求清单是不断完善的.Product Owner 在项目进行过程中可以随时更新：增加、删除、修改功能，变更优先级等.下一次迭代中要包含较高优先级的需求.产品需求清单也可称为User Stories(用例)，因为它们能够给产品的用户带来价值.在一次迭代中要能够实现产品需求清单，如果不能全部实现要进行分解.25Copyright 2008 TietoEnator Corporation产品需求清单(2/4)构成Product Owner负责创建最初的产品需求清单，一开始是不完整的.最初的清单应当包含足够的需求.清单应当包含多少需求,取决于定价模型(black-box,更多的计划时间).产品需求清单来源于:客户;标书,需求规格说明等.Scrum团队的想法;增强型新功能等.现有产品的迭代增量;已知错误,技术问题等.比较好的做法是Product Owner、Scrum团队、客户/管理以及其它相关方（如相关的Scrum团队）举行一次或者多次研讨会Scrum Master 或者 Product Owner 来促成会议的召开，必须要有人来做.要有效率、要围绕主题、沟通良好、避免不同的假设，承诺并且共通合作，确定优先级.26Copyright 2008 TietoEnator Corporation产品需求清单(3/4)估计Scrum团队对产品需求清单的每一项的规模提供初步的估计，通常采用事件点作为单位Story Points(模糊的).也可采用人天或者人小时作为单位，但容易混淆：a)实际的规模 b)时间的单位.精确的估计值可以在Sprint 规划时给出,当前阶段没有足够的信息.规模的相对值才有意义.这个估计值有助于确定优先级;所需时间所需时间团队速度团队速度产品规模产品规模27Copyright 2008 TietoEnator Corporation产品需求清单(4/4)优先级优先级是产品需求清单中的主要问题.优先级不但反映了客户的价值也反映了风险.产品所有者-PO 设定优先级.清单中的每一项的优先级是唯一的,但可以对它们进行分类优先级可以在项目的任何时候进行更改;如新的重要的功能可以直接给较高的优先级.确定优先级考虑：价值风险依赖关系28Copyright 2008 TietoEnator Corporation产品需求清单 示例PriorityID,like in any requirements documentDescription of the item=User StoryThese will likely endup in the first Sprint29Copyright 2008 TietoEnator Corporation版本发布计划在 Scrum中,不是 每个Sprints 都要发布一个版本.迭代的结果主要是要实现功能的演示,不一定就是发布的版本.版本发布计划决定了每次迭代应当包含产品需求清单的哪些功能.根据现有的信息制定的项目总体的长期的计划.根据产品需求清单和团队的进度来决定(实施的范围/迭代,e.g.in Story Points).Scrum团队参与版本发布计划的制定;架构、风险、依赖性决定了可行的实现顺序.版本发布计划很大程度上依赖于客户的时间表和发布周期，即什么时候客户的产品需要包含我们的模块（交付物）.版本发布计划不是一成不变的;每个迭代结束后都可以更改.30Copyright 2008 TietoEnator Corporation完成的定义 当迭代任务清单上的任务都完成时，变为“已完成”状态定义“已完成”的含义是非常重要的,例如:如何记录软件的变化.使用什么样的代码分析工具，发现的问题应当如何处理.进行了什么样的测试,结果是如何记录的,通过标准（如覆盖率、修正的错误）是什么.定义“已完成”意味着定义质量上的需求.“已完成”是0/1变量：完成或者未完成.所有的任务（task)都完成了迭代任务才算完成.在第一个迭代开始之前应该定义好，因为它会影响工作量,而且必须文档化，这样团队和产品所有者的理解是一致的.31Copyright 2008 TietoEnator Corporation完成的定义完成的范围随着团队的成熟程度会逐渐发生变化计划计划分析分析架构架构设计设计开发开发测试测试性能指标性能指标验收验收试运行试运行代码评审代码评审支持文档支持文档集成集成用户文档用户文档32Copyright 2008 TietoEnator Corporation完成的定义-Example完成的定义 遵循编码规范能在模拟器上演示 使用PCLint 进行静态代码分析具有EUnit 测试套件的通过率 和执行率.或者使用结对编程，或者进行代码走查33Copyright 2008 TietoEnator Corporation迭代任务清单规划(1/5)总论迭代任务清单规划 的主要目的是从产品任务清单中挑选高优先级的任务包含在下一次迭代中，即确定迭代的范围.至于能够包含多少产品任务清单中的任务取决于Scum团队能够承诺完成多少.承诺总是来自于内部，不能从外部强加.迭代不应当有空闲时间,因此规划迭代范围时要保证工作量是稳定的(进度是持续的速度).依赖多个因素;团队的能力,技术的成熟度,当前迭代增量的情况等.迭代的范围在迭代任务清单中描述;团队设定优先级.产品所有者 PO 定义每个迭代的任务说明（mission statement），目标(sprint goal)，使迭代更具有针对性，如.“实现一个可扩展的列表控件，其项目是可以选择的”34Copyright 2008 TietoEnator CorporationSprint 迭代计划(2/5)输入和输出Sprint PlanningMeetingProduct BacklogTeam CapabilitiesBusiness ConditionsTechnologyCurrent ProductSprint BacklogProduct OwnerScrum TeamManagementCustomersSprint Goal35Copyright 2008 TietoEnator Corporation迭代任务清单规划(3/5)逻辑迭代任务清单规划 是“铁三角”法则的另一个例子在Scrum,边界是一个变量，因为:资源(Scrum团队)是确定的.进度表（迭代的时间）是不能变的.质量是无法协商的团队在一个迭代内能完成的任务，可以用团队进度来衡量(Story Points/Sprint).如果可能的话利用同一个团队上个迭代的进度,“yesterdays weather”.30-day sprint 20 work days-1 day for planning,1 for review/retrospective=18 work days5 persons in team 90 theoretical man days7.5-hour working day,average 85%to project work90*7.5*0.85=574 man hours 5%reserved for re-estimation and re-planning 545 man hours 36Copyright 2008 TietoEnator Corporation迭代任务清单规划(4/5)规划会议召开迭代任务清单规划会议的目的是确定迭代的边界.时间是限定的,最长时间是一个工作日(对持续4个星期的迭代,迭代持续的时间越短，用在规划上的时间也应该越少.由 Scrum Master推动会议.由于会议时间有限，Product Owner 和Scrum 团队都应该事前进行准备.前提:产品需求清单是有效的（valid）;最新的,标注了优先级并且表述清楚.规划会议要解决两个问题:下次迭代要做什么.确定迭代的目标，包含产品需求清单上高优先级的功能.给Bug修改留一定的余地怎么样实现下次增量所需要的功能.改进设计以实现产品需求清单上的功能.37Copyright 2008 TietoEnator Corporation迭代任务清单规划(5/5)工作流程产品所有者向团队介绍起草的产品需求清单和迭代目标.产品所有者传达迭代的起止日期.Scrum 团队 从产品需求清单中选取高优先级的功能作为迭代的任务，如果有必要，更新其规模估计.Scrum 团队改进架构和设计以便能够实现提出的产品需求.Scrum团队把 产品需求清单的每一项划分成小的任务，并估算每个任务要花费的小时数.“扑克规划”方法是估算工作量的有效方法.Scrum 团队决定一个迭代中能够实现产品需求清单的多少功能产品所有者和Scrum团队明确了各自要承担的义务.38Copyright 2008 TietoEnator CorporationSprint Backlog 示例Personsworking onthe taskDescription of the taskEffort estimateTask blockedby an impedimentSprint goalMeets the definition of done39Copyright 2008 TietoEnator Corporation执行迭代任务清单执行迭代任务清单意味着 团队在迭代期间自行开发.团队清楚要达到什么的目标以及怎样达到目标.每人每一时间只有一个任务团队是自发组织的；成员自己挑选任务,Scrum Master 提供指导并清除障碍.不能从外部改变迭代的范围或者迭代的周期.为了达到迭代的目标，团队可以增加、删除任务或者改变其优先次序.如果要重新设定迭代的范围时需要产品所有者的配合.迭代周期短，意味着工期紧;应该把重点放在剩余的工作和风险的消除，要区分任务的优先级，重要的事情应当先做.迭代应当达到项目的质量要求(definition of“done”);没有独立的测试阶段.40Copyright 2008 TietoEnator Corporation迭代进度图-Burndown ChartScrum 注重成果，它关心的是要花多少时间达到目标，而不是已经花费的时间;.团队能否在既定的时间达到迭代的目标,可以查看要完成产品需求清单的功能所剩余的工作Remaining work=Estimate to Complete(ETC).描述剩余工作量和时间关系的图表称为Sprint Burndown图,是Scrum中非常重要的控制方法(control measure).给Scrum团队和产品所有者提供直观的信息.术语 burndown 表明Scrum团队在迭代过程中消耗剩余工作的能力;迭代结束时其值为0.每个任务（task）的工作量由Scrum团队来估计.每天都要进行估计，以便进行跟踪.可以使用电子表格或者专门的工具（如 ScrumWorks）41Copyright 2008 TietoEnator Corporation迭代进度图-Burndown ChartIdeal burndown.Actual burndown.Remaining work increasing Tasks underestimated and/or work remainingnot updated.Tasks removed from the Sprint Backlog to meetSprint Goal faster decline.Sum of remaining work h for all tasks in the Sprint Backlog on a particular day.Initial estimate(752 h)In the beginning of theSprint 42Copyright 2008 TietoEnator Corporation迭代进度图-Burndown Chart43Copyright 2008 TietoEnator CorporationScrum每日例会(1/4)小鸡和猪的故事A chicken and a pig are together when the chicken says,Lets start a restaurant!“The pig thinks it over and says,What would we call this restaurant?“The chicken says,Ham n Eggs!“The pig says,No thanks.Id be committed,but youd only be involved!“In a Daily Sprint,only Scrum Master and Scrum Team are committed,and thus allowed to speak.Others are only involved.44Copyright 2008 TietoEnator CorporationScrum每日例会(2/4)概述例会最长15分钟，在整个迭代过程中每天的同一时间召开.团队成员 之间交流信息.了解项目的真实的进展情况交流风险和存在的问题.面对面的会议加强了承诺.Scrum Master 负责整个会议(会议地点,邀请等).其他人可以参与,但只允许Scrum Master 和 Scrum 团队成员讲话(小鸡和猪).例会之前团队要更新工作量估计，使进度表保持最新.45Copyright 2008 TietoEnator CorporationScrum每日例会(3/4)形式为使会议简短而富有成效，要遵循严格的规程每个成员向其他人汇报以下内容:上次会议以后所做的工作?下次会议之前要做的工作?工作中是否有什么障碍?如果出现其它的问题（如设计的问题），应当在会议后处理.纪录会议纪要，例如wiki.要养成良好的会议习惯46Copyright 2008 TietoEnator CorporationScrum每日例会(4/4)47Copyright 2008 TietoEnator Corporation障碍基本上，任何阻止团队正常工作的，都可称之为障碍，例如:无法访问信息系统.所需要的信息不能及时提供或者提供的不正确，如界面规格或者其它软件模块不到位或不正确开发环境或者原型系统出现问题其他的任务分配：培训，售前支持缺乏必要的信息或者相应的知识对于团队提出的各项障碍，Scrum Master要以列表形式进行记录，48Copyright 2008 TietoEnator Corporation谁来清除障碍？每个人自我管理、自我组织的团队Scrum Master产品所有者管理层其他相关的干系人Scrum Master 负责确定障碍已经清除，不一定亲自自己清除49Copyright 2008 TietoEnator Corporation清除障碍某些障碍是浪费部分地完成工作额外的过程额外的功能任务转换等待缺陷清除障碍的过程是团队和组织学习的过程50Copyright 2008 TietoEnator Corporation浪费产生的原因多问几个“为什么”对于每个标识的障碍或者浪费，问一问“为什么”浪费会存在多问几个“为什么”，找到造成浪费的根本原因51Copyright 2008 TietoEnator Corporation迭代中的同步工作每次迭代不是小的瀑布项目而是，每件事情同时都做一点52Copyright 2008 TietoEnator Corporation迭代的非正常终止在Scrum中，结束正在进行的迭代是一种极端的行为，只有在万不得以的情况下才能这么做.有时候确实需要停下来重新规划，而不是一味的蛮干(banging your head against the wall).迭代终止可能由下面的人发起:Scrum团队,如果他们认为达不到目标或者目标不清楚.Scrum Master,如果迭代没有进展,或者无法克服某个困难.客户/管理层,如果目标已经陈旧/过时(目标产品被取消，平台过时)，或者其它的原因(资源问题等).迭代终止以后,启动新迭代的计划.导致迭代终止的原因不应该在新的迭代中再次出现.要考虑到合同方面的问题，如时间表的变更等.53Copyright 2008 TietoEnator Corporation迭代评审 概述迭代评审，在迭代结束后进行，展示迭代的成果(功能运行).确保成果与预期的一致，收集反馈为项目提供一个参考点，根据目前的位置计划下一期的旅程为下次迭代提供输入（改正、修改、新的想法可以由产品所有者添加到产品需求清单.与其它 Scrum 会议一样,Scrum Master 主持迭代评审会议,Scrum 团队负责演示.参加会议的其他人包括:产品所有者Product Owner(必须参加)、客户、管理人员,以及其它感兴趣的人,例如其他Scrum团队(注意保密协议的要求).评审会议的时间是固定的:最长4个小时.评审会议应当是非正式的、创造性的，不用幻灯片等正式的东西.54Copyright 2008 TietoEnator Corporation迭代评审 流程在评审会议召开之前，团队要做好准备:有组织、有效地进行演示，不要超过4个小时.谁来演示，演示什么，怎样演示?计划准备的时间不要超过一个小时.迭代评审流程的一个例子:Scrum Master 介绍本次迭代的总体情况.目标和清单 vs.实际的结果,如果存在差距，原因是什么.Scrum 团队简要介绍所 涉及的技术问题，如架构及其变更.Scrum 团队演示已经实现的功能:演示并进行功能说明在场的人能够亲自尝试使用不同的功能.Scrum Master 推动自由讨论，集思广益.迭代评审应当是互动的;有问题提出,问题解答，并欢迎提出想法和建议.55Copyright 2008 TietoEnator Corporation迭代评审 可能的措施产品所有者根据评审的结果可能采取如下行动:更新产品需求清单，重新设定优先级:包含没有按计划实现的功能(进度比预期的要慢,任务未完成).不在计划中当却已经实现的功能(进度比预期的快).迭代评审中出现的新的想法.与 Scrum Master 一起解决团队的变动问题.要求把演示的功能，或者把上次迭代的功能，作为一个版本发布给客户.决定项目不再持续下去，不再进行迭代;认为产品已完备.要求把产品需求清单授权给另外的团队来一起工作.56Copyright 2008 TietoEnator Corporation迭代回顾会议 Sprint Retrospective回顾的目的是评价本次迭代并酝酿改进，使得下一个迭代进行的更好.类似于项目的最终评审，但经常举行.障碍列表具有很好的参考价值!Scrum Master主持召开,持续半天,Scrum团队参加(产品所有者也可参加).简单流程:Scrum Master 总结本次迭代;迭代任务清单,重要的事情和决策,预期的/实际进度.每个组员陈述迭代中那些方法进行的较好、哪些需要改进,Scrum Master 进行记录.对重要的问题计划相应的措施：团队自己解决,或者提交给公司的管理层.57Copyright 2008 TietoEnator CorporationScrum方法应用Copyright 2008 TietoEnator Corporation敏捷开发中使用扑克Poker方法进行估计(1/3)尽管名字有好笑,但却非常可靠和有效.可以来估算产品需求清单中每项的规模（规模估算:用例点story point）以及迭代任务清单中任务的估计(工作量估算：人时).Scrum Master推动活动的进行,一个以上的专家参与估算,而且最好是项目团队中的人.估算时使用卡片：写有一系列的离散数据，如0,1,2,3,5,8,13,?(无法估计).59Copyright 2008 TietoEnator Corporation敏捷开发中使用扑克Poker方法进行估计(2/3)前提条件:提前准备好要估算的任务、User Stories等;迭代任务清单和产品需求清单都已经起草好.对某个任务最有经验的开发者做一个简短的概述.可以通过简短的讨论澄清任务的具体含义，找出存在的风险以及不确定性.各自对任务进行估计，所有的人将写有各自估计数据的扑克/卡片扣上。(单位事先进行约定：工时、事件点).大家同时把扑克/卡片翻过来.如果扑克/卡片上的数差距比较明显(如一个13，2个5，一个1),就要讨论一下为什么会出现这么大的差距，估计值所基于的假定要进行澄清.如果差距较小(如三个8两个5)，主持人帮助确定最终的估值.对于不确定性，估算数据中可以多包含一些余量.不断的重复该过程直到达成一致.将这些估值记录到相应的文档中(产品需求清单,迭代任务清单).60Copyright 2008 TietoEnator Corporation敏捷开发中使用扑克Poker方法进行估计(3/3)为什么使用离散的数字?比使用任意数字更加容易进行估算.在整个项目中或者迭代中,每个人估计值的错误会相互抵消掉.对每个任务,16 小时是上限,不确定性会随着规模的增加而增加.为什么要有“?”.将较大的任务进行分解，帮助更加精确的估计同时减少不确定性.为什么要“讨论并重复”?弄清不同的假设(利用重用代码或者重新编码)和可能的误解 更为可靠的估计.对于那些偏离平均值的估计，即使由有经验的人给出的，也必须要有充分的理由.61Copyright 2008 TietoEnator Corporation练习在一个小时之内编写一个三只小猪的连环画册使用Scrum 实践自组织团队迭代每日Scrum会议产品需求清单迭代任务清单62Copyright 2008 TietoEnator Corporation练习-进度安排5 分钟:迭代目标团队与产品所有者共同协作，从产品需求列表中选择本次迭代要完成的项目5 分钟:迭代任务清单团队从所选择的产品需求列表中产生任务10 分钟:第一天团队完成任务和产品需求列表中的项目产品所有者负责回答问题5 分钟:“每日”“Scrum会议每个人回答三个问题10 分钟:第二天团队继续完成任务和产品需求列表中的项目产品所有者负责回答问题5 分钟:“每日”“Scrum会议每个人回答三个问题10 分钟:第三天团队完成产品的一个版本产品所有者负责回答问题每组5 分钟:演示团队向产品所有者展示完成的连环画册63Copyright 2008 TietoEnator Corporation练习 给出优先级的产品需求清单展示基本的故事用铅笔画展示的故事每页图画配有说明给出写有标题的封面故事用9页进行说明展示版权信息添加色彩广告教小孩数数1，2，3寓教于乐：坚固的重要性封皮吸引人硬的封皮3D效果的卡通形象展示所有的故事内容产品所有者-Product Owner充分考虑市场情况，对产品进行规划并进行简要地说明规划当前该产品如何占有更多的市场份额规划今后该产品的发展前景Scrum团队根据产品所有者的产品规划进行开发64Copyright 2008 TietoEnator Corporation测试驱动开发 Test Driven Development 什么是测试驱动？一种能够支持Scrum的敏捷实践