Scrum敏捷软件开发过程

Scrum敏捷软件开发过程目录•什么是敏捷软件开发？•敏捷方法的项目计划•敏捷项目管理和传统项目管理•为什么使用敏捷？•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敏捷过程的限制•敏捷软件开发过程包含过程、原则、工具，和最重要的-人•因此：诚信是基础•没有过程能够对诚信进行有效地约束，诚信与否是有效实施敏捷过程的最大限制ProductconstantlyScope frozen new PBL items to next SprintBacklog使用敏捷方法的项目计划“Sprintful” of top - priority PBL to the next SprintSprintMore accurate estimates as man hours8Short term planning (commitment byMay be52 13 8 5 8∑32Long term planning (best guess at the moment):Initial Size Estimates As Story PointsVelocity 8 SP/Sprint 4 Sprints T arget Sprint for each PBL item set, feasible implementation Order.敏捷项目管理和传统项目管理• 传统项目管理：• 事先对整个项目进行估计、计划、分析 • 反对变更; 变更需要重新估计、重新规划• 严密的合同来减少风险, 如果改变需求要走 CR 流程. • 项目作为一个“黑盒子”，对客户与供应商的可视性差. • 产品化和测试阶段是分离的. • 文档和计划驱动的方法.• 软件交付时间晚, 意识到风险的时间晚.• 敏捷项目管理:• 对整个项目做一个粗略的估计,每一次迭代都有详细的计划. • 鼓励变化, 客户价值驱动开发.• 信任和赋予权力;合约使变更变得简单，增加价值. • 客户和开发人员之间是紧密的连续的合作关系 • 每次迭代都产生可交付的软件 • 专注于交付软件.• 第一次迭代就可交付能工作的版本，风险发现的早.为什么采用敏捷? –预期的收益• 采用敏捷方法得当的话，可以： • 更加透明; 随时跟踪项目的状态和进展情况，及早发现问题和风险 . • 快速交付, 每次迭代都能交付可运行的软件.• 最高风险和最高优先级的需求，最优先进行开发. • 改善应对变更能力, 减少大量的重计划. • 改善项目沟通.•更好的客户参与, 避免错误的假设.• 总之:•提高了生产率; 减少“浪费”（不需要的文档，重复工作等），项目的每次迭代都有明确的目标.•提高客户满意度;短期内产生成效,按预期交付软件,每次迭代结束产生可以运行的软件.•改善员工的满意度;团队精神，减少官僚，能够规划和管理自己的工作，减少“恐慌”，稳定的工作量（可持续的步伐）.敏捷方法何时有效？•公司和客户一致认为应当使用敏捷方法，双方都能理解敏捷方法.•敏捷方法对需求不完整以及经常变换的项目比较有效.•项目可以划分成固定时间间隔的迭代,并且可以冻结正在进行的迭代的范围•公司和客户都有能力担当角色尤其是Product Owner和Scrum Master.•项目的人员结构能够分成6到10人的团队，最好每个工作地点一个小组.•团队成员能够以自组织的方式工作.•项目的合同允许变更.•固定价格的项目可以使用敏捷，但应当尽量避免。

•最好在按时间和材料付费或者按月付费的项目中进行使用•变更项目的范围不需要高级管理层的批准.Scrum概述Scrum概述(1/3)•Scrum是管理软件项目的一个轻量级的敏捷方法,名字来源于橄榄球运动中的scrum过程•简单，但高度的纪律性•依赖迭代和增量的敏捷方法.•Scrum是一种工作管理的方法，不仅仅限于软件开发，可以用来管理其它活动.•Scrum不包含技术方法或实践.Scrum概述(2/3)–项目的阶段•项目分成增量的迭代过程，在Scrum中称为迭代任务清单,通常持续2-4周的时间.•Sprint的时间是限定好的;不能从外部改变正在进行中的sprint持续时间和范围.•每个sprint都可以产生可交付的迭代,即测试过并具备文档的的功能点•原则上,当产品开发到一定程度时，如实现了足够的客户价值，项目可以在任何一个sprint后结束.•如同任何项目，敏捷的项目有三个主要阶段：•产品定义(规划);运行Sprints所需要的准备、规划、技术分析.•执行Sprints(执行):在增量时间段内实现需求(产品需求清单).•结束:准备最终发布，结束项目Scrum概述(3/3)Daily Scrum meetings:What did you do yesterday你昨天做了什么What will you do today?你今天会做什么What obstacles are in your way?有什么障碍在你的方式DailySprint Planning Meeting:Next Sprint Goal下一个Sprint目标Shippable Product Increment 可交付的产品增量SprintRetrospectiveSprint回顾Updated Product Backlog更新Product BacklogScrum的流程1、将整个产品Backlog分解成Sprint Backlog，按照目前的人力物力条件可以完成的。

2、召开Sprint计划会议，划分、确定这个Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。

注意这里的任务是以小时计算的，并不是按人天计算，长度不超过8小时。

3、进入Sprint开发周期,每个Sprint迭代周期为连续30个日例日（2-4周）。

在这个周期内，每天需要召开每日Scrum简会，时间为15分钟。

在会议中每个团队成员仅就以下三点发言:自上次Scrum会议后你做了什么?从现在到下次Scrum会议的时间里你准备做什么?你在工作中遇到了哪些困难?4、整个Sprint周期结束，召开Sprint评审会议(Sprint review meeting)，将成果演示给Product Owner，该会议限定时间为4小时。

5、团队成员最后召开冲刺回顾会议(Sprint retrospective meeting)，总结问题和经验，该会议限定时间为3小时。

6、这样周而复始，按照同样的步骤进行下一次Sprint。

Scrum角色、实践和工作产品Scrum中的三种角色•Product Owner-产品所有者•个人：代表所有的干系人•Scrum Master:•个人：负责指导过程的执行•Scrum Team–Scrum团队:•承诺完成工作，向干系人交付产品价值Scrum角色–Scrum团队•Scrum团队是Scrum的中心角色，产品交付要依靠团队.•Scrum团队自我组织、自我管理•Scrum团队是职能交叉的，包含产品交付的所有角色:开发人员、测试人员、build managers,文档编写,界面设计人员.•Scrum团队中的角色是不分等级的;不应当出现“我是开发人员我不作测试”.•团队按照最有利于项目的原则来分担责任(如组件的所有权等).•敏捷是建立在信任和授权的基础上，因此团队是自发组织的，组员选择自己的任务，而不是别人强制加以分配的.•另一方面，Scrum团队有交付的责任，他们需要能够自我激励和对工作目标进行承诺.•团队最佳规模：6-10人•主要职责•参与迭代任务清单的创建•执行为干系人创造价值的工作•根据团队的承诺完成所需的各项任务•将工作中的各项障碍迅速与Scrum Master进行沟通•全面参与所有的各项会议•更新任务状态•自发选择任务•标识任务的完成•标识发现的新的任务•与其它团队共同进行工作◆Scrum角色–Scrum Master•Scrum Master不是一个管理者，而是一个教练和推动者-Scrum团队是一种自发的组织，是自我管理的.•Scrum Master的角色通常由项目组的成员担当，组长或者项目经理。

Scrum Master应当是项目中的成员.•主要职责:•评价过程的健康状况•加强过程•消除障碍•促进过程改进•支持团队开发•Scrum Master的主要工作是做决策、消除障碍，保证团队能顺利交付产品•Scrum Master还有如下责任•与其它角色配合.•训练团队，提高生产率.•培训产品所有者和干系人，确保Scrum流程的执行•确保一切工作按照既定的规范来运行.•规划并进行必要的改进.•推动会议的召开.•维护障碍列表•维护Scrum过程改进列表•优秀的Scrum Master应当是专注的,、有决心的、有领导才能.◆Scrum角色–Product Owner•产品所有者代表投资方的利益，确保交付的产品与期望的一致（提供更好的投资回报).•Product Owner决定产品具有哪些功能.•Product Owner’s的主要责任是创建和维护产品需求清单,即管理项目的范围.•Product Owner不断的把产品需求清单按优先级进行排序，使得最重要的功能能优先实现.•对于团队来说，只有一个需求集。

