Scrum敏捷软件开发过程.pdf

TietoEnatoru o 二 s o d。一。一 e u山。一二 8 0 0。2.?AdooScrum敏捷软件开发过程Jinghua Li Quality Manager Tieto Enato r Co rpo ratio n T&MMDRMID jinghua.liieto enato r.co m目录E 2 on 3Z.M,什么是敏捷软件开发?敏捷方法的项目计划敏捷项目管理和传统项目管理u o二可o d。一。一e u山o 一二 8 0 0。三?为什么使用敏捷？Ssrum概述Ssrum的角色Ssrum实践和工作产品 敏捷开发中的估计方法 测试驱动开发Ssrum应用支持工具和模版 一些常见的误解TietoEnatoro敏捷开发方法E 2 on 07 3Z.M,TietoEnator什么是敏捷软件开发？,敏捷软件开发是软件项目的一个概念框架.有许多建立在敏捷概念上的方法，如Ssrum和Extreme Pro gramming(XP).,与僵化的、重量级的、官僚式的方法形成对照，比如瀑布模型(指纯粹形式的)最大限度地降低短期固定时间的迭代式软件的开发风险.E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator敏捷宣言（2001年）,人和交互胜过过程和工具.Individuals and interactio ns o ver pro cesses and to o ls,可以工作的软件胜过完备的文档.Wo rking so ftware o ver co mprehensive do cuments客户协作胜过合同谈判.Custo mer co llabo ratio n o ver co ntract nego tiatio n,随时应对变化胜过遵循计划.Respo nding to change o ver fo llo wing a planE 2 on OJ 3Z.M,uo t e o d。一。一 e u 山 o 一-1 80001三?TietoEnator敏捷过程的限制,敏捷软件开发过程包含过程、原则、工具，和最重要的-人,因此,诚信是基础没有过程能够对诚信进行有效地约束 诚信与否是有效实施敏捷过程的最大限制E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator使用敏捷方法的项目计划E 2 on OJ 3Z.M,“Sprintful”o f to pprio rity PBL to the next Sprint _(Tasks)Sprint Backlo gMo re accurate estimates as man ho ursu o二可o d。一。一e u山o 一二 8 0 0。三?Initial Size Estimates As Sto ry Po intsSho rt term planning(co mmitment by Team):,Sco pe fro zen 今 new PBL items to next SprintLo ng term planning(best guess at the mo ment):32 8P o f functio nality,Team Velo city 8 SP/Sprint 3 4 Sprints Target Sprint fo r each PBL item set,feasible implementatio n Order.TietoEnator敏捷项目管理和传统项目管理传统项目管理：事先对整个项目进行估计、计划、分析 反对变更；变更需要重新估计、重新规划 严密的合同来减少风险，如果改变需求要走CR流 程.项目作为一个“黑盒子”，对客户与供应商的可 视性差.产品化和测试阶段是分离的.文档和计划驱动的方法.软件交付时间晚，意识到风险的时间晚.E 2 on 3Z.M,敏捷项目管理：对整个项目做一个粗略的估计，每一次迭代都有详 细的计划.鼓励变化，客户价值驱动开发.信任和赋予权力;合约使变更变得简单，增加价值.客户和开发人员之间是紧密的连续的合作关系 每次迭代都产生可交付的软件 专注于交付软件.第一次迭代就可交付能工作的版本，风险发现的 早.u o 二 Eo d。一。一 e u山 o 一二 80001三TietoEnator8u o二可o d。一。一e u山o 一二 8 0 0。三?为什么采用敏捷?项期的收益,采用敏捷方法得当的话，可以：更加透明；随时跟踪项目的状态和进展情况，及早发现问题和风险.快速交付，每次迭代都能交付可运行的软件.最高风险和最高优先级的需求，最优先进行开发.改善应对变更能力，减少大量的重计划.改善项目沟通.更好的客户参与，避免错误的假设.总之：提高了生产率；减少“浪费”（不需要的文档，重复工作等），项目的每次迭代都有明确的 目标.提高客户满意度；短期内产生成效，按预期交付软件，每次迭代结束产生可以运行的软件.改善员工的满意度；团队精神，减少官僚，能够规划和管理自己的工作，减少“恐慌”，稳定 的工作量（可持续的步伐）.E 2 on 3Z.M,TietoEnator9敏捷方法何时有效？公司和客户一致认为应当使用敏捷方法，双方都能理解敏捷方法.敏捷方法对需求不完整以及经常变换的项目比较有效.项目可以划分成固定时间间隔的迭代，并且可以冻结正在进行的迭代的范围 公司和客户都有能力担当角色尤其是Pro duct Owner和Ssrum Master.项目的人员结构能够分成6到10人的团队，最好每个工作地点一个小组.团队成员能够以自组织的方式工作.项目的合同允许变更.固定价格的项目可以使用敏捷，但应当尽量避免。最好在按时间和材料付费或者按月付费的项目中进行使用、变更项目的范围不需要高级管理层的批准.E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator10警告！敏捷开发过程是一个艰苦的过程 Agile Wo rk is Hard Wo rkE 2 0 1。U 始 3Z.MM这种状态也许会存在很长时间！不舒服疑惑有挫折感u o 二 Eo d。一。一 e u山 o 一二 80001三B-A d o oTietoEnator11SDrum概述E 2 on 07 3Z.M,TietoEnatorScrum 概述(1/3)Ssrum是管理软件项目的一个轻量级的敏捷方法，名字来源于橄榄球运动中的scrum 过程,简单，但高度的纪律性依赖迭代和增量的敏捷方法.,Ssrum是一种工作管理的方法，不仅仅限于软件开发，可以用来管理其它活动.Ssrum不包含技术方法或实践.E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator13Scrum概述（2/3）-项目的阶段,项目分成增量的迭代过程，在bru m中称为迭代任务清单，通常持续2-4周的时间.%rint的时间是限定好的；不能从外部改变正在进行中的sprint持续时间和范围.,每个sprint都可以产生可交付的迭代，即测试过并具备文档的的功能点原则上，当产品开发到一定程度时，如实现了足够的客户价值，项目可以在任何一个sprint后 结束,.如同任何项目，敏捷的项目有三个主要阶段：产品定义（规划）；运行prints所需要的准备、规划、技术分析.执行prints（执行）：在增量时间段内实现需求（产品需求清单）.结束：准备最终发布，结束项目E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator14Scrum 概述(3/3)Inputs from Customers,Team,Managers,ExecsVVVftScrum MasterThe TeamDaily Scrum meetings:What did yo u do yesterday Whatwill yo u do to day?What o bstacles are in yo ur way?Daily Scrum1-4 Week,SprintSprint ReviewE 2 on 3Z.M,u o 二 Eo d。一。一 e u山 o 一二 80001三B-A d o oProduct OwnerProduct BacklogTeam Miects startlna at top as much as It can commit todelg by end of SprintTask BreakoutSprint BacklogSprint Planning Meetingn J一Sprint Planning Meeting:Next Sprint Go alSprint Backlo gUpdated Pro duct Backlo gSprint end date and team deliverable do not changeShippable Product IncrementSprint RetrospectiveSo urce:http:www.amdika.co m/scrum_primer_ 1 0.pdfTiel or15E 2 on 07 3Z.M,SDrum角色、实践和工作产品odooTietoEnatorScrum中的三种角色 Pro duct Owner-产品所有者个人：代表所有的干系人 Ssrum Master:个人：负责指导过程的执行 Ssrum Team-Ssrum团队：承诺完成工作，向干系人交付产品价值E2O)QUOO=3ZM*一Stakeho ldersScrumMasterPro duct Owneru o 二 Eo d。一。一 e u山 o 一二 80001三B-A d o oThe Team JTietoEnator17Scrum角色-Scriim团队-Sbrum团队是Scrum的中心角色，产品交付要依靠团队.由rum团队自我组织、自我管理 Ssrum团队是职能交叉的，包含产品交付的所有角色:开发人员、测试人员、build managers,文档编写，界面设计人员.Ssrum团队中的角色是不分等级的；不应当出现“我是开发人员我不作测试”.团队按照最有利于项目的原则来分担责任（如组件的所有权等）.敏捷是建立在信任和授权的基础上，因此团队是自发组织的，组员选择自己的任务，而不是别人强制加以分配的.,另一方面，&rum团队有交付的责任，他们需要能够自我激励和对工作目标进行承诺.团队最佳规模：6-10人E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator18Scrum角色-Scriim团队 主要职责 参与迭代任务清单的创建 执行为干系人创造价值的工作 根据团队的承诺完成所需的各项任务 将工作中的各项障碍迅速与Ssrum Master进行沟通 全面参与所有的各项会议 更新任务状态自发选择任务标识任务的完成标识发现的新的任务与其它团队共同进行工作E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator19u o二可o d。一。一e u山o 一二 8 0 0。三?Scrum 角色 一Scriim MasterSsrum Master不是一个管理者，而是一个教练和推动者-Ssrum团队是一种自发的组 织，是自我管理的.Ssrum Master的角色通常由项目组的成员担当，组长或者项目经理。Ssrum Master 应当是项目中的成员.主要职责：评价过程的健康状况 加强过程 消除障碍 促进过程改进 支持团队开发Arum岫ster的主要工作是做决策、消除障碍，保证团队能顺利交付产品E 2 on 3Z.M,TietoEnator20Scrum 角色 一Scriim MasterSsrum Master还有如下责任 与其它角色配合.,训练团队，提高生产率.培训产品所有者和干系人，确保Ssrum流程的执行 确保一切工作按照既定的规范来运行.规划并进行必要的改进.推动会议的召开.维护障碍列表 维护Ssrum过程改进列表优秀的Ssrum Master应当是专注的,、有决心的、有领导才能.E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator21Scrum 角色一Pro duct Owner,产品所有者代表投资方的利益，确保交付的产品与期望的一致（提供更好的投资回 报）.Pro duct Q/vner决定产品具有哪些功能.,Pro duct Owners的主要责任是创建和维护产品需求清单，即管理项目的范围.Pro duct Q/vner不断的把产品需求清单按优先级进行排序,使得最重要的功能能优先实现.对于团队来说，只有一个需求集。所有的需求申请都归口到Pro duct Q/vner 管理商业价值（投资回报）Pro duct Owner还有如下责任：计划项目的发布，什么时间、向什么人等.对每次小ri nt的结果进行评审和批准E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator22Scrum 角色一Pro duct Owner 参与Ssrum会议 迭代计划会议 团队进展跟踪会议 迭代评审和回顾会议能够随时回答团队工作中产生的各项和产品/业务相关的问题 Pro duct Own6r的角色一般由客户担当，作为服务提供商的公司无法设定优先级.E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator23Scrum角色-客户与管理层,客户和管理的角色是可选的，需要时才设立,客户：是产品的最终用户 通过Pro duct Q/vner来设定对产品的期望 把当前的业务传达给项目.,管理层：公司高级管理层,代表公司在项目中的利益.通过Pro duct Q/vner来传达公司的利益和优先级(prio rities)E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator24产品需求清单Pro duct Backlo g(1/4)一概论基本上，产品需求清单是为了实现产品的功能所需要的工作的列表，包括：功能方面的需求；功能点.非功能方面的需求，如性能改进.要修改的Bug;上一版本的已知错误.新技术，如支持新的操作系统或者平台.问题；日后的不确定项，如新的功能.,产品需求清单是不断完善的.Pro duct Q/vner在项目进行过程中可以随时更新：增加、删除、修改功能，变更优先级等.下一次迭代中要包含较高优先级的需求.产品需求清单也可称为User Sto ries(用例)，因为它们能够给产品的用户带来价值.在一次迭代中要能够实现产品需求清单，如果不能全部实现要进行分解.E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator25u o二可o d。一。一e u山o 一二 8 0 0。三?产品需求清单（2/4）-构成,Pro duct Owner负责创建最初的产品需求清单，一开始是不完整的.最初的清单应当包含足够的需求.清单应当包含多少需求，取决于定价模型（black-bo x,更多的计划时间）.产品需求清单来源于：客户；标书，需求规格说明等.Ssrum团队的想法；增强型新功能等.现有产品的迭代增量；已知错误，技术问题等.比较好的做法是Pro duct Owner、Ssrum团队、客户/管理以及其它相关方（如相关 的险rum团队）举行一次或者多次研讨会 Ssrum Master或者Pro duct Q/vner来促成会议的召开，必须要有人来做.要有效率、要围绕主题、沟通良好、避免不同的假设，承诺并且共通合作，确定优先级.E 2 on 3Z.M,TietoEnator26产品需求清单（3/4）-估计,S:rum团队对产品需求清单的每一项的规模提供初步的估计，通常采用事件点作为单 位Sto ry Po ints（模糊的）.也可采用人天或者人小时作为单位，但容易混淆：a）实际的规模b）时间的单位.精确的估计值可以在frint规划时给出，当前阶段没有足够的信息.规模的相对值才有意义.这个估计值有助于确定优先级；E 2 on 3Z.M,u o二可o d。一。一e u山o 一二 8 0 0。三?产品规模所需时间团队速度TietoEnator27产品需求清单（4/4）-优先级,优先级是产品需求清单中的主要问题.优先级不但反映了客户的价值也反映了风险.产品所有者-po设定优先级.清单中的每一项的优先级是唯一的，但可以对它们进行分类 优先级可以在项目的任何时候进行更改；如新的重要的功能可以直接给较高的优先级.,确定优先级考虑：价值风险 依赖关系E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator28产品需求清单-示例E 2 on OJ 3Z.M,ID,like in any requirements do cumentPrio rityDescriptio n o f the item=User Sto ryu o二可o d。一。一e u山o 一二 8 0 0。三?Ite m#PrivilyProduct Backlog Item*DesciiptionIssued by31Design web page lo o k and feel,flo wCreate and review with custo mer lo o k and feel o f the page.JK52Create graphics&bannersHo tel lo go,animated advertisment banner,backgro und imagesJK73Visito r and admin mo deAdmin sho uld have po ssibility to easily change co ntent o f the pageIT44Add address info rmatio n including interactive mapUser sho uld be able to zo o m in and zo o m o ut map o f the lo catio n o f the ho telJK15Create subpage with pricingPricing info rmatio n available at fro nt deskJK86Create subpage with po ssible events handled in ho telCo ntact Jo hn Ko walsky fo r the list o f eventsJK67Create gallery subpage-28Create references subpageCo ntact Jo hn Ko walsky fo r the referencesJK.These will likely end up in the first SprintTietoEnator29版本发布计划在Ssrum中，不是每个prints都要发布一个版本.迭代的结果主要是要实现功能的演示，不一定就是发布的版本.版本发布计划决定了每次迭代应当包含产品需求清单的哪些功能.根据现有的信息制定的项目总体的长期的计划.根据产品需求清单和团队的进度来决定（实施的范围/迭代，e.g.in Sto ry Po ints）.Ssrum团队参与版本发布计划的制定；架构、风险、依赖性决定了可行的实现顺序.版本发布计划很大程度上依赖于客户的时间表和发布周期，即什么时候客户的产品需 要包含我们的模块（交付物）.版本发布计划不是一成不变的;每个迭代结束后都可以更改.E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator30完成的定义,当迭代任务清单上的任务都完成时，变为“已完成”状态 定义“已完成”的含义是非常重要的，例如：如何记录软件的变化.使用什么样的代码分析工具，发现的问题应当如何处理.进行了什么样的测试，结果是如何记录的，通过标准（如覆盖率、修正的错误）是什么.定义“已完成”意味着定义质量上的需求.“已完成”是0/1变量：完成或者未完成.所有的任务（task）都完成了迭代任务才算完 成.在第一个迭代开始之前应该定义好，因为它会影响工作量，而且必须文档化，这样团 队和产品所有者的理解是一致的.E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator31完成的定义完成的范围随着团队的成熟程度会逐渐发生变化E 2 on 3Z.M,u o二可o d。一。一e u山o 一二 8 0 0。三?潜在的 可交付的软件TietoEnator32完成的定义-Example完成的定义 遵循编码规范 能在模拟器上演示 使用PCLint进行静态代码分析 具有EUnit测试套件的通过率和执行率.或者使用结对编程，或者进行代码走查E 2 0 1。U 始 3Z.MMu o 二 Eo d。一。一 e u山 o 一二 80001三TietoEnator33迭代任务清单规划(1/5)-总论迭代任务清单规划的主要目的是从产品任务清单中挑选高优先级的任务包含在下一 次迭代中，即确定迭代的范围.,至于能够包含多少产品任务清单中的任务取决于bum团队能够承诺完成多少.承诺总是来自于内部，不能从外部强加.迭代不应当有空闲时间，因此规划迭代范围时要保证工作量是稳定的(进度是持续的速度).依赖多个因素；团队的能力，技术的成熟度，当前迭代增量的情况等.,迭代的范围在迭代任务清单中描述；团队设定优先级.产品所有者P0定义每个迭代的任务说明(missio n statement),目标(sprint go al),使迭代更具有针对性，如.“实现一个可扩展的列表控件，其项目是可以选择的”E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator34*rint迭代计划（2/5）-输入和输出E 2 on OJ 3Z.M,uo t e o d。一。一 e u 山 o 一-1 80001三?Sprint Planning MeetingSprint Go alSprint Backlo gTietoEnator35迭代任务清单规划(3/5)-逻辑E 2 on 3Z.M,u o二可o d。一。一e u山o 一二 8 0 0。三?迭代任务清单规划是“铁三角”法则的另一个例子在Ssrum,边界是一个变量，因为：资源(Ssrum团队)是确定的.进度表(迭代的时间)是不能变的.质量是无法协商的团队在一个迭代内能完成的任务，可以用团队进度来衡量(Sto ry Po ints/frint).如果可能的话利用同一个团队上个迭代的进度，“yest erdays weather.Sco pe(Features,Functio nality)30-day sprint 9捌的k d-1 da4o r planning,1 fo r reviyv/retro spective =1/wo rk daysReso urce5 eiso ns in team-590 巾dui D砰加血除(Co st,Budg明5-ho ur wo rking day,average 85口艇甲ro ject wo rk 分90 7.5 0.85=第D例BshOWOott W.Ambler 5%reserved fo r re-estimatio n and re-planning 今 545 man ho ursTietoEnator36u o二可o d。一。一e u山o 一二 8 0 0。三?迭代任务清单规划(4/5)-规划会议召开迭代任务清单规划会议的目的是确定迭代的边界.时间是限定的，最长时间是一个工作日(对持续4个星期的迭代，迭代持续的时间越短，用在规 划上的时间也应该越少.由Ssrum Mast er推动会议.由于会议时间有限，Pro duct Owner和Ssrum团队都应该事前进行准备.前提：产品需求清单是有效的(valid);最新的，标注了优先级并且表述清楚.规划会议要解决两个问题：下次迭代要做什么.确定迭代的目标，包含产品需求清单上高优先级的功能.给Bug修改留一定的余地怎么样实现下次增量所需要的功能.改进设计以实现产品需求清单上的功能.E 2 on 3Z.M,TietoEnator37迭代任务清单规划(5/5)-工作流程 产品所有者向团队介绍起草的产品需求清单和迭代目标.产品所有者传达迭代的起止日期.Ssrum团队从产品需求清单中选取高优先级的功能作为迭代的任务，如果有必要，更新其规模估计.&ru m团队改进架构和设计以便能够实现提出的产品需求.Ssrum团队把产品需求清单的每一项划分成小的任务，并估算每个任务要花费的小 时数.“扑克规划”方法是估算工作量的有效方法.&ru m团队决定一个迭代中能够实现产品需求清单的多少功能产品所有者和rum团队明确了各自要承担的义务.E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator38*rint Backl o g 示例Sprint go alSprint 1 BacklogPerso ns wo rking o n the taskGoal:deliver wording version of wetypageEffo rt estimateE2O)a JUHSAnalysis Design Co nstructio n Testing6ucue-d W-Esuo=e-od-ooo-euwo-a5-1 800z-qi.d。52TietoEnator迭代的非正常终止在险rum中，结束正在进行的迭代是一种极端的行为，只有在万不得以的情况下才能 这么做.有时候确实需要停下来重新规划，而不是一味的蛮干（bangingyo ur head against the wall）.迭代终止可能由下面的人发起：Ssrum团队，如果他们认为达不到目标或者目标不清楚.Ssrum Master,如果迭代没有进展，或者无法克服某个困难.客户/管理层，如果目标已经陈旧/过时（目标产品被取消，平台过时），或者其它的原因（资源 问题等）.迭代终止以后，启动新迭代的计划.导致迭代终止的原因不应该在新的迭代中再次出现.要考虑到合同方面的问题，如时间表的变更等.E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator53迭代评审-概述 迭代评审，在迭代结束后进行，展示迭代的成果（功能运行）.确保成果与预期的一致，收集反馈为项目提供一个参考点，根据目前的位置计划下一期的旅程为下次迭代提供输入（改正、修改、新的想法玲可以由产品所有者添加到产品需求清单.与其它Ssrum会议一样，Ssrum Master主持迭代评审会议，Ssrum团队负责演示.参加会议的其他人包括：产品所有者Pro duct Own6r（必须参加）、客户、管理人员,以及其它感兴趣的人，例如其他Ssrum团队（注意保密协议的要求）.评审会议的时间是固定的：最长4个小时.评审会议应当是非正式的、创造性的，不用幻灯片等正式的东西.E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator54u o二可o d。一。一e u山o 一二 8 0 0。三?迭代评审-流程 在评审会议召开之前，团队要做好准备：有组织、有效地进行演示，不要超过4个小时.谁来演示，演示什么，怎样演示？计划准备的时间不要超过一个小时.,迭代评审流程的一个例子：Ssrum Master介绍本次迭代的总体情况.目标和清单vs.实际的结果，如果存在差距，原因是什么.Ssrum团队简要介绍所涉及的技术问题，如架构及其变更.Ssrum团队演示已经实现的功能：演示并进行功能说明在场的人能够亲自尝试使用不同的功能.Ssrum Master推动自由讨论，集思广益.迭代评审应当是互动的；有问题提出，问题解答，并欢迎提出想法和建议.E 2 on 3Z.M,TietoEnator55迭代评审-可能的措施,产品所有者根据评审的结果可能采取如下行动：更新产品需求清单，重新设定优先级：包含没有按计划实现的功能（进度比预期的要慢，任务未完成）.不在计划中当却已经实现的功能（进度比预期的快）.迭代评审中出现的新的想法.与Ssrum Master 一起解决团队的变动问题.要求把演示的功能，或者把上次迭代的功能，作为一个版本发布给客户.决定项目不再持续下去，不再进行迭代；认为产品已完备.要求把产品需求清单授权给另外的团队来一起工作.E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator56迭代U顾会议 中rint Retro spective,回顾的目的是评价本次迭代并酝酿改进，使得下一个迭代进行的更好.类似于项目的最终评审，但经常举行.障碍列表具有很好的参考价值！Ssrum Master主持召开，持续半天，Ssrum团队参加（产品所有者也可参加）.,简单流程：Ssrum Master总结本次迭代；迭代任务清单，重要的事情和决策，预期的/实际进度.每个组员陈述迭代中那些方法进行的较好、哪些需要改进，Ssrum Master进行记录.对重要的问题计划相应的措施：团队自己解决，或者提交给公司的管理层.E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator57E 2 on OJ 3Z.M,SDrum方法应用co二可o d。5-E U山。TietoEnator敏捷开发中使用扑克Po ker方法进行估计（1/3）尽管名字有好笑，但却非常可靠和有效.可以来估算产品需求清单中每项的规模（规 模估算：用例点sto ry po int）以及迭代任务清 单中任务的估计（工作量估算：人时）.Ssrum Master推动活动的进行，一个以上的专 家参与估算，而且最好是项目团队中的人.估算时使用卡片：写有一系列的离散数据，如0,1,2,3,5,8,13,?（无法估计）.E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator59u o二可o d。一。一e u山o 一二 8 0 0。三?敏捷开发中使用扑克Po ker方法进行估计（2/3）,前提条件：提前准备好要估算的任务、User Sto ries等；迭代任务清单和产品需求清单 都已经起草好.对某个任务最有经验的开发者做一个简短的概述.可以通过简短的讨论澄清任务的具 体含义，找出存在的风险以及不确定性.各自对任务进行估计，所有的人将写有各自估计数据的扑克/卡片扣上。（单位事先 进行约定：工时、事件点）.,大家同时把扑克/卡片翻过来.如果扑克/卡片上的数差距比较明显（如一个13,2个5,一个1）,就要讨论一下为什么 会出现这么大的差距，估计值所基于的假定要进行澄清.如果差距较小（如三个8两个5）,主持人帮助确定最终的估值.对于不确定性，估算数据中可以多包含一些余量.不断的重复该过程直到达成一致.将这些估值记录到相应的文档中（产品需求清单，迭代任务清单）.E 2 on 3Z.M,TietoEnator60敏捷开发中使用扑克Po ker方法进行估计(3/3),为什么使用离散的数字？比使用任意数字更加容易进行估算.在整个项目中或者迭代中，每个人估计值的错误会相互抵消掉.对每个任务，16小时是上限，不确定性会随着规模的增加而增加.为什么要有将较大的任务进行分解，帮助更加精确的估计同时减少不确定性.为什么要“讨论并重复”？弄清不同的假设(利用重用代码或者重新编码)和可能的误解玲更为可靠的估计.对于那些偏离平均值的估计，即使由有经验的人给出的，也必须要有充分的理由.E 2 on 3Z.M,U。二可o d。-E U山。一-1 一6一TietoEnator61练习在一个小时之内编写一个三只小猪的连环画册使用Ssrum实践 自组织团队迭代 每日Ssrum会议 产品需求清单 迭代任务清单E 2 on 3Z.M,u o 二 Eo d。一。一 e u山 o 一二 80001三B-A d o o笆Micro so ft Wo rd Do cumentTietoEnator62练习-进度安排 5分钟：迭代目标团队与产品所有者共同协作，从产品需求列表中 选择本次迭代要完成的项目 5分钟：迭代任务清单团队从所选择的产品需求列表中产生任务 10分钟：第一天团队完成任务和产品需求列表中的项目产品所有者负责回答问题 5分钟：“每日”“Ssrum会议 每个人回答三个问题E 2 on 3Z.M,10分钟：第二天 团队继续完成任务和产品需求列表中的项目 产品所有者负责回答问题5分钟：“每日”“Ssrum会议 每个人回答三个问题10分钟：第三天 团队完成产品的一个版本 产品所有者负责回答问题每组5分钟：演示 团队向产品所有者展示完成的连环画册u o 二 Eo d。一。一 e u山 o 一二 80001三TietoEnator63练习-给出优先级的产品需求清单E 2 on 3Z.M,u o二可o d。一。一e u山o 一二 8 0 0。三?展示基本的故事 用铅笔画展示的故事 每页图画配有说明 给出写有标题的封面 故事用9页进行说明 展示版权信息 添加色彩 广告 教小孩数数1,2,3 寓教于乐：坚固的重要性 封皮吸引人硬的封皮 3国果的卡通形象 展示所有的故事内容产品所有者-Pro duct Owner充分考虑市场情况，对产品进行规划并进行 简要地说明 规划当前该产品如何占有更多的市场份额规划今后该产品的发展前景Scrum团队根据产品所有者的产品规划进行开 发TietoEnator64u o二可o d。一。一e u山o 一二 8 0 0。三?测试驱动开发 Test Driven Develo pment什么是测试驱动？一种能够支持Ssrum的敏捷实践方法，开发满足Do D的软件首先创建测试用例，然后开发软件通过测试(在开 发代码前，首先编写测试代码)一种设计软件的方法，而不仅仅是一种测试 方法-所创建的测试用例用来指导和约束项目中的 各项工作，对未来的各项工作提供一个安全 的保护不需要测试的工作不需要完成 所创建的测试用例通常替代详细的业务和技 术需求定-测试也有效地驱动设计，使设计更加趋向于 可行的设计 通常情况下需要自动测试的支持(EUnit,JUnit etc.).对于UI软件应用TDD方法有一定的困难1E 2 on OJ 3Z.M,Add a testPassFailRun the testsFailMake a little changeRun the testsPass,Development continuesPass,Development stopsCo pyright 2003-2006 Sco Q W AmblerTietoEnator65测试驱动开发-TDD,测试用例的作用：确定所要完成的工作沟通工具 产生一致的结果 对软件开发提供一个安全的保障E 2 on 3Z.M,u o二可o d。一。一e u山o 一二 8 0 0。三?TietoEnator66Scrum的核心E 2 on OJ 3Z.M,反馈 检查 接受Release PlanWeeks Acceptance TestDaysMo nthsIteration Plan阶段发布迭代演示u o二可o d。一。一e u山o 一二 8 0 0。三?One DayJPair NegotiationHo urs/Stand Up MeetingUnit Test Minute/.Pair ProgrammingSeco nd sxCpOC Cupui田 J.Xniuxao结对编程TietoEnator67应用（1/4）-概述 基本原则：不能只挑自己喜欢的，不管其它的 Srum非常简单，为了有效地发挥作用，应当具备：所有的角色.所有的实践.所有的产品.&rum可以进行裁剪，但应当明白裁剪对工程的影响玲需要经验和仔细考虑.E 2 on 3Z.M,uo