scrum敏捷模式PPT课件.ppt

scrum敏捷开发模式 2012年07月24日bywangrb 主要内容 什么是敏捷开发敏捷开发宣言敏捷开发原则敏捷实践模式敏捷中的异味如何避免异味采用敏捷的好处 什么是scrumscrum角色scrum构件scrum活动敏捷常见误解团队合作之道 2 什么是敏捷开发 是一种以人为核心 迭代 循序渐进的增量式开发方法在敏捷开发中 软件项目的构建被切分成多个子项目 各个子项目的成果都经过测试 具备集成和可运行的特征简言之 就是把一个大项目分为多个相互联系 但也可独立运行的小项目 并分别完成 在此过程中软件一直处于可使用状态 3 什么是敏捷开发 常用敏捷开发方法XP极限编程 ExtremeProgramming Scrum特征驱动开发 FeatureDriverDevelopment 动态系统开发 DynamicSystemsDevelopmentMethod 透明水晶开发 CrystalClear 4 什么是敏捷开发 瀑布模型采用结构化的分析和设计方法逻辑实现与物理实现分离按工序将问题简化固定的 没有弹性很困难去达到互动项目周期较长 敏捷方法完整地开发 每少数几周或是少数几个月里可以测试功能 强调在获得最简短的可执行功能的部分 能够及早给予企业价值 在整个项目的生命周期里 可以持续的改善 增加未来的功能 5 什么是敏捷开发 瀑布模型 scrum敏捷模型 6 什么是敏捷开发 传统项目管理 事先对整个项目进行估计 计划 分析反对变更 变更需要重新估计 重新规划严密的合同来减少风险 如果改变需求要走CR流程 项目作为一个 黑盒子 对客户与供应商的可视性差 文档和计划驱动的方法 软件交付时间晚 意识到风险的时间晚 WBS 甘特图 关键路径分析 敏捷项目管理 对整个项目做一个粗略的估计 每一次迭代都有详细的计划 鼓励变化 客户价值驱动开发 信任和赋予权力 合约使变更变得简单 增加价值 客户和开发人员之间是紧密的连续的合作关系每次迭代都产生可交付的软件专注于交付软件 第一次迭代就可交付能工作的版本 风险发现的早 7 敏捷开发宣言 个体和交互胜过过程和工具可以工作的软件胜过面面俱到的文档客户合作胜过合同谈判响应变化胜过遵循计划 8 敏捷开发宣言 1 个体和交互胜过过程和工具人是软件项目获得成功最为重要的因素合作 沟通能力以及交互能力比单纯的软件编程能力和工具更为重要方法和工具是死的 人是活的 人要是太 面 或者协作不好 再强大的方法和工具都是白扯 9 敏捷开发宣言 2 可以工作的软件胜过面面俱到的文档过多的面面俱到的文档往往比过少的文档更糟软件开发的主要和中心活动是创建可以工作的软件直到迫切需要并且意义重大时 才进行文档编制编制的内部文档应尽量短小并且主题突出 10 敏捷开发宣言 3 客户合作胜过合同谈判客户不可能做到一次性地将他们的需求完整清晰地表述在合同中 为开发团队和客户的协同工作方式提供指导的合同才是最好的合同 11 敏捷开发宣言 4 响应变化胜过遵循计划变化是软件开发中存在的现实计划必须有足够的灵活性与可塑性短期的迭代的计划比中长期计划更有效 12 敏捷开发原则 最优先要做的是通过尽早的 持续的交付有价值的软件来使客户满意即使到了开发的后期 也欢迎改变需求 敏捷过程利用变化来为客户创造竞争优势 经常性的交付可以工作的软件 交付的时间间隔可以从几周到几个月 交付的时间间隔越短越好在整个项目开发期间 业务人员和开发人员必须天天在一起工作 13 敏捷开发原则 围绕被激励起来的个人来构建项目 给他们提供所需要的环境和支持 并且信任他们能够完成工作 在团队内部 最具有效果并且富有效率的传递信息的方法 就是面对面的交谈 而不是文档 工作的软件是首要的进度度量标准 敏捷过程提倡可持续开发进度 责任人 开发者和用户应该能够保持一个长期的 恒定的开发速度 14 敏捷开发原则 不断地关注优秀的技能和好的设计会增强敏捷能力简单化是根本最好的架构 需求和设计出自于自组织的团队每隔一段时间 团队会在如何才能更有效地工作方面进行反省 然后相应地对自己的行为进行调整 15 敏捷实践模式 反馈实践模式技术实践模式辅助实践模式 16 敏捷实践模式 反馈实践模式 迭代在一个固定时间周期内 由团队完成系统中一部分功能的开发设定目标 启动会 演示和回顾启动会同步团队之间的工作 计划迭代要完成的工作设定目标 做出承诺待办工作事项需要完成的工作即需求 有优先级规划 扑克 快速估计实现需求所要付出的工作量站立会议迭代中的见面交流会 完成了什么 要做什么 有什么问题一般不超过15分钟 17 敏捷实践模式 反馈实践模式 完成状态迭代中每个需求的完成目标以及对完成的定义尽可能的接近部署或发布演示迭代结束是向项目的相关负责人进行系统功能展示回顾迭代结束或者发布后举行 总结经验 优化流程频繁发布条件允许的情况下 尽可能经常的发布软件给用户前提需要做到持续集成 联合驻扎 团队团队成员在同一个物理空间工作 便于相互交流 18 敏捷实践模式 反馈实践模式 自组织团队不需要外部过多的指导和干预 团队成员自己推进目标的实现需要经常回顾改进工作方法 提升团队的效率跨职能团队类似外科手术团队 具备完成一个系统所需要的各种成员scrum团队客户作为团队成员客户加入团队一起工作 需要客户对所需要解决的业务问题理解非常透彻唤醒式文档唤起人们的记忆 比传统的文档更有意义花更多的时间进行面对面的交流 较少的时间编写和维护文档 19 敏捷实践模式 反馈实践模式 用户故事为需求创建一个唤醒式文档 对需求的概要描述一般包括需求描述以及完成定义用例描述对客户有重要价值的业务流程描述系统行为的一种需求表现形式信息辐射器提高透明度 便于信息的交流重要数据 进度 问题等 20 敏捷实践模式 技术实践模式 自动化测试测试可被轻松的执行促进系统设计不断的趋向于松耦合测试后行开发开发完代码后再进行测试测试先行开发先编写测试 然后开发产品代码必须有良好的设计 结构松耦合重构保持系统原有功能的同时 改进系统设计和代码结构发现问题 马上动手 经常性的重构 21 敏捷实践模式 技术实践模式 持续集成代码变更提交后 执行完整的构建 集成运行并通过所有的测试简单设计设计复杂程度满足当前需求即可 不要画蛇添足持续改进设计功能测试满足客户验收需求的测试确保系统输出使用户所想要的集体代码所有权开发团队中的任何人都有权利和责任修改任何一部分代码结对编程两个人一起工作 相互合作 提升产品质量 减少对专家的依赖 22 敏捷实践模式 辅助实践模式 教练有经验的敏捷开发实践者 作为顾问加入团队 帮助团队进步融入敏捷社区获取知识 建议和经验的地方读书会大家一同学习 分享一本好书研讨会课堂培训 23 敏捷中的异味 僵化 很难对系统进行改动 因为每个改动都会迫使许多对系统其他部分的其它改动脆弱 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题 牢固 很难解开系统的纠结 使之成为一些可在其他系统中重用的组件 粘滞 做正确的事情比做错误的事情要困难 24 敏捷中的异味 复杂 设计中包含有不具任何直接好处的基础结构 重复 设计中包含有重复的结构 而该重复的结构本可以使用单一的抽象进行统一 晦涩 很难阅读 理解 没有很好地表现出意图 25 如何避免异味 单一职责原则 SRP 就一个类而言 应该仅有一个引起它变化的原因 开放 封闭原则 OCP 软件实体应该是可以扩展的 但是不可修改 里氏替换原则 LSP 子类型必须能够替换掉它们的基类型 26 如何避免异味 依赖倒置原则 DIP 抽象不应该依赖于细节 细节应该依赖于抽象 接口隔离原则 ISP 不应该强迫客户依赖于它们不用的方法 接口属于客户 不属于它所在的类层次结构 重用发布等价原则 REP 重用的粒度就是发布的粒度 27 如何避免异味 共同封闭原则 CCP 包中的所有类对于同一类性质的变化应该是共同封闭的 一个变化若对一个包产生影响 则将对该包中的所有类产生影响 而对于其他的包不造成任何影响 共同重用原则 CRP 一个包中的所有类应该是共同重用的 如果重用了包中的一个类 那么就要重用包中的所有类 28 如何避免异味 无环依赖原则 ADP 在包的依赖关系图中不允许存在环 稳定依赖原则 SDP 朝着稳定的方向进行依赖 稳定抽象原则 SAP 包的抽象程度应该和其稳定程度一致 29 采用敏捷的好处 缩短产品上市时间增强产品实用性提高产品质量提高灵活性增强透明度降低成本延长产品生命周期业务价值是组织的目标 30 什么是scrum 是一种敏捷开发框架 一个迭代式 增量开发过程 属于敏捷开发的一种 它由一个开发过程 几种角色以及一套规范的实施方法组成 角色 productowner scrummaster scrumteam stakeholder构件 productbacklog sprintbacklog burn downchart活动 sprintplanningmeeting dailystandupmeeting sprintreviewmeeting retrospectivemeeting 31 scrum敏捷流程 32 scrum角色 productowner productowner产品利益相关方的代表 负责产品相关业务 给出明确的 可度量的 合理的产品backlog职责 确定产品的功能 决定发布的日期和发布内容 为产品的profitabilityoftheproduct ROI 负责 根据市场价值确定功能优先级 每个Sprint 根据需要调整功能和优先级 每个Sprint开始前调整 接受或拒绝接受开发团队的工作成果 33 scrum角色 scrummaster scrummaster为scrum过程负责的人 整个团队的导师和组织者 确保scrum的正确使用并使得Scrum的收益最大化职责保证团队资源完全可被利用并且全部是高产出的 保证各个角色及职责的良好协作 解决团队开发中的障碍 做为团队和外部的接口 屏蔽外界对团队成员的干扰 保证开发过程按计划进行 组织每日站立会议 演示会 回顾会 34 scrum角色 scrumteam scrumteam自组织的跨职能团队 以完成目标为己任职责一般情况下人数在5 9个左右团队要跨职能 包括开发人员 测试人员 用户界面设计师等 团队成员需要全职 有些情况例外 比如架构师 在项目向导范围内有权利做仸何事情已确保达到Sprint的目标高度的自我组织能力向ProductOwner演示产品功能团队成员构成在sprint内不允许变化 35 scrum角色 stakeholder 项目组有关的成员 但并不专注于项目以观察者的形式参加Scrummeeting 36 scrum构件 productbacklog 一个关于产品的需求列表 一般情况使用用户故事 userstory 来表示backlog条目backlog条目按照商业价值排列优先级 理想情况每个需求项都对产品的用户有价值 优先级由产品负责人来排列在每个Sprint结束的时候要更新优先级的排列 37 scrum构件 sprintbacklog 一次迭代计划要完成的需求 来自productbacklog进入sprintbacklog的需求都是清楚的 没有歧义每个需求已有团队成员认领 并估计了完成工作量每项sprintbacklog有合理的任务拆解 有些任务可以并行 38 scrum构件 burn downchart 39 scrum活动 计划会 40 scrum活动 计划会 计划会议要有足够的时间 至少4个小时取出部分产品需求做成sprint需求 并制成卡片确定并细分每一个卡片的故事 Story 通过认领分配工作确定每日站立会议的时间和地点确定好演示会议和回顾会议的日期 41 scrum活动 站立会议 团队每日例会 在同样的时间和地点举行 所有成员站立开会最好每日上班开始或者临近下班时开 一般15分钟左右 严格控制时间只有团队成员可以在例会上发言 其他人员有兴趣可以参加 但只能旁听 不能发言每日Scrum会议由ScrumMaster主持 Scrum团队所有成员轮流回答以下3个问题 昨天我完成了什么工作 今天我打算做什么 我在工作中遇到了什么困难 更新燃尽图 42 scrum活动 演示会 演示会用来演示在这个Sprint中开发的产品功能给ProductOwner ProductOwner会组织这阶段的会议并且邀请利益相关者参加团队展示Sprint中完成的功能一般是通过现场演示的方式展现功能和架构 不要太正式 不需要PPT 一般控制在2个小时以内团队成员都要参加利益相关者和有兴趣的人员参加 43 scrum活动 回顾会 团队的定期自我检视 一般控制在15 30分钟每个Sprint都要做 全体team成员参加会议主题可以发扬的经验需要改进的问题会议组织会议准备收集信息讨论分析收集到的信息制定改进计划结束会议 44 敏捷常见误解 敏捷是拯救任何项目的银弹敏捷方法只有运用得当才有效果敏捷意不需要任何文档敏捷是有严格要求的 也是面向质量的根据沟通的需要产生相应的文档 45 敏捷常见误解 采用敏捷方法的项目不需要制定计划敏捷项目需要经常制定计