所有的需求申请都归口到Product Owner•管理商业价值（投资回报）•Product Owner还有如下责任:•计划项目的发布，什么时间、向什么人等.•对每次Sprint的结果进行评审和批准•参与Scrum会议•迭代计划会议•团队进展跟踪会议•迭代评审和回顾会议•能够随时回答团队工作中产生的各项和产品/业务相关的问题•Product Owner的角色一般由客户担当，作为服务提供商的公司无法设定优先级.Scrum角色–客户与管理层•客户和管理的角色是可选的，需要时才设立•客户:•是产品的最终用户•通过Product Owner来设定对产品的期望•把当前的业务传达给项目.•管理层:•公司高级管理层,代表公司在项目中的利益.•通过Product Owner来传达公司的利益和优先级（priorities）产品需求清单Product Backlog概论•基本上，产品需求清单是为了实现产品的功能所需要的工作的列表，包括:•功能方面的需求;功能点.•非功能方面的需求,如性能改进.•要修改的Bug;上一版本的已知错误.•新技术,如支持新的操作系统或者平台.•问题;日后的不确定项,如新的功能.•产品需求清单是不断完善的.•Product Owner在项目进行过程中可以随时更新：增加、删除、修改功能，变更优先级等.•下一次迭代中要包含较高优先级的需求.•产品需求清单也可称为User Stories(用例)，因为它们能够给产品的用户带来价值.•在一次迭代中要能够实现产品需求清单，如果不能全部实现要进行分解.构成•Product Owner负责创建最初的产品需求清单，一开始是不完整的.•最初的清单应当包含足够的需求.•清单应当包含多少需求,取决于定价模型(black-box,更多的计划时间).•产品需求清单来源于:•客户;标书,需求规格说明等.•Scrum团队的想法;增强型新功能等.•现有产品的迭代增量;已知错误,技术问题等.document Description of the item=User•比较好的做法是Product Owner、Scrum团队、客户/管理以及其它相关方（如相关的Scrum 团队）举行一次或者多次研讨会•Scrum Master或者Product Owner来促成会议的召开，必须要有人来做.•要有效率、要围绕主题、沟通良好、避免不同的假设，•承诺并且共通合作，确定优先级.估计•Scrum团队对产品需求清单的每一项的规模提供初步的估计，通常采用事件点作为单位Story Points(模糊的).•也可采用人天或者人小时作为单位，但容易混淆：a)实际的规模b)时间的单位.•精确的估计值可以在Sprint规划时给出,当前阶段没有足够的信息.•规模的相对值才有意义.•这个估计值有助于确定优先级;优先级•优先级是产品需求清单中的主要问题.•优先级不但反映了客户的价值也反映了风险.•产品所有者-PO设定优先级.•清单中的每一项的优先级是唯一的,但可以对它们进行分类•优先级可以在项目的任何时候进行更改;如新的重要的功能可以直接给较高的优先级.•确定优先级考虑：•价值•风险•依赖关系示例ID,like in anyrequirementsPriorityThese will likely endup in the first Sprint版本发布计划•在Scrum中,不是每个Sprints都要发布一个版本.•迭代的结果主要是要实现功能的演示,不一定就是发布的版本.•版本发布计划决定了每次迭代应当包含产品需求清单的哪些功能.•根据现有的信息制定的项目总体的长期的计划.•根据产品需求清单和团队的进度来决定(实施的范围/迭代,e.g.in Story Points).•Scrum团队参与版本发布计划的制定;架构、风险、依赖性决定了可行的实现顺序.•版本发布计划很大程度上依赖于客户的时间表和发布周期，即什么时候客户的产品需要包含我们的模块（交付物）.•版本发布计划不是一成不变的;每个迭代结束后都可以更改.完成的定义•当迭代任务清单上的任务都完成时，变为“已完成”状态•定义“已完成”的含义是非常重要的,例如:•如何记录软件的变化.•使用什么样的代码分析工具，发现的问题应当如何处理.•进行了什么样的测试,结果是如何记录的,通过标准（如覆盖率、修正的错误）是什么.•定义“已完成”意味着定义质量上的需求.•“已完成”是0/1变量：完成或者未完成.所有的任务（task)都完成了迭代任务才算完成.•在第一个迭代开始之前应该定义好，因为它会影响工作量,而且必须文档化，这样团队和产品所有者的理解是一致的.•完成的范围随着团队的成熟程度会逐渐发生变化计划分析架构性能指标试运行代码评审验收设计开发测试支持文档集成用户文档完成的定义-Example•完成的定义•遵循编码规范•能在模拟器上演示•使用PCLint进行静态代码分析•具有EUnit测试套件的通过率和执行率.•或者使用结对编程，或者进行代码走查迭代任务清单Sprint Backlog总论•迭代任务清单规划的主要目的是从产品任务清单中挑选高优先级的任务包含在下一次迭代中，即确定迭代的范围.•至于能够包含多少产品任务清单中的任务取决于Scum团队能够承诺完成多少.•承诺总是来自于内部，不能从外部强加.•迭代不应当有空闲时间,因此规划迭代范围时要保证工作量是稳定的(进度是持续的速度).•依赖多个因素;团队的能力,技术的成熟度,当前迭代增量的情况等.•迭代的范围在迭代任务清单中描述;团队设定优先级.•产品所有者PO定义每个迭代的任务说明（mission statement），目标(sprint goal)，使迭代更具有针对性，如.“实现一个可扩展的列表控件，其项目是可以选择的”输入和输出Scrum TeamProduct Team Business Technology CurrentProduct Owner CustomersManagementSprint PlanningMeetingSprint GoalSprint Backlog逻辑• 迭代任务清单规划 是“铁三角”法则的另一个例子 • 在 Scrum, 边界是一个变量，因为:• 资源 (Scrum 团队) 是确定的.• 进度表（迭代的时间）是不能变的. • 质量是无法协商的• 团队在一个迭代内能完成的任务，可以用团队进度来衡量 (Story Points / Sprint).• 如果可能的话利用同一个团队上个迭代的进度, “yesterday’s weather”.30-day sprint 20 work days1 day for planning, 1 for review/retrospective = 18 work days5 persons in team 90 theoretical man days 7.5-hour working day, average 85% to project work90*7.5*0.85 = 574 man hours5% reserved for re -estimation and re -planning规划会议• 召开迭代任务清单规划会议的目的是确定迭代的边界.• 时间是限定的, 最长时间是一个工作日 (对持续 4 个星期的迭代, 迭代持续的时间越短，用在规划上的时间也应该越少. • 由 Scrum Master 推动会议.• 由于会议时间有限，Product Owner 和 Scrum 团队都应该事前进行准备.• 前提: 产品需求清单是有效的（valid ）; 最新的, 标注了优先级并且表述清楚.• 规划会议要解决两个问题:• 下次迭代要做什么.• 确定迭代的目标，包含产品需求清单上高优先级的功能. • 给 Bug 修改留一定的余地• 怎么样实现下次增量所需要的功能.• 改进设计以实现产品需求清单上的功能.工作流程•产品所有者向团队介绍起草的产品需求清单和迭代目标.•产品所有者传达迭代的起止日期.•Scrum团队从产品需求清单中选取高优先级的功能作为迭代的任务，如果有必要，更新其规模估计.•Scrum团队改进架构和设计以便能够实现提出的产品需求.•Scrum团队把产品需求清单的每一项划分成小的任务，并估算每个任务要花费的小时数.•“扑克规划”方法是估算工作量的有效方法.•Scrum团队决定一个迭代中能够实现产品需求清单的多少功能•产品所有者和Scrum团队明确了各自要承担的义务.Sprint Backlog示例Personsworkingon EffortSprintMeets thedefinition ofDescriptiontheTask blockedby an执行迭代任务清单•执行迭代任务清单意味着团队在迭代期间自行开发.•团队清楚要达到什么的目标以及怎样达到目标.•每人每一时间只有一个任务•团队是自发组织的；成员自己挑选任务,Scrum Master提供指导并清除障碍.•不能从外部改变迭代的范围或者迭代的周期.•为了达到迭代的目标，团队可以增加、删除任务或者改变其优先次序.•如果要重新设定迭代的范围时需要产品所有者的配合.•迭代周期短，意味着工期紧;应该把重点放在剩余的工作和风险的消除，要区分任务的优先级，重要的事情应当先做.•迭代应当达到项目的质量要求(definition of“done”);没有独立的测试阶段.迭代进度图-Burndown Chart•Scrum注重成果，它关心的是要花多少时间达到目标，而不是已经花费的时间;.•团队能否在既定的时间达到迭代的目标,可以查看要完成产品需求清单的功能所剩余的工作•Remaining work=Estimate to Complete(ETC).•描述剩余工作量和时间关系的图表称为Sprint Burndown图,是Scrum中非常重要的控制方法(control measure).•给Scrum团队和产品所有者提供直观的信息.•术语burndown表明Scrum团队在迭代过程中消耗剩余工作的能力;迭代结束时其值为0.•每个任务（task）的工作量由Scrum团队来估计.•每天都要进行估计，以便进行跟踪.•可以使用电子表格或者专门的工具（如ScrumWorks）Remaining work increasing T asks underestimatedand/or work remainingInitial estimate (752h) In the beginning of theall tasks in theSprint Backlog on a particular day.T asks removed from theSprint Backlog to meetSprint Goal faster decline. IdealActualScrum每日例会小鸡和猪的故事•A chicken and a pig are together when the chicken says,"Let's 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.I'd be committed,but you'd only be involved!“•In a Daily Sprint,only Scrum Master and Scrum Team are committed,and thus allowed to speak.Others are only involved.概述•例会最长15分钟，在整个迭代过程中每天的同一时间召开.•团队成员之间交流信息.•了解项目的真实的进展情况•交流风险和存在的问题.•面对面的会议加强了承诺.•Scrum Master负责整个会议(会议地点,邀请等).•其他人可以参与,但只允许Scrum Master和Scrum团队成员讲话(小鸡和猪).•例会之前团队要更新工作量估计，使进度表保持最新.形式•为使会议简短而富有成效，要遵循严格的规程•每个成员向其他人汇报以下内容:•上次会议以后所做的工作?•下次会议之前要做的工作?•工作中是否有什么障碍?•如果出现其它的问题（如设计的问题），应当在会议后处理.•纪录会议纪要，例如wiki.•要养成良好的会议习惯障碍•基本上，任何阻止团队正常工作的，都可称之为障碍，例如:•无法访问信息系统.•所需要的信息不能及时提供或者提供的不正确，如界面规格或者其它软件模块不到位或不正确•开发环境或者原型系统出现问题•其他的任务分配：培训，售前支持•缺乏必要的信息或者相应的知识•对于团队提出的各项障碍，Scrum Master要以列表形式进行记录，谁来清除障碍？•每个人•自我管理、自我组织的团队•Scrum Master•产品所有者•管理层•其他相关的干系人•Scrum Master负责确定障碍已经清除，不一定亲自自己清除清除障碍•某些障碍是浪费•部分地完成工作•额外的过程•额外的功能•任务转换•等待•缺陷•清除障碍的过程是团队和组织学习的过程浪费产生的原因•多问几个“为什么”•对于每个标识的障碍或者浪费，问一问“为什么”浪费会存在•多问几个“为什么”，找到造成浪费的根本原因迭代中的同步工作•每次迭代不是小的瀑布项目•而是，每件事情同时都做一点迭代的非正常终止•在Scrum中，结束正在进行的迭代是一种极端的行为，只有在万不得以的情况下才能这么做.•有时候确实需要停下来重新规划，而不是一味的蛮干(banging your head against the wall).•迭代终止可能由下面的人发起:•Scrum团队,如果他们认为达不到目标或者目标不清楚.•Scrum Master,如果迭代没有进展,或者无法克服某个困难.•客户/管理层,如果目标已经陈旧/过时(目标产品被取消，平台过时)，或者其它的原因(资源问题等).•迭代终止以后,启动新迭代的计划.•导致迭代终止的原因不应该在新的迭代中再次出现.•要考虑到合同方面的问题，如时间表的变更等.迭代评审会议概述•迭代评审，在迭代结束后进行，展示迭代的成果(功能运行).•确保成果与预期的一致，收集反馈•为项目提供一个参考点，根据目前的位置计划下一期的旅程•为下次迭代提供输入（改正、修改、新的想法à可以由产品所有者添加到产品需求清单.•与其它Scrum会议一样,Scrum Master主持迭代评审会议,Scrum团队负责演示.•参加会议的其他人包括:产品所有者Product Owner(必须参加)、客户、管理人员,以及其它感兴趣的人,例如其他Scrum团队(注意保密协议的要求).•评审会议的时间是固定的:最长4个小时.•评审会议应当是非正式的、创造性的，不用幻灯片等正式的东西.迭代评审–流程•在评审会议召开之前，团队要做好准备:•有组织、有效地进行演示，不要超过4个小时.•谁来演示，演示什么，怎样演示?•计划准备的时间不要超过一个小时.•迭代评审流程的一个例子:•Scrum Master介绍本次迭代的总体情况.•目标和清单vs.实际的结果,如果存在差距，原因是什么.•Scrum团队简要介绍所涉及的技术问题，如架构及其变更.•Scrum团队演示已经实现的功能:•演示并进行功能说明•在场的人能够亲自尝试使用不同的功能.•Scrum Master推动自由讨论，集思广益.•迭代评审应当是互动的;有问题提出,问题解答，并欢迎提出想法和建议.迭代评审–可能的措施•产品所有者根据评审的结果可能采取如下行动:•更新产品需求清单，重新设定优先级:•包含没有按计划实现的功能(进度比预期的要慢,任务未完成).•不在计划中当却已经实现的功能(进度比预期的快).•迭代评审中出现的新的想法.•与Scrum Master一起解决团队的变动问题.•要求把演示的功能，或者把上次迭代的功能，作为一个版本发布给客户.•决定项目不再持续下去，不再进行迭代;认为产品已完备.•要求把产品需求清单授权给另外的团队来一起工作.•……迭代回顾会议Sprint Retrospective•回顾的目的是评价本次迭代并酝酿改进，使得下一个迭代进行的更好.•类似于项目的最终评审，但经常举行.•障碍列表具有很好的参考价值!•Scrum Master主持召开,持续半天,Scrum团队参加(产品所有者也可参加).•简单流程:•Scrum Master总结本次迭代;迭代任务清单,重要的事情和决策,预期的/实际进度.•每个组员陈述迭代中那些方法进行的较好、哪些需要改进,Scrum Master进行记录.•对重要的问题计划相应的措施：团队自己解决,或者提交给公司的管理层.Scrum方法应用扑克Poker方法敏捷开发中使用扑克Poker方法进行估计(1/3)•尽管名字有好笑,但却非常可靠和有效.•可以来估算产品需求清单中每项的规模（规模估算:用例点story point）以及迭代任务清单中任务的估计(工作量估算：人时).•Scrum Master推动活动的进行,一个以上的专家参与估算,而且最好是项目团队中的人.•估算时使用卡片：写有一系列的离散数据，如0,1,2,3,5,8,13,?(无法估计).敏捷开发中使用扑克Poker方法进行估计(2/3)•前提条件:提前准备好要估算的任务、User Stories等;迭代任务清单和产品需求清单都已经起草好.•对某个任务最有经验的开发者做一个简短的概述.可以通过简短的讨论澄清任务的具体含义，找出存在的风险以及不确定性.•各自对任务进行估计，所有的人将写有各自估计数据的扑克/卡片扣上。