敏捷开发-Scrum-PPT课件.pptx

1、敏捷开发-ScrumAdermon 2019.3目录 基本概念 Scrum 框架 Scrum 开发流程 Scrum 关键实践 Scrum 敏捷开发总结Scrum 起源英式橄榄球中的术语1986年，竹内弘高和 野中郁次郎在 New Product Development Game文章首次提到将Scrum应用与产品开发1993年首次在Easel公司定义了用于了软件开发行业的Scrum流程，并开始实施。2019年 敏捷宣言及原则发布、敏捷联盟成立，Scrum是其中一种敏捷方法。2019年Ken Schwaber 和Mike Cohn共同创办了Scrum联盟。Scrum 框架Scrum 角色 Prod

2、uct Owner（PO）确定产品的功能(User Story)决定发布的日期和发布内容 为产品的profitability of the product(ROI)负责 根据市场价值确定功能优先级 每个Sprint，根据需要调整功能和优先级（每个Sprint开始前调整）接受或拒绝接受开发团队的工作成果Scrum 角色 Scrum Master(SM)保证团队资源完全可被利用并且全部是高产出的 保证各个角色及职责的良好协作 解决团队开发中的障碍 做为团队和外部的接口，屏蔽外界对团队成员的干扰 保证开发过程按计划进行 组织 Daily Scrum Meeting 组织Sprint Review a

3、nd Sprint Planning meetingsScrum 角色 Scrum Team(Team)在项目向导范围内有权利做任何事情以确保达到Sprint的目标 高度的自我组织能力 向Product Owner演示产品功能 团队成员构成在sprint内不允许变化 团队包括开发人员、测试人员、用户界面设计师等Scrum 物件 看板、燃尽图(Burn Down Chart)Scrum 物件 看板示例1Scrum 物件 看板示例2Scrum 物件 看板示例3Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Da

4、y 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 物件 产品订单(Product Backlog)一个需求的列表 使用用户故事(User Story)来表示bac

5、klog条目 每个需求项都对产品的客户或用户有价值 Backlog条目按照商业价值排列优先级 优先级由产品负责人(PO)来排列 在每个Sprint结束的时候要更新优先级的排列 用户故事(User Story)作为一个XXX(角色)，我想。(实现的功能)，以便于。(商业价值)Sprint 物件 产品Backlog示例做什么APP？做一个出行工具？做一个聊天软件？做一款点餐软件？做一款新闻软件？。Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示De

6、moScrum 角色汇总Scrum 仪式-Sprint计划会议(Planning Meeting)Scrum 仪式-Sprint计划会议(Planning Meeting)冲刺(Sprints)Scrum的项目过程有一系列的Sprint组成 Sprint的长度一般控制在2-4周 通过固定的周期保持良好的节奏 产品的设计、开发、测试都在Sprint期间完成 Sprint结束时交付可以工作的软件 在Sprint过程中不允许发生变更Sprint 物件 冲刺订单(Sprint Backlog)团队成员自己挑选任务，而不是指派任务 对每一个任务，每天要更新剩余的工作量估算 每个团队成员都可以修改Spri

7、nt backlog，增加、删除或者修改任务Sprint 物件 Sprint Backlog示例1Sprint 物件 Sprint Backlog示例2Scrum时间估算-估算扑克的使用方法 每个团队成员拿到一组卡片 产品负责人或者一名团队成员扮演阅读者的角色，他负责阅读需要估算产品Backlog的条目，并且询问大家是否有疑问 团队讨论这个条目 当团队理解了这个条目之后，每个团队成员按照自己的想法给出估算结果，并且选择对应的扑克出牌 所有人都出牌之后，阅读者向大家确认是否都已经确定估算结果 团队评估不同的估算结果，最终团队需要达成一致 开始估算下一个条目Sprint 物件 Burn Down

