1、1什么是敏捷软件开发？敏捷方法的项目计划敏捷项目管理和传统项目管理为什么使用敏捷？Scrum概述 Scrum的角色 Scrum实践和工作产品 敏捷开发中的估计方法测试驱动开发Scrum应用支持工具和模版一些常见的误解23敏捷软件开发是软件项目的一个概念框架.有许多建立在敏捷概念上的方法，如 Scrum 和 Extreme Programming (XP).与僵化的、重量级的、官僚式的方法形成对照，比如瀑布模型（指纯粹形式的）最大限度地降低短期固定时间的迭代式软件的开发风险.4人和交互胜过过程和工具. Individuals and interactions over processes and
2、 tools可以工作的软件胜过完备的文档.Working software over comprehensive documents客户协作胜过合同谈判.Customer collaboration over contract negotiation随时应对变化胜过遵循计划.Responding to change over following a plan5敏捷软件开发过程包含过程、原则、工具，和最重要的-人因此 诚信是基础没有过程能够对诚信进行有效地约束 诚信与否是有效实施敏捷过程的最大限制6Product Backlog(Features)521385832Initial SizeEst
3、imatesAs 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 hou
4、rs Short term planning (commitment by Team):May be constantlyupdatedScope frozen new PBL items to next Sprint7传统项目管理：事先对整个项目进行估计、计划、分析反对变更; 变更需要重新估计、重新规划严密的合同来减少风险, 如果改变需求要走 CR 流程.项目作为一个“黑盒子” ，对客户与供应商的可视性差.产品化和测试阶段是分离的.文档和计划驱动的方法.软件交付时间晚, 意识到风险的时间晚.敏捷项目管理:对整个项目做一个粗略的估计,每一次迭代都有详细的计划.鼓励变化, 客户价值驱动开发.信任
5、和赋予权力;合约使变更变得简单，增加价值.客户和开发人员之间是紧密的连续的合作关系每次迭代都产生可交付的软件专注于交付软件.第一次迭代就可交付能工作的版本，风险发现的早. 8采用敏捷方法得当的话，可以：更加透明; 随时跟踪项目的状态和进展情况，及早发现问题和风险 .快速交付, 每次迭代都能交付可运行的软件.最高风险和最高优先级的需求，最优先进行开发.改善应对变更能力, 减少大量的重计划.改善项目沟通.更好的客户参与, 避免错误的假设.总之:提高了生产率; 减少“浪费” （不需要的文档，重复工作等） ，项目的每次迭代都有明确的目标.提高客户满意度; 短期内产生成效, 按预期交付软件, 每次迭代结
6、束产生可以运行的软件.改善员工的满意度; 团队精神，减少官僚，能够规划和管理自己的工作，减少“恐慌” ，稳定的工作量（可持续的步伐）. 9公司和客户一致认为应当使用敏捷方法，双方都能理解敏捷方法.敏捷方法对需求不完整以及经常变换的项目比较有效.项目可以划分成固定时间间隔的迭代, 并且可以冻结正在进行的迭代的范围公司和客户都有能力担当角色尤其是Product Owner 和 Scrum Master.项目的人员结构能够分成6到10人的团队，最好每个工作地点一个小组.团队成员能够以自组织的方式工作. 项目的合同允许变更.固定价格的项目可以使用敏捷，但应当尽量避免。 最好在按时间和材料付费或者按月付
7、费的项目中进行使用、变更项目的范围不需要高级管理层的批准.10敏捷开发过程是一个艰苦的过程Agile Work is Hard Work这种状态也许会存在很长时间！不舒服疑惑有挫折感1112Scrum是管理软件项目的一个轻量级的敏捷方法, 名字来源于橄榄球运动中的scrum 过程简单，但高度的纪律性依赖迭代和增量的敏捷方法.Scrum 是一种工作管理的方法，不仅仅限于软件开发，可以用来管理其它活动.Scrum 不包含技术方法或实践.13项目分成增量的迭代过程，在Scrum中称为迭代任务清单, 通常持续2-4周的时间.Sprint 的时间是限定好的; 不能从外部改变正在进行中的sprint持续时
8、间和范围.每个sprint都可以产生可交付的迭代, 即测试过并具备文档的的功能点原则上, 当产品开发到一定程度时，如实现了足够的客户价值，项目可以在任何一个sprint后结束,.如同任何项目，敏捷的项目有三个主要阶段 :产品定义 (规划); 运行Sprints 所需要的准备、规划、技术分析.执行Sprints (执行): 在增量时间段内实现 需求 (产品需求清单).结束: 准备最终发布，结束项目14Sprint Planning Meeting:Next Sprint GoalSprint BacklogUpdated Product BacklogDaily Scrum meetings :
9、 What did you do yesterdayWhat will you do today?What obstacles are in your way?Source: http:/ ScrumSprintRetrospectiveShippableProduct Increment1516Product Owner- 产品所有者个人：代表所有的干系人Scrum Master: 个人：负责指导过程的执行Scrum Team Scrum团队:承诺完成工作，向干系人交付产品价值17Scrum 团队是Scrum的中心角色， 产品交付要依靠团队.Scrum 团队自我组织、自我管理Scrum 团队
10、是职能交叉的， 包含产品交付的所有角色:开发人员、测试人员、build managers, 文档编写, 界面设计人员.Scrum 团队中的角色是不分等级的; 不应当出现“我是开发人员我不作测试”.团队按照最有利于项目的原则来分担责任 (如组件的所有权等 ).敏捷是建立在信任和授权的基础上，因此团队是自发组织的，组员选择自己的任务，而不是别人强制加以分配的.另一方面，Scrum团队有交付的责任，他们需要能够自我激励和对工作目标进行承诺.团队最佳规模： 6-10 人18主要职责参与迭代任务清单的创建执行为干系人创造价值的工作根据团队的承诺完成所需的各项任务将工作中的各项障碍迅速与Scrum Mas
11、ter 进行沟通全面参与所有的各项会议更新任务状态 自发选择任务 标识任务的完成 标识发现的新的任务与其它团队共同进行工作19Scrum Master不是一个管理者，而是一个教练和推动者 - Scrum团队是一种自发的组织，是自我管理的.Scrum Master的角色通常由项目组的成员担当，组长或者项目经理。Scrum Master 应当是项目中的成员.主要职责:评价过程的健康状况加强过程消除障碍促进过程改进支持团队开发Scrum Master 的主要工作是做决策、消除障碍，保证团队能顺利交付产品20Scrum Master 还有如下责任与其它角色配合.训练团队，提高生产率.培训产品所有者和干
12、系人，确保Scrum流程的执行确保一切工作按照既定的规范来运行.规划并进行必要的改进.推动会议的召开.维护障碍列表维护Scrum过程改进列表优秀的 Scrum Master 应当是专注的,、有决心的、有领导才能.21产品所有者代表投资方的利益，确保交付的产品与期望的一致 （提供更好的投资回报).Product Owner决定产品具有哪些功能.Product Owners的主要责任是创建和维护产品需求清单, 即管理项目的范围.Product Owner不断的把产品需求清单按优先级进行排序 ，使得最重要的功能能优先实现.对于团队来说，只有一个需求集。所有的需求申请都归口到Product Owner
13、管理商业价值（投资回报）Product Owner 还有如下责任:计划项目的发布，什么时间、向什么人等.对每次Sprint的结果进行评审和批准22参与Scrum会议迭代计划会议团队进展跟踪会议迭代评审和回顾会议能够随时回答团队工作中产生的各项和产品/业务相关的问题Product Owner 的角色一般由客户担当，作为服务提供商的公司无法设定优先级.23客户和管理的角色是可选的，需要时才设立客户:是产品的最终用户 通过 Product Owner来设定对产品的期望把当前的业务传达给项目.管理层:公司高级管理层,代表公司在项目中的利益.通过Product Owner来传达公司的利益和优先级（pri
14、orities ）24基本上，产品需求清单是为了实现产品的功能所需要的工作的列表，包括:功能方面的需求; 功能点.非功能方面的需求, 如性能改进.要修改的Bug; 上一版本的已知错误.新技术, 如支持新的操作系统或者平台.问题; 日后的不确定项, 如新的功能.产品需求清单是不断完善的.Product Owner 在项目进行过程中可以随时更新：增加、删除、修改功能，变更优先级等.下一次迭代中要包含较高优先级的需求.产品需求清单也可称为User Stories (用例) ，因为它们能够给产品的用户带来价值.在一次迭代中要能够实现产品需求清单，如果不能全部实现要进行分解. 25Product Own
15、er负责创建最初的产品需求清单，一开始是不完整的.最初的清单应当包含足够的需求.清单应当包含多少需求, 取决于定价模型 (black-box, 更多的计划时间).产品需求清单来源于:客户; 标书, 需求规格说明等.Scrum团队的想法; 增强型新功能等.现有产品的迭代增量; 已知错误, 技术问题等.比较好的做法是Product Owner 、Scrum团队、客户/管理以及其它相关方（如相关的Scrum团队）举行一次或者多次研讨会Scrum Master 或者 Product Owner 来促成会议的召开，必须要有人来做.要有效率、要围绕主题、 沟通良好 、避免不同的假设，承诺并且共通合作，确定
16、优先级.26Scrum团队对产品需求清单的每一项的规模提供初步的估计，通常采用事件点作为单位Story Points (模糊的).也可采用人天或者人小时作为单位，但容易混淆： a) 实际的规模 b) 时间的单位.精确的估计值可以在Sprint 规划时给出, 当前阶段没有足够的信息.规模的相对值才有意义.这个估计值有助于确定优先级; 所需时间所需时间团队速度团队速度产品规模产品规模27优先级是产品需求清单中的主要问题.优先级不但反映了客户的价值也反映了风险.产品所有者-PO 设定优先级.清单中的每一项的优先级是唯一的, 但可以对它们进行分类优先级可以在项目的任何时候进行更改; 如新的重要的功能可
17、以直接给较高的优先级.确定优先级考虑：价值风险依赖关系28PriorityID, like in any requirements documentDescription of the item = User StoryThese will likely endup in the first Sprint29在 Scrum中,不是 每个Sprints 都要发布一个版本.迭代的结果主要是要实现功能的演示, 不一定就是发布的版本.版本发布计划决定了每次迭代应当包含产品需求清单的哪些功能.根据现有的信息制定的项目总体的长期的计划.根据产品需求清单和团队的进度来决定 (实施的范围/迭代, e.g. i
18、n Story Points).Scrum团队参与版本发布计划的制定; 架构、风险、依赖性决定了可行的实现顺序.版本发布计划很大程度上依赖于客户的时间表和发布周期，即什么时候客户的产品需要包含我们的模块（交付物）.版本发布计划不是一成不变的;每个迭代结束后都可以更改.30当迭代任务清单上的任务都完成时，变为“已完成”状态定义“已完成”的含义是非常重要的, 例如:如何记录软件的变化.使用什么样的代码分析工具 ，发现的问题应当如何处理.进行了什么样的测试, 结果是如何记录的, 通过标准（如覆盖率、修正的错误）是什么.定义“已完成”意味着定义质量上的需求.“已完成”是0/1变量：完成或者未完成. 所
19、有的任务（task)都完成了迭代任务才算完成.在第一个迭代开始之前应该定义好，因为它会影响工作量, 而且必须文档化，这样团队和产品所有者的理解是一致的.31完成的范围随着团队的成熟程度会逐渐发生变化计划计划分析分析架构架构设计设计开发开发测试测试性能指标性能指标验收验收试运行试运行代码评审代码评审支持文档支持文档集成集成用户文档用户文档潜在的潜在的可交付的软件可交付的软件32完成的定义 遵循编码规范能在模拟器上演示 使用PCLint 进行静态代码分析具有EUnit 测试套件的通过率 和执行率. 或者使用结对编程，或者进行代码走查33迭代任务清单规划 的主要目的是从产品任务清单中挑选高优先级的任
20、务包含在下一次迭代中，即确定迭代的范围.至于能够包含多少产品任务清单中的任务取决于Scum团队能够承诺完成多少.承诺总是来自于内部，不能从外部强加.迭代不应当有空闲时间, 因此规划迭代范围时要保证工作量是稳定的 (进度是持续的速度).依赖多个因素; 团队的能力, 技术的成熟度, 当前迭代增量的情况等.迭代的范围在迭代任务清单中描述; 团队设定优先级.产品所有者 PO 定义每个迭代的任务说明（mission statement），目标(sprint goal)，使迭代更具有针对性，如. “实现一个可扩展的列表控件，其项目是可以选择的”34Sprint PlanningMeetingProduct
21、 BacklogTeam CapabilitiesBusiness ConditionsTechnologyCurrent ProductSprint BacklogProduct OwnerScrum TeamManagementCustomersSprint Goal35迭代任务清单规划 是“铁三角”法则的另一个例子在Scrum, 边界是一个变量，因为:资源 (Scrum团队) 是确定的.进度表（迭代的时间）是不能变的.质量是无法协商的团队在一个迭代内能完成的任务，可以用团队进度来衡量 (Story Points / Sprint).如果可能的话利用同一个团队上个迭代的进度, “yeste
22、rdays 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 36召开迭代任务清单规划会议的目的是确
23、定迭代的边界.时间是限定的, 最长时间是一个工作日 (对持续4个星期的迭代, 迭代持续的时间越短，用在规划上的时间也应该越少. 由 Scrum Master推动会议.由于会议时间有限，Product Owner 和Scrum 团队都应该事前进行准备.前提: 产品需求清单是有效的（valid）; 最新的, 标注了优先级并且表述清楚.规划会议要解决两个问题:下次迭代要做什么. 确定迭代的目标，包含产品需求清单上高优先级的功能. 给Bug修改留一定的余地怎么样实现下次增量所需要的功能. 改进设计以实现产品需求清单上的功能.37产品所有者向团队介绍起草的产品需求清单和迭代目标.产品所有者传达迭代的起止
24、日期.Scrum 团队 从产品需求清单中选取高优先级的功能作为迭代的任务，如果有必要，更新其规模估计.Scrum 团队改进架构和设计以便能够实现提出的产品需求.Scrum团队把 产品需求清单的每一项划分成小的任务，并估算每个任务要花费的小时数.“扑克规划”方法是估算工作量的有效方法.Scrum 团队决定一个迭代中能够实现产品需求清单的多少功能产品所有者和Scrum团队明确了各自要承担的义务.38Personsworking onthe taskDescription of the taskEffort estimateTask blockedby an impedimentSprint goa
25、lMeets the definition of done39执行迭代任务清单意味着 团队在迭代期间自行开发.团队清楚要达到什么的目标以及怎样达到目标.每人每一时间只有一个任务团队是自发组织的；成员自己挑选任务, Scrum Master 提供指导并清除障碍.不能从外部改变迭代的范围或者迭代的周期.为了达到迭代的目标，团队可以增加、删除任务或者改变其优先次序. 如果要重新设定迭代的范围时需要产品所有者的配合. 迭代周期短，意味着工期紧; 应该把重点放在剩余的工作和风险的消除，要区分任务的优先级，重要的事情应当先做.迭代应当达到项目的质量要求 (definition of “done”);没有独
26、立的测试阶段.40Scrum 注重成果，它关心的是要花多少时间达到目标，而不是已经花费的时间;.团队能否在既定的时间达到迭代的目标,可以查看要完成产品需求清单的功能所剩余的工作Remaining work = Estimate to Complete (ETC).描述剩余工作量和时间关系的图表称为Sprint Burndown图, 是Scrum中非常重要的控制方法(control measure).给Scrum团队和产品所有者提供直观的信息.术语 burndown 表明Scrum团队在迭代过程中消耗剩余工作的能力; 迭代结束时其值为0.每个任务 （ task ）的工作量由Scrum团队来估计.
27、每天都要进行估计，以便进行跟踪.可以使用电子表格或者专门的工具（如 ScrumWorks ）41Ideal 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 par
28、ticular day.Initial estimate (752 h)In the beginning of theSprint 4243A 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 you
29、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.44例会最长15分钟，在整个迭代过程中每天的同一时间召开.团队成员 之间交流信息.了解项目的真实的进展情况交流风险和存在的问题.面对面的会议加强了承诺. Scrum Master 负责整个会议 (会议地点,邀请等).其他人可以参与, 但只允许Scrum Master 和 Scrum 团队成员讲话 (小鸡和猪).例会之前团
30、队要更新工作量估计，使进度表保持最新.45为使会议简短而富有成效，要遵循严格的规程每个成员向其他人汇报以下内容:上次会议以后所做的工作?下次会议之前要做的工作?工作中是否有什么障碍?如果出现其它的问题（如设计的问题），应当在会议后处理.纪录会议纪要，例如wiki.要养成良好的会议习惯4647基本上，任何阻止团队正常工作的，都可称之为障碍，例如:无法访问信息系统.所需要的信息不能及时提供或者提供的不正确，如界面规格或者其它软件模块不到位或不正确开发环境或者原型系统出现问题其他的任务分配：培训，售前支持缺乏必要的信息或者相应的知识对于团队提出的各项障碍，Scrum Master要以列表形式进行记录
31、，48每个人自我管理、自我组织的团队Scrum Master产品所有者管理层其他相关的干系人Scrum Master 负责确定障碍已经清除，不一定亲自自己清除49某些障碍是浪费部分地完成工作额外的过程额外的功能任务转换等待缺陷清除障碍的过程是团队和组织学习的过程50多问几个“为什么”对于每个标识的障碍或者浪费，问一问“为什么”浪费会存在多问几个“为什么”，找到造成浪费的根本原因51每次迭代不是小的瀑布项目而是，每件事情同时都做一点52在Scrum中，结束正在进行的迭代是一种极端的行为，只有在万不得以的情况下才能这么做.有时候确实需要停下来重新规划，而不是一味的蛮干(banging your h
32、ead against the wall).迭代终止可能由下面的人发起:Scrum团队,如果他们认为达不到目标或者目标不清楚.Scrum Master, 如果迭代没有进展, 或者无法克服某个困难.客户/管理层, 如果目标已经陈旧/过时(目标产品被取消，平台过时)，或者其它的原因 (资源问题等).迭代终止以后, 启动新迭代的计划.导致迭代终止的原因不应该在新的迭代中再次出现.要考虑到合同方面的问题，如时间表的变更等.53迭代评审，在迭代结束后进行，展示迭代的成果 (功能运行).确保成果与预期的一致，收集反馈为项目提供一个参考点，根据目前的位置计划下一期的旅程为下次迭代提供输入（改正、修改、新的想
33、法可以由产品所有者添加到产品需求清单.与其它 Scrum 会议一样, Scrum Master 主持迭代评审会议, Scrum 团队负责演示.参加会议的其他人包括: 产品所有者Product Owner (必须参加) 、客户、 管理人员, 以及其它感兴趣的人, 例如其他Scrum团队 (注意保密协议的要求).评审会议的时间是固定的: 最长4个小时.评审会议应当是非正式的、创造性的，不用幻灯片等正式的东西.54在评审会议召开之前，团队要做好准备:有组织、有效地进行演示，不要超过4个小时.谁来演示，演示什么，怎样演示?计划准备的时间不要超过一个小时.迭代评审流程的一个例子:Scrum Master
34、 介绍本次迭代的总体情况. 目标和清单 vs. 实际的结果, 如果存在差距，原因是什么.Scrum 团队简要介绍所 涉及的技术问题，如架构及其变更.Scrum 团队演示已经实现的功能: 演示并进行功能说明 在场的人能够亲自尝试使用不同的功能.Scrum Master 推动自由讨论，集思广益.迭代评审应当是互动的; 有问题提出, 问题解答，并欢迎提出想法和建议. 55产品所有者根据评审的结果可能采取如下行动:更新产品需求清单，重新设定优先级: 包含没有按计划实现的功能 (进度比预期的要慢, 任务未完成). 不在计划中当却已经实现的功能 (进度比预期的快). 迭代评审中出现的新的想法. 与 Scr
35、um Master 一起解决团队的变动问题. 要求把演示的功能，或者把上次迭代的功能，作为一个版本发布给客户. 决定项目不再持续下去，不再进行迭代; 认为产品已完备. 要求把产品需求清单授权给另外的团队来一起工作. 56回顾的目的是评价本次迭代并酝酿改进，使得下一个迭代进行的更好.类似于项目的最终评审，但经常举行.障碍列表具有很好的参考价值!Scrum Master主持召开, 持续半天, Scrum团队参加 (产品所有者也可参加).简单流程:Scrum Master 总结本次迭代; 迭代任务清单, 重要的事情和决策, 预期的/实际进度.每个组员陈述迭代中那些方法进行的较好、哪些需要改进, Sc
36、rum Master 进行记录.对重要的问题计划相应的措施：团队自己解决, 或者提交给公司的管理层.5758尽管名字有好笑, 但却非常可靠和有效.可以来估算产品需求清单中每项的规模（规模估算: 用例点story point）以及迭代任务清单中任务的估计 (工作量估算： 人时).Scrum Master推动活动的进行, 一个以上的专家参与估算, 而且最好是项目团队中的人.估算时使用卡片：写有一系列的离散数据，如0, 1, 2, 3, 5, 8, 13, ? (无法估计).59前提条件: 提前准备好要估算的任务、User Stories等; 迭代任务清单和产品需求清单都已经起草好.对某个任务最有经
37、验的开发者做一个简短的概述. 可以通过简短的讨论澄清任务的具体含义，找出存在的风险以及不确定性. 各自对任务进行估计，所有的人将写有各自估计数据的扑克/卡片扣上。 (单位事先进行约定：工时、事件点). 大家同时把扑克/卡片翻过来. 如果扑克/卡片上的数差距比较明显 (如一个13，2个5，一个1), 就要讨论一下为什么会出现这么大的差距，估计值所基于的假定要进行澄清.如果差距较小 (如三个8两个5) ，主持人帮助确定最终的估值.对于不确定性，估算数据中可以多包含一些余量. 不断的重复该过程直到达成一致.将这些估值记录到相应的文档中 (产品需求清单, 迭代任务清单). 60为什么使用离散的数字?比
38、使用任意数字更加容易进行估算.在整个项目中或者迭代中, 每个人估计值的错误会相互抵消掉.对每个任务, 16 小时是上限, 不确定性会随着规模的增加而增加.为什么要有 “?”.将较大的任务进行分解，帮助更加精确的估计同时减少不确定性.为什么要 “讨论并重复”?弄清不同的假设 (利用重用代码或者重新编码) 和可能的误解 更为可靠的估计.对于那些偏离平均值的估计，即使由有经验的人给出的，也必须要有充分的理由.61在一个小时之内编写一个三只小猪的连环画册使用Scrum 实践自组织团队迭代每日Scrum会议产品需求清单迭代任务清单625 分钟: 迭代目标团队与产品所有者共同协作，从产品需求列表中选择本次
39、迭代要完成的项目5 分钟: 迭代任务清单团队从所选择的产品需求列表中产生任务10 分钟: 第一天团队完成任务和产品需求列表中的项目产品所有者负责回答问题5 分钟: “每日”“Scrum会议每个人回答三个问题10 分钟: 第二天团队继续完成任务和产品需求列表中的项目产品所有者负责回答问题5 分钟: “每日”“Scrum会议每个人回答三个问题10 分钟: 第三天团队完成产品的一个版本产品所有者负责回答问题每组5 分钟: 演示团队向产品所有者展示完成的连环画册63展示基本的故事用铅笔画展示的故事每页图画配有说明给出写有标题的封面故事用9页进行说明展示版权信息添加色彩广告教小孩数数1，2，3寓教于乐：
40、坚固的重要性封皮吸引人硬的封皮3D效果的卡通形象展示所有的故事内容产品所有者- Product Owner充分考虑市场情况，对产品进行规划并进行简要地说明规划当前该产品如何占有更多的市场份额规划今后该产品的发展前景Scrum团队根据产品所有者的产品规划进行开发64什么是测试驱动？一种能够支持Scrum的敏捷实践方法，开发满足DoD的软件首先创建测试用例，然后开发软件通过测试(在开发代码前，首先编写测试代码)一种设计软件的方法，而不仅仅是一种测试方法所创建的测试用例用来指导和约束项目中的各项工作，对未来的各项工作提供一个安全的保护不需要测试的工作不需要完成所创建的测试用例通常替代详细的业务和技术
41、需求定测试也有效地驱动设计，使设计更加趋向于可行的设计通常情况下需要自动测试的支持 (EUnit, JUnit etc.).对于UI软件应用TDD方法有一定的困难65测试用例的作用：确定所要完成的工作沟通工具产生一致的结果对软件开发提供一个安全的保障66反馈检查接受结对编程结对编程单体测试单体测试阶段发布阶段发布每日每日Scrum会议会议迭代演示迭代演示67基本原则: 不能只挑自己喜欢的，不管其它的Scrum非常简单，为了有效地发挥作用，应当具备:所有的角色.所有的实践.所有的产品.Scrum 可以进行裁剪, 但应当明白裁剪对工程的影响 需要经验和仔细考虑.686到10人在同一房间进行工作时，
42、Scrum能够发挥最大效用.Scrum也可应用在大型的跨地域的项目.一些指导原则:将大的项目分成多个团队，每个团队6到10人，有各自的Scrum Master. 对跨地域的项目，尽量不要把一个Scrum团队分到多个地方，一个Scrum团队就在一个地方，有自己的Scrum Master.但是，如果团队的跨地域是不可避免的，可以使用网络工具远程召开Scrum例会.划分团队时，团队之间应该有一个“自然界面” ，如为避免混乱，不同的团队负责产品的不同部分.对于整个项目/产品：一个产品/项目只能有一个产品所有者和产品需求清单.团队之间的协调利用Scrum of Scrums方法69Scrum Team6
43、-10 personsScrum Team6-10 personsScrum Team6-10 personsScrum of Scrums“Scrum on Team Level”1-3 times / week, or on demandEach team representedby dedicated persons (only one if no issues to escalate)Project divided to Scrum teams based on project size or geographical locationScrum Teams have Daily Sc
44、rum meetings, Scrum of Scrums can be held less frequently.Tele and video conferencing utilized as needed.70Scrum 不鼓励固定价格的项目每次迭代时进行项目预算, 产品需求清单可以根据当前的优先级进行调整.某些项目中, 客户需要我们对整个项目给一个报价或者预算.价格固定限制了灵活性 (对变化的响应):如果价格和进度是固定的，那么整个项目的范围也是固定的 (PB).必须对项目所有的迭代都进行详细的计划和规模估计.变更项目的范围，以及随之而来的预算/进度的变更需要提交CR. 当然可以改变产品
45、需求清单的优先级，或者不改变工作量前提下把其中的某一项换成另一项.仍然可以使用Scrum，并从中获益71Tasks notstartedTasks inprogressTaskscompleted (done)PrioritySprint GoalSprint Burndown ChartTasks:-Description-Responsible person-Work remaining72敏捷是拯救任何项目的银弹.敏捷方法只有运用得当才有效果.敏捷意味着 ad-hoc hacking ，不需要任何文档.敏捷是有严格要求的，也是面向质量的根据沟通的需要产生相应的文档.敏捷只是开发者的问题基
46、本的开发方法与传统相比有显著不同, 影响项目的各个方面: 合同, 角色, 定价模型, 项目管理等.采用敏捷方法的开发组/项目不需要制定计划敏捷项目需要经常制定计划，但是不需要试图超前制定项目计划，通常这也是不可能的.敏捷项目的范围可以随时改变.变更可以等到下一次迭代开始，当前正在进行中的迭代不能变更只对小项目适用在中型和大型的项目中一样取得了成功7374Jinghua LiQuality ManagerTietoEnator CorporationT&M MDR MID75主要包含三个阶段：产品定义(计划)：进行迭代所需要的项目准备、项目计划和技术分析迭代开发(执行)：在固定时间的迭代中实现需
47、求（产品需求清单中的项目）结束：准备最终的发布，结束项目(ramp down)76通常称为“Sprint Zero” 也使用Scrum的实践，例如每日会议目标：进行项目准备（just enough）。在计划阶段进行的计划和技术分析是为了使迭代以一种受控的方式进行所需的活动和详细程度取决于软件的复杂程度、质量要求、项目规模、项目设置和重用的要求等如果没有适当的计划就进入首次迭代会有很大的风险通常情况下由核心团队完成，由专家进行项目的计划项目在正式迭代开始之前全力进行准备(ramped up )77定义产品需求清单项目需求及其验收准则，初始的规模估计（ Story Points ）及其优先级迭代的
48、长度，每个产品需求清单项目所处的迭代，发布计划由产品负责人负责进行起草，并和Scrum团队共同进行讨论重用计划将要在本项目中重用的内容：第三方软件或OSS等计划在本项目中开发，可以为其他项目所重用的内容 所需的可行性分析（对于OSS来说，必须进行）对于工作量/规模估算的影响分析（需要包含研究、测试用例的编写、测试和文档化的工作）78架构设计根据实际需要的充分程度，进行产品的架构设计- on sufficient level 计划的需求如何实现 通过技术研究和技术分析，更好地进行项目计划， 根据要求的指南和模版进行架构设计其他需要考虑的问题，包括： 重要的架构需求 系统分解（模块/界面） 各个部
49、分的特性及其之间的相互关联关系 非功能特性（性能、本地化的要求等） 设计指南79进行UI概念设计，即产品UI设计的基本方法UI风格 主画面（Main views. ）交互风格UI 设计指南验证架构如果有时间，已经计划的架构应该通过基本的运行框架验证 验证架构是否满足已计划的特征、性能测试的要求和扩展需求等80计划方法制订完成的定义，即质量需求 考虑来自客户需求，如果没有来自客户的需求，要首先制定可行性建议 DoD对于迭代计划有重大的影响根据完成的定义，计划所需的工具和方法，例如：评审，静态/动态代码分析，测试等计划需要交付的工作产品和文档建立需要的工具和系统SCM，测试管理工具，BUG管理工具
50、和文档管理工具等81根据定义的Scrum方法进行迭代计划迭代目标：本地迭代的任务说明（ mission statement ）迭代任务清单，以及每个任务的工作量迭代执行：按照优先级的顺序执行迭代任务清单中的任务根据完成的定义，软件的每一变更都是已设计的，已实现的、已验证的和已文档化的。没有单独的测试阶段根据实际需要执行测试驱动的开发，自动测试和持续集成同一部分代码也许会持续发生变更-再工程随着项目的扩展，测试的工作量也越来越大根据计划进行测试和bug报告82验收测试：通常情况下，在项目/产品交付后，客户需要进行30天的验收测试根据实际的项目计划进行验收测试回归测试与客户进行项目/产品交接支持和
