《Scrum敏捷项目管理课件PPT》由会员分享，可在线阅读，更多相关《Scrum敏捷项目管理课件PPT（74页珍藏版）》请在金锄头文库上搜索。
1、Scrum敏捷项目管理1目录敏捷的背景与动机敏捷宣言及原则敏捷方法是什么？敏捷方法的实践 Scrum的角色 Scrum流程和工作产品 Scrum应用总结2敏捷的背景与动机软件危机及软件工程的出现速度是企业竞争致胜的关键因素，软件项目的最大挑战在于一方面要应付变动中的需求一方面要在紧缩的时程内完成项目传统的软件工程难以满足这些要求所以软件团队除了在技术上必须日益精进，更需要运用有效的开发流程，以确保团队能够发挥综效。这正是Agile Process (敏捷的软件开发流程)于近年来兴起的主要原因。3软件项目的复杂性横轴代表需求的复杂度纵轴表示技术的复杂度还有人力资源的复杂度4解决复杂性问题需要采用
2、经验式方式解决问题的两种方式：预定义过程控制（富士康流水线生产）经验性过程控制（摸着石头过河）如果复杂度超过预定义方式的能力范围，应该采用经验性方式经验性方式的三大支柱：可见性、检查及适应5他山之石互联网时代的出版模式作者最开始的时候并没有想出一本书，而只是把多年的积累梳理出来写成了博客，凭借博客的成功最后得到了出版商和纸版读者的认可。在写成本书的过程中，作者是渐进式的进行的，每写完一个章节，放到博客上去征求读者的反馈，很多反馈意见在后面的章节或修订中及时地体现出来，这样就形成了与读者之间的良好反馈，在出版之前就锁定了大量的读者。这就是敏捷开发提倡的“增量迭代、及时交付”的思想。这种模式能最大
3、程度地不偏离客户需求的本质。精益制造消除浪费、关注流程、建立无间断流程以快速应变 、降低库存 、一次做对、基于顾客需求的拉动生产 、标准化与工作创新 、尊重员工，给员工授权 等6目录敏捷的背景与动机敏捷宣言及原则敏捷宣言及原则敏捷方法是什么？敏捷方法的实践 Scrum的角色 Scrum流程和工作产品 Scrum应用总结7敏捷的历史敏捷软件开发又称敏捷开发，从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。2001年初，因观察到许多的软件团队身陷不断扩大的流程之中的困境，一群业界专家聚集在一起，勾勒出一些能让软件团队迅速工作，以及响应变化的价值
4、观和原则。他们自称为Agile Alliance。之后的七个月里，他们创造具有价值的声明，也就是敏捷软件的开发宣言。十五人中包括：大名鼎鼎的Kent Beck（XP,TDD的创始人,Junit的创始人之一）、Ward Cunningham（Wiki概念的发明者）、Martin Fowler（企业应用架构模式作者）、Robert C. Martin、Ken Schwaber 8敏捷价值观之敏捷宣言9敏捷开发的核心思想是敏捷开发的核心思想是：以人为本，适应变化以人为本，适应变化。敏捷价值观之敏捷宣言-1个体和交互胜过过程和工具人是软件项目获得成功最为重要的因素合作、沟通能力以及交互能力比单纯的软件
5、编程能力和工具更为重要方法和工具是死的，人是活的，人要是太“面”或者协作不好，再强大的方法和工具都是白扯；10敏捷价值观之敏捷宣言-2可以工作的软件胜过面面俱到的文档过多的面面俱到的文档往往比过少的文档更糟软件开发的主要和中心活动是创建可以工作的软件直到迫切需要并且意义重大时，才进行文档编制编制的内部文档应尽量短小并且主题突出11敏捷价值观之敏捷宣言-3客户合作胜过合同谈判客户不可能做到一次性地将他们的需求完整清晰地表述在合同中为开发团队和客户的协同工作方式提供指导的合同才是最好的合同12敏捷价值观之敏捷宣言-4响应变化胜过循环计划变化是软件开发中存在的现实计划必须有足够的灵活性与可塑性短期的
6、迭代的计划比中长期计划更有效.13敏捷开发的12个原则1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。2.即使到了开发的后期，也欢迎改变需求。3.经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好 。4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。5.围绕被激励起来的个人来构建项目。6.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。 14敏捷开发的12个原则7.工作的软件是首要的进度度量标准。8.敏捷过程提倡平稳的开发节奏；发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 9.不断地关注优秀
7、的技能和好的设计会增强敏捷能力。 10.简单化是根本（不做过度设计和预测）。 11.最好的构架、需求和设计出自于自组织的团队。12.每隔一定时间，团队会在如何才能更有效地工作方面进行反思并对自己的行为进行相应调整。 15目录敏捷的背景与动机敏捷宣言及原则敏捷方法是什么？敏捷方法是什么？敏捷方法的实践 Scrum的角色 Scrum流程和工作产品 Scrum应用总结16什么是敏捷方法？敏捷方法是一类软件开发流程的泛称；敏捷方法是相对于传统的瀑布式软件过程提出的；敏捷方法可以用敏捷宣言（4条）、敏捷原则（12条）来概括；敏捷原则通过一系列的敏捷实践来体现出来；敏捷方法有很多种。问题1，请举出你知道的
8、2个以上敏捷方法名字来17敏捷的方法Extreme ProgrammingExtreme Programming (XP)极限编程ScrumScrum Adaptive Software Development (ASD)自适应软件开发Crystal Clear and Other Crystal Methodologies水晶方法Dynamic Systems Development Method (DSDM)动态系统开发方法等18敏捷方法 VS. 瀑布模型瀑布模型固定的、没有弹性的。很困难去达到互动。假如说需求没有完全的被了解，或是可能需要完全地改变项目的需求，瀑布式的model是比较不适
9、合的。敏捷方法完整地开发，每少数几周或是少数几个月里可以测试功能。强调在获得最简短的可执行功能的部分，能够及早给予企业价值。在整个项目的生命周期里，可以持续的改善、增加未来的功能。19敏捷项目管理VS传统项目管理传统项目管理：事先对整个项目进行估计、计划、分析反对变更;变更需要重新估计、重新规划严密的合同来减少风险,如果改变需求要走CR流程.项目作为一个“黑盒子”，对客户与供应商的可视性差.文档和计划驱动的方法.软件交付时间晚,意识到风险的时间晚.WBS,甘特图,关键路径分析敏捷项目管理:对整个项目做一个粗略的估计,每一次迭代都有详细的计划.鼓励变化,客户价值驱动开发.信任和赋予权力;合约使变
10、更变得简单，增加价值.客户和开发人员之间是紧密的连续的合作关系每次迭代都产生可交付的软件专注于交付软件.第一次迭代就可交付能工作的版本，风险发现的早.20敏捷 与CMMI双剑合璧CMMI更加关注于流程，敏捷更加关注于人CMMI自顶向下，敏捷自底向上敏捷并不排斥必要的文档敏捷的很多实践是对CMMI的一种实现，比如sprint计划会议就是PP的实现，每日例会就是在做PMC很多CMMI45级的公司也在应用敏捷，比如说宝信、华为项目级的敏捷实践通过CMMI可以在组织级得以重用21eXtreme ProgrammingXP我们一般称为极限编程，是最轻量级的开发流程。最主要的精神是在客户有系统需求时，给予
11、及时满意的可执行程序，所以最适合需求快速变动的项目。它强调客户所要的是workable的执行码，所以把与撰写程序无关的工作降至最低，并要求客户与开发人员最好以side-by-side的方式一起工作。XP的实践包括：完整团队、计划游戏、客户测试简单设计、结对编程、测试驱动开发改进设计、持续集成、集体代码所有权编码标准、隐喻、可持续的速度22Scrum开发流程.23为什么采用敏捷? 预期的收益 采用敏捷方法得当的话，可以：更加透明;随时跟踪项目的状态和进展情况，及早发现问题和风险 .快速交付,每次迭代都能交付可运行的软件.最高风险和最高优先级的需求，最优先进行开发.改善应对变更能力,减少大量的重计
12、划.改善项目沟通.更好的客户参与,避免错误的假设.总之:提高了生产率;减少“浪费” （不需要的文档，重复工作等） ，项目的每次迭代都有明确的目标.提高客户满意度;短期内产生成效,按预期交付软件,每次迭代结束产生可以运行的软件.改善员工的满意度;团队精神，减少官僚，能够规划和管理自己的工作，减少“恐慌” ，稳定的工作量（可持续的步伐）.24目录敏捷的背景与动机敏捷宣言及原则敏捷方法是什么？敏捷方法的实践敏捷方法的实践 Scrum的角色 Scrum流程和工作产品 Scrum应用总结25敏捷关键实践1增量迭代每个迭代有一个大约为14周的时间框，在SCRUM里称为一次冲刺（超过1个月的详细计划往往偏差
13、很大）每次迭代都应该有明确的目标每次迭代都应该有明确的可演示的工作成果迭代过程中项目团队应该尽量免受打扰迭代可以将项目的压力分解到每个小的阶段，风险也能同时分解26敏捷关键实践2测试驱动开发 TDD什么是测试驱动？首先创建测试用例，然后开发软件通过测试(在开发代码前，首先编写测试代码)一种设计软件的方法，而不仅仅是一种测试方法所创建的测试用例用来指导和约束项目中的各项工作，对未来的各项工作提供一个安全的保护不需要测试的工作不需要完成所创建的测试用例通常替代详细的业务和技术需求定测试也有效地驱动设计，使设计更加趋向于可行的设计通常情况下需要自动测试的支持(EUnit,JUnitetc.).对于U
14、I软件应用TDD方法有一定的困难27敏捷关键实践3持续集成28极限编程称为“每日构建”持续集成一般利用ANT、MAVEN等工具日构建的好处：将集成风险降到最低降低质量风险提升士气日构建可以看做是项目的心跳，冒烟测试就像是听诊器日构建必须至少：成功编译、打包、发布；不含有任何明显的缺陷；通过冒烟测试敏捷关键实践4面对面交流 虽然如今通讯工具花样繁多，但面对面交流在某些场合下仍然是不可替代的；敏捷开发把交流缺失问题考虑在内，要求团队成员彼此直接协作，尽量创造面对面交流的机会；尤其当业务分析师和软件开发人员一起工作的时候，面对面的交流是很重要的。匿名共享需求文档只会打开曲解和误解之门，更不用说书面信
15、息比口头交流还要慢很多。29敏捷方法的其它实践结对编程 每日立会 用户故事团队工作室 频繁发布自组织团队重构30重构改善既有代码的设计MartinFowler提出代码的坏味道MartinFowler和KentBeck列举了22种坏味道：冗余代码、冗长的方法、巨大的类、过多的参数等等重构可以弥补设计的不足简单设计的思想重构与测试驱动的关系TDD是重构的脚手架IDE已经对主要的重构模式提供了自动化支持：Rename,extractmethod,movefield等等简单设计测试用例实现再说（重构回归测试）*31Scrum何时更有效？公司和客户一致认为应当使用敏捷方法，双方都能理解敏捷方法.敏捷方法
16、对需求不完整以及经常变换的项目比较有效.项目可以划分成固定时间间隔的迭代,并且可以冻结正在进行的迭代的范围公司和客户都有能力担当角色尤其是ProductOwner和 ScrumMaster.项目的人员结构能够分成6到10人的团队，最好每个工作地点一个小组.（ScrumofScrums，Scrum的扩展）团队成员能够以自组织的方式工作.项目的合同允许变更.固定价格的项目可以使用敏捷，但应当尽量避免。最好在按时间和材料付费或者按月付费的项目中进行使用、变更项目的范围不需要高级管理层的批准.32问题2，为什么SCRUM团队人员最好在10人以内？目录敏捷的背景与动机敏捷宣言及原则敏捷方法是什么？敏捷方
17、法的实践Scrum的角色的角色 Scrum流程和工作产品 Scrum应用总结33敏捷特别强调人的因素相对于过程与工具，敏捷更强调“人”的因素。诚信是基础没有过程能够对诚信进行有效的约束诚信与否是有效实施敏捷过程的最大限制34Scrum框架.Scrum角色36Scrum角色之Product Owner产品负责人（ProductOwner）的职责如下：确定产品的功能。决定发布的日期和发布内容。为产品的profitabilityoftheproduct(ROI)负责。根据市场价值确定功能优先级。每个Sprint，根据需要调整功能和优先级（每个Sprint开始前调整）。接受或拒绝接受开发团队的工作成果
18、。37Scrum角色之ScrumMaster作为TeamLeader和Productowner紧密地工作在一起，他可以及时地为团队成员提供帮助。他必须:保证团队资源完全可被利用并且全部是高产出的。保证各个角色及职责的良好协作。解决团队开发中的障碍。做为团队和外部的接口，屏蔽外界对团队成员的干扰。保证开发过程按计划进行，组织 DailyScrum,SprintReviewandSprintPlanningmeetings。38Scrum角色之Scrum Team一般情况人数在5-9个左右团队要跨职能（包括开发人员、测试人员、用户界面设计师等）团队成员需要全职。（有些情况例外，比如数据库管理员）在
19、项目向导范围内有权利做任何事情已确保达到Sprint的目标。高度的自我组织能力。向ProductOwner演示产品功能。团队成员构成在sprint内不允许变化。39目录敏捷的背景与动机敏捷宣言及原则敏捷方法是什么？敏捷方法的实践 Scrum的角色 Scrum流程和工作流程和工作产品产品 Scrum应用总结40Scrum 流程41SprintPlanningMeeting:NextSprintGoalSprintBacklogUpdatedProductBacklogDailyScrummeetings:WhatdidyoudoyesterdayWhatwillyoudotoday?Whatob
20、staclesareinyourway?Source:http:/ ScrumSprintRetrospectiveShippableProduct IncrementSprints(冲刺)Scrum的项目过程有一系列的Sprint组成。Sprint的长度一般控制在2-4周。通过固定的周期保持良好的节奏。产品的设计、开发、测试都在Sprint期间完成。Sprint结束时交付可以工作的软件。在Sprint过程中不允许发生变更。42Scrum框架43Scrum仪式之Sprint计划会议.44Scrum仪式之Sprint计划会议.45Scrum仪式之每日Scrum会议(Daily Scrum)每日S
21、crum会议，即团队每日例会，条件允许的话，每天都应该在同样的时间和地点，组织所有成员站立进行。最好是每天早晨开，一般15分钟左右，时间比较短，也有利于团队成员安排好当天的工作。只有团队成员可以在例会上发言，其他人员有兴趣可以参加，但只能旁听，不能发言。（小猪和小鸡的故事）每日Scrum会议由ScrumMaster主持，Scrum团队所有成员轮流回答以下3个问题：昨天我完成了什么工作？今天我打算做什么？我在工作中遇到了什么困难？.46Scrum 任务板(Task Board).47任务板（墙）展现了在Sprint过程中所有要完成的任务。在Sprint过程中我们要不断的更新它。如果某个开发人员想
22、到了一个任务他就可以把这个任务写下来放在任务墙上。 无论每日站会过程中或者之后，如果估计发生了变化，任务会根据变化在任务墙上做相应的调整。通常的任务板是下面这个样子:Scrum仪式之Sprint评审会议Sprint评审会用来演示在这个Sprint中开发的产品功能给ProductOwner.ProductOwner会组织这阶段的会议并且邀请相关的干系人参加。团队展示Sprint中完成的功能一般是通过现场演示的方式展现功能和架构不要太正式不需要PPT一般控制在2个小时团队成员都要参加可以邀请所有人参加.48Scrum仪式之Sprint回顾会议.49团队的定期自我检视，发现什么是好的，什么是不好的。
23、一般控制在15-30分钟每个Sprint都要做全体参加ScrumMaster产品负责人团队可能的客户或其它干系人Sprint回顾会议上，全体成员讨论有哪些好的做法可以启动，哪些不好的做法不能再继续下去了，哪些好的做法要继续发扬。Scrum物件之产品订单(Product Backlog)一个需求的列表。一般情况使用用户故事来表示backlog条目理想情况每个需求项都对产品的客户或用户有价值Backlog条目按照商业价值排列优先级优先级由产品负责人来排列在每个Sprint结束的时候要更新优先级的排列.50Scrum物件之产品订单(Product Backlog).51Scrum物件之冲刺订单(Sp
24、rint Backlog).52Sprint Backlog 示例53PersonsworkingonthetaskDescriptionofthetaskEffortestimateTaskblockedbyanimpedimentSprintgoalMeetsthedefinitionofdoneScrum物件之冲刺订单(Sprint Backlog)管理Sprint的backlog:团队成员自己挑选任务，而不是指派任务对每一个任务，每天要更新剩余的工作量估算每个团队成员都可以修改Sprintbacklog，增加、删除或者修改任务.54Scrum物件之燃尽图(Burn Down Chart
25、)55Idealburndown.Actualburndown.RemainingworkincreasingTasksunderestimatedand/orworkremainingnotupdated.TasksremovedfromtheSprintBacklogtomeetSprintGoalfasterdecline.SumofremainingworkhforalltasksintheSprintBacklogonaparticularday.Initialestimate(752h)InthebeginningoftheSprint扩展Scrum一般情况一个团队的人数控制在5-
26、9人大型项目可以采用多团队，通过teamofteams来扩展Scrum。影响扩展的因素团队规模项目类型项目周期团队分布Scrum曾被用于超过1000人团队规模的项目。 .56Scrum Of Scrums.57Scrum项目之估计Scrum团队对产品需求清单的每一项的规模提供初步的估计，通常采用事件点作为单位StoryPoints(模糊的).也可采用人天或者人小时作为单位，但容易混淆： a)实际的规模 b)时间的单位.精确的估计值可以在Sprint规划时给出,当前阶段没有足够的信息.规模的相对值才有意义.这个估计值有助于确定优先级;可以采用估算扑克58所需时间所需时间团队速度团队速度产品规模产
27、品规模完成的定义 当迭代任务清单上的任务都完成时，变为“已完成”状态定义“已完成”的含义是非常重要的,例如:如何记录软件的变化.使用什么样的代码分析工具，发现的问题应当如何处理.进行了什么样的测试,结果是如何记录的,通过标准（如覆盖率、修正的错误）是什么.定义“已完成”意味着定义质量上的需求.“已完成”是0/1变量：完成或者未完成.所有的任务（task)都完成了迭代任务才算完成.在第一个迭代开始之前应该定义好，因为它会影响工作量,而且必须文档化，这样团队和产品所有者的理解是一致的.59完成的定义 - Example完成的定义遵循编码规范能在模拟器上演示使用PCLint进行静态代码分析具有EUn
28、it测试套件的通过率 和执行率.或者使用结对编程，或者进行代码走查60障碍基本上，任何阻止团队正常工作的，都可称之为障碍，例如:无法访问信息系统.所需要的信息不能及时提供或者提供的不正确，如界面规格或者其它软件模块不到位或不正确开发环境或者原型系统出现问题其他的任务分配：培训，售前支持缺乏必要的信息或者相应的知识对于团队提出的各项障碍，ScrumMaster要以列表形式进行记录，61谁来清除障碍？每个人自我管理、自我组织的团队ScrumMaster产品所有者管理层其他相关的干系人ScrumMaster负责确定障碍已经清除，不一定亲自自己清除62清除障碍某些障碍是浪费部分地完成工作额外的过程额外
29、的功能任务转换等待缺陷清除障碍的过程是团队和组织学习的过程63浪费产生的原因多问几个“为什么”对于每个标识的障碍或者浪费，问一问“为什么”浪费会存在多问几个“为什么”，找到造成浪费的根本原因64目录敏捷的背景与动机敏捷宣言及原则敏捷方法是什么？敏捷方法的实践 Scrum的角色 Scrum流程和工作产品 Scrum应用应用总结65SCRUM实践研发部2009年开始在几个项目当中进行了SCRUM项目管理的尝试：营销综合停电系统开发FLEX-ADP开发海颐OA项目等.66SCRUM看板.67SCRUM燃尽图.68SCRUM带来的改善项目的计划性更强了，将项目按SPRINT进行分解，每个SPRINT要
30、进行计划和总结，每天也有立会来进行简短的总结和计划；引入SCRUM以后，项目团队的沟通比以往更有效，项目看板为项目团队沟通提供了一个统一的项目视图，每日立会是项目团队沟通的有效通道；项目的阶段性比以前更明确，通过SPRINT将项目划分成阶段，通过SPRINT演示等活动将项目整体的压力分解到每个SPRINT，这样可以有效降低项目的整体风险。.69目录敏捷的背景与动机敏捷宣言及原则敏捷方法是什么？敏捷方法的实践 Scrum的角色 Scrum流程和工作产品 Scrum应用总结总结70一些常见的误解敏捷是拯救任何项目的银弹.敏捷方法只有运用得当才有效果.敏捷意味着 ad-hochacking，不需要任
31、何文档.敏捷是有严格要求的，也是面向质量的根据沟通的需要产生相应的文档.敏捷只是开发者的问题基本的开发方法与传统相比有显著不同,影响项目的各个方面:合同,角色,定价模型,项目管理等.采用敏捷方法的开发组/项目不需要制定计划敏捷项目需要经常制定计划，但是不需要试图超前制定项目计划，通常这也是不可能的.敏捷项目的范围可以随时改变.变更可以等到下一次迭代开始，当前正在进行中的迭代不能变更只对小项目适用在中型和大型的项目中一样取得了成功71总结Agile Software Development是软件开发所强调的一个精神，而不是一个方法。遵循Agile Alliance所提的四个价值观与12个原则。最
32、常见的开发方式XPSCRUM敏捷开发过程是一个艰苦的过程，重在实践即使非敏捷的项目中也可以应用敏捷的实践经验CMMI应该与敏捷实现融合，双剑合璧问题3，在SCRUM中能够直观展现冲刺的进度的图形是什么图？72延伸学习原书名： Agile Project Management with Scrum原出版社： MicrosoftPress作者： (美美)Ken Schwaber作译者介绍译者： 李国彪 丛书名： 微软技术丛书微软技术丛书 出版社：清华大学出版社 ISBN：978730216403673硝烟中的硝烟中的Scrum和和XP我们如何实施我们如何实施Scrum原书名： Scrum and XP from the Trenches 原出版社： L 作者： (瑞典瑞典)Henrik Kniberg 译者： 李剑 出版社：清华大学出版社 ISBN：9787302243335 上架时间：2011-1-17 出版日期：2011 年1月 .74