8、Chart示例1Sprint 物件 Burn Down Chart示例2Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示DemoScrum 仪式 每日立会(Daily Meeting)一般10至15分钟 每天都在同样的时间和地点 只有团队成员可以在例会上发言 其他人员有兴趣可以参加，但只能旁听，不能发言 由Scrum Master主持 三个问题：昨天我完成了什么工作？今天我打算做什么？我在工作中遇到了什么困难？“完成”的定义 当迭代任务清单上的

9、任务都完成时，变为“已完成”状态“已完成”是0/1变量：完成或者未完成.所有的任务（task)都完成了迭代任务才算完成 在第一个迭代开始之前应该定义好，因为它会影响工作量,而且必须文档化，这样团队和产品所有者的理解是一致的Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示DemoScrum 敏捷开发关键实践1 增量迭代 每个迭代有一个大约为14周的时间框，在SCRUM里称为一次冲刺 每次迭代都应该有明确的目标 每次迭代都应该有明确的可演示的工作成

10、果 迭代过程中项目团队应该尽量免受打扰 迭代可以将项目的压力分解到每个小的阶段，风险也能同时分解Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示DemoScrum 敏捷开发关键实践2 测试驱动开发 TDD 什么是测试驱动？一种设计软件的方法，而不仅仅是一种测试方法 所创建的测试用例用来指导和约束项目中的各项工作，对未来的各项工作提供一个安全的保护 不需要测试的工作不需要完成 TDD有效地驱动设计，使设计更加趋向于可行的设计 通常情况下需要自动测

11、试的支持(EUnit,JUnit etc.)对于UI软件应用TDD方法有一定的困难Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示DemoScrum 仪式-Sprint评审会议(Review Meeting)团队给Product Owner演示在这个Sprint中开发的产品功能 Product Owner会组织这阶段的会议并且邀请相关的干系人参加 通过现场演示的方式展现功能和架构 非正式：不需要PPT、一般控制在2个小时 团队成员都要参加Scr

12、um 仪式 Sprint回顾会议(Retrospective Meeting)团队的定期自我检视，发现什么是好的，什么是不好的 一般控制在15-30分钟 每个Sprint结束都要做 全体参加 Product Owner Scrum Master Team 可能的客户或其它干系人Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示Demo猪与鸡的故事Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画

13、任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示DemoScrum of Scrums谁来清除障碍？每个人 自我管理、自我组织的团队 Scrum Master 产品所有者 管理层 其他相关的干系人 Scrum Master 确定障碍已经清除 不一定亲自自己清除Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示DemoScrum 敏捷开发关键实践3 持续集成 持续集成一般利用ANT、MAVEN、Je

14、nkins等工具 日构建的好处 将集成风险降到最低 降低质量风险 提升士气 每日构建可以看做是项目的心跳，冒烟测试就像是听诊器 日构建必须至少：成功编译、打包、发布；不含有任何明显的缺陷；通过冒烟测试Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示DemoScrum 敏捷开发关键实践4 面对面交流 敏捷开发要求团队成员彼此直接协作，尽量创造面对面交流的机会 尤其当业务分析师和软件开发人员一起工作的时候，面对面的交流是很重要的 面对面交流可以打开

15、曲解和误解之门 书面信息比口头交流还要慢很多Scrum敏捷开发准备工作确定PO确定SM确定Team头脑风暴做什么User Story优先级计划会画任务板画燃尽图建立SB估算工期迭代Day 1Day 2Day 3回顾总结PO 回顾Team总结演示DemoScrum 框架为什么敏捷?更加透明;随时跟踪项目的状态和进展情况，及早发现问题和风险 快速交付,每次迭代都能交付可运行的软件 最高风险和最高优先级的需求，最优先进行开发 改善应对变更能力,减少大量的重计划 改善项目沟通 更好的客户参与,避免错误的假设理想与现实瀑布模型的主要缺陷 程序的维护成本越来越高 团队氛围压抑（感受不到激情）不方便做需求变

