敏捷开发--Scrum课件.pptx

注意：要更改此幻灯片上的图片，请选择图片并将其删除。然后在占位符中单击图片图标以便插入自己的图片。敏捷开发-ScrumAdermon2019.3目录基本概念Scrum框架Scrum开发流程Scrum关键实践Scrum敏捷开发总结Scrum起源英式橄榄球中的术语1986年，竹内弘高和野中郁次郎在NewProductDevelopmentGame文章首次提到将Scrum应用与产品开发1993年首次在Easel公司定义了用于了软件开发行业的Scrum流程，并开始实施。2019年敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷方法。2019年KenSchwaber和MikeCohn共同创办了Scrum联盟。Scrum框架Scrum角色ProductOwner（PO）确定产品的功能(UserStory)决定发布的日期和发布内容为产品的profitabilityoftheproduct(ROI)负责根据市场价值确定功能优先级每个Sprint，根据需要调整功能和优先级（每个Sprint开始前调整）接受或拒绝接受开发团队的工作成果Scrum角色ScrumMaster(SM)保证团队资源完全可被利用并且全部是高产出的保证各个角色及职责的良好协作解决团队开发中的障碍做为团队和外部的接口，屏蔽外界对团队成员的干扰保证开发过程按计划进行组织DailyScrumMeeting组织SprintReviewandSprintPlanningmeetingsScrum角色ScrumTeam(Team)在项目向导范围内有权利做任何事情以确保达到Sprint的目标高度的自我组织能力向ProductOwner演示产品功能团队成员构成在sprint内不允许变化团队包括开发人员、测试人员、用户界面设计师等Scrum物件看板、燃尽图(BurnDownChart)Scrum物件看板示例1Scrum物件看板示例2Scrum物件看板示例3Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示DemoScrum开发模型Daily Scrum meetings:What did you do yesterdayWhat will you do today?What obstacles are in your way?Sprint Planning Meeting:Next Sprint GoalSprint BacklogUpdated Product BacklogScrum开发模型(简易模型)Sprint物件产品订单(ProductBacklog)一个需求的列表使用用户故事(UserStory)来表示backlog条目每个需求项都对产品的客户或用户有价值Backlog条目按照商业价值排列优先级优先级由产品负责人(PO)来排列在每个Sprint结束的时候要更新优先级的排列用户故事(UserStory)作为一个XXX(角色)，我想。(实现的功能)，以便于。(商业价值)Sprint物件产品Backlog示例做什么APP？做一个出行工具？做一个聊天软件？做一款点餐软件？做一款新闻软件？。你决定！你决定！你决定！你决定！Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示DemoScrum角色汇总Scrum仪式-Sprint计划会议(PlanningMeeting)Scrum仪式-Sprint计划会议(PlanningMeeting)冲刺(Sprints)Scrum的项目过程有一系列的Sprint组成Sprint的长度一般控制在2-4周通过固定的周期保持良好的节奏产品的设计、开发、测试都在Sprint期间完成Sprint结束时交付可以工作的软件在Sprint过程中不允许发生变更Sprint物件冲刺订单(SprintBacklog)团队成员自己挑选任务，而不是指派任务对每一个任务，每天要更新剩余的工作量估算每个团队成员都可以修改Sprintbacklog，增加、删除或者修改任务Sprint物件SprintBacklog示例1Sprint物件SprintBacklog示例2Scrum时间估算-估算扑克的使用方法每个团队成员拿到一组卡片产品负责人或者一名团队成员扮演阅读者的角色，他负责阅读需要估算产品Backlog的条目，并且询问大家是否有疑问团队讨论这个条目当团队理解了这个条目之后，每个团队成员按照自己的想法给出估算结果，并且选择对应的扑克出牌所有人都出牌之后，阅读者向大家确认是否都已经确定估算结果团队评估不同的估算结果，最终团队需要达成一致开始估算下一个条目Sprint物件BurnDownChart示例1Sprint物件BurnDownChart示例2Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示DemoScrum仪式每日立会(DailyMeeting)一般10至15分钟每天都在同样的时间和地点只有团队成员可以在例会上发言其他人员有兴趣可以参加，但只能旁听，不能发言由ScrumMaster主持三个问题：昨天我完成了什么工作？今天我打算做什么？我在工作中遇到了什么困难？“完成”的定义当迭代任务清单上的任务都完成时，变为“已完成”状态“已完成”是0/1变量：完成或者未完成.所有的任务（task)都完成了迭代任务才算完成在第一个迭代开始之前应该定义好，因为它会影响工作量,而且必须文档化，这样团队和产品所有者的理解是一致的承承承承诺诺诺诺！CommitmentCommitmentCommitmentCommitment！Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示DemoScrum敏捷开发关键实践1增量迭代每个迭代有一个大约为14周的时间框，在SCRUM里称为一次冲刺每次迭代都应该有明确的目标每次迭代都应该有明确的可演示的工作成果迭代过程中项目团队应该尽量免受打扰迭代可以将项目的压力分解到每个小的阶段，风险也能同时分解Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示DemoScrum敏捷开发关键实践2测试驱动开发TDD什么是测试驱动？一种设计软件的方法，而不仅仅是一种测试方法所创建的测试用例用来指导和约束项目中的各项工作，对未来的各项工作提供一个安全的保护不需要测试的工作不需要完成TDD有效地驱动设计，使设计更加趋向于可行的设计通常情况下需要自动测试的支持(EUnit,JUnitetc.)对于UI软件应用TDD方法有一定的困难Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示DemoScrum仪式-Sprint评审会议(ReviewMeeting)团队给ProductOwner演示在这个Sprint中开发的产品功能ProductOwner会组织这阶段的会议并且邀请相关的干系人参加通过现场演示的方式展现功能和架构非正式：不需要PPT、一般控制在2个小时团队成员都要参加Scrum仪式Sprint回顾会议(RetrospectiveMeeting)团队的定期自我检视，发现什么是好的，什么是不好的一般控制在15-30分钟每个Sprint结束都要做全体参加ProductOwnerScrumMasterTeam可能的客户或其它干系人Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示Demo猪与鸡的故事Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示DemoScrumofScrums谁来清除障碍？每个人自我管理、自我组织的团队ScrumMaster产品所有者管理层其他相关的干系人ScrumMaster确定障碍已经清除不一定亲自自己清除Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示DemoScrum敏捷开发关键实践3持续集成持续集成一般利用ANT、MAVEN、Jenkins等工具日构建的好处将集成风险降到最低降低质量风险提升士气每日构建可以看做是项目的心跳，冒烟测试就像是听诊器日构建必须至少：成功编译、打包、发布；不含有任何明显的缺陷；通过冒烟测试Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示DemoScrum敏捷开发关键实践4面对面交流敏捷开发要求团队成员彼此直接协作，尽量创造面对面交流的机会尤其当业务分析师和软件开发人员一起工作的时候，面对面的交流是很重要的面对面交流可以打开曲解和误解之门书面信息比口头交流还要慢很多Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示DemoScrum框架为什么敏捷?更加透明;随时跟踪项目的状态和进展情况，及早发现问题和风险快速交付,每次迭代都能交付可运行的软件最高风险和最高优先级的需求，最优先进行开发改善应对变更能力,减少大量的重计划改善项目沟通更好的客户参与,避免错误的假设理想与现实瀑布模型的主要缺陷程序的维护成本越来越高团队氛围压抑（感受不到激情）不方便做需求变更（引起客户不满）敏捷方法VS.瀑布模型敏捷方法完整地开发，每少数几周或是少数几个月里可以测试功能强调在获得最简短的可执行功能的部分，能够及早给予企业价值在整个项目的生命周期里，可以持续的改善、增加未来的功能瀑布模型固定的、没有弹性的很困难去达到互动假如说需求没有完全的被了解，或是可能需要完全地改变项目的需求，瀑布式的model是比较不适合的敏捷项目管理VS.传统项目管理传统项目管理目管理敏捷敏捷项目管理目管理事先对整个项目进行估计、计划、分析对整个项目做一个粗略的估计,每一次迭代都有详细的计划反对变更;变更需要重新估计、重新规划鼓励变化,客户价值驱动开发严密的合同来减少风险,如果改变需求要走CR流程信任和赋予权力;合约使变更变得简单，增加价值项目作为一个“黑盒子”，对客户与供应商的可视性差客户和开发人员之间是紧密的连续的合作关系文档和计划驱动的方法每次迭代都产生可交付的软件软件交付时间晚,意识到风险的时间晚专注于交付软件WBS,甘特图,关键路径分析第一次迭代就可交付能工作的版本，风险发现的早敏捷特别强调人的因素相对于过程与工具，敏捷更强调“人”的因素诚信是基础没有过程能够对诚信进行有效的约束诚信与否是有效实施敏捷过程的最大限制敏捷宣言敏捷开发的核心敏捷开发的核心思想是思想是：以人为以人为本本，拥抱拥抱变化变化承承诺！Commitment！敏捷开发的12个原则1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意2.即使到了开发的后期，也欢迎改变需求3.经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作5.围绕被激励起来的个人来构建项目6.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈敏捷开发的12个原则7.工作的软件是首要的进度度量标准8.敏捷过程提倡平稳的开发节奏；发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度9.不断地关注优秀的技能和好的设计会增强敏捷能力10.简单化是根本（不做过度设计和预测）11.最好的构架、需求和设计出自于自组织的团队12.每隔一定时间，团队会在如何才能更有效地工作方面进行反思并对自己的行为进行相应调整Scrum何时更有效？公司和客户一致认为应当使用敏捷方法，双方都能理解敏捷方法敏捷方法对需求不完整以及经常变换的项目比较有效.项目可以划分成固定时间间隔的迭代公司和客户都有能力担当角色尤其是ProductOwner和ScrumMaster项目的人员结构能够分成6到10人的团队，最好每个工作地点一个小组团队成员能够以自组织的方式工作项目的合同允许变更固定价格的项目可以使用敏捷，但应当尽量避免变更项目的范围不需要高级管理层的批准使用Scrum面临的挑战公司文化是否是鼓励自主，易容错的企业文化？多做多错？PO是否有足够的前瞻性？PO是否能提出明确的需求、质量标准并清晰地传达给团队？PO是否能有效地评估每块的工作量和优先级？PO管理理念从：下命令转为团队服务，盯执行改为看方向SM是否是一个很好的问题发现/预见者，问题解决者？团队成员是否够专业（独当一面）？SCRUM带来的改善项目的计划性更强了，将项目按SPRINT进行分解，每个SPRINT要进行计划和总结，每天也有立会来进行简短的总结和计划项目团队的沟通比以往更有效项目的阶段性比以前更明确，通过SPRINT将项目划分成阶段，通过SPRINT演示等活动将项目整体的压力分解到每个SPRINT，这样可以有效降低项目的整体风险延伸学习原书名：AgileProjectManagementwithScrum硝烟中的Scrum和XP我们如何实施ScrumQ&AThank You!