16、更（引起客户不满）敏捷方法 VS.瀑布模型 敏捷方法 完整地开发，每少数几周或是少数几个月里可以测试功能 强调在获得最简短的可执行功能的部分，能够及早给予企业价值 在整个项目的生命周期里，可以持续的改善、增加未来的功能 瀑布模型 固定的、没有弹性的 很困难去达到互动 假如说需求没有完全的被了解，或是可能需要完全地改变项目的需求，瀑布式的model是比较不适合的敏捷项目管理 VS.传统项目管理传统项目管理传统项目管理敏捷项目管理敏捷项目管理事先对整个项目进行估计、计划、分析对整个项目做一个粗略的估计,每一次迭代都有详细的计划反对变更;变更需要重新估计、重新规划鼓励变化,客户价值驱动开发严密的合同

17、来减少风险,如果改变需求要走 CR 流程信任和赋予权力;合约使变更变得简单，增加价值项目作为一个“黑盒子”，对客户与供应商的可视性差客户和开发人员之间是紧密的连续的合作关系文档和计划驱动的方法每次迭代都产生可交付的软件软件交付时间晚,意识到风险的时间晚专注于交付软件WBS,甘特图,关键路径分析第一次迭代就可交付能工作的版本，风险发现的早敏捷特别强调人的因素 相对于过程与工具，敏捷更强调“人”的因素 诚信是基础 没有过程能够对诚信进行有效的约束 诚信与否是有效实施敏捷过程的最大限制敏捷宣言敏捷开发的核心敏捷开发的核心思想是思想是：以人为以人为本本，拥抱拥抱变化变化承诺！承诺！Commitment

18、！敏捷开发的12个原则1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意2.即使到了开发的后期，也欢迎改变需求3.经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好 4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作5.围绕被激励起来的个人来构建项目6.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈敏捷开发的12个原则7.工作的软件是首要的进度度量标准8.敏捷过程提倡平稳的开发节奏；发起人、开发者和用户应该能够保持一个长期的、恒定的开发速度9.不断地关注优秀的技能和好的设计会增强敏捷能力10.简单化是根本（不做过

19、度设计和预测）11.最好的构架、需求和设计出自于自组织的团队12.每隔一定时间，团队会在如何才能更有效地工作方面进行反思并对自己的行为进行相应调整Scrum何时更有效？公司和客户一致认为应当使用敏捷方法，双方都能理解敏捷方法 敏捷方法对需求不完整以及经常变换的项目比较有效.项目可以划分成固定时间间隔的迭代 公司和客户都有能力担当角色尤其是Product Owner 和 Scrum Master 项目的人员结构能够分成6到10人的团队，最好每个工作地点一个小组 团队成员能够以自组织的方式工作 项目的合同允许变更 固定价格的项目可以使用敏捷，但应当尽量避免 变更项目的范围不需要高级管理层的批准使用

20、Scrum面临的挑战 公司文化是否是鼓励自主，易容错的企业文化？多做多错？PO是否有足够的前瞻性？PO是否能提出明确的需求、质量标准并清晰地传达给团队？PO是否能有效地评估每块的工作量和优先级？PO管理理念从：下命令转为团队服务，盯执行改为看方向 SM是否是一个很好的问题发现/预见者，问题解决者？团队成员是否够专业（独当一面）？SCRUM带来的改善 项目的计划性更强了，将项目按SPRINT进行分解，每个SPRINT要进行计划和总结，每天也有立会来进行简短的总结和计划 项目团队的沟通比以往更有效 项目的阶段性比以前更明确，通过SPRINT将项目划分成阶段，通过SPRINT演示等活动将项目整体的压力分解到每个SPRINT，这样可以有效降低项目的整体风险延伸学习原书名：Agile Project Management with Scrum 硝烟中的Scrum和XP我们如何实施ScrumQ&AThank You!