《Scrum敏捷与DevOps浅谈PPT参考幻灯片PPT课件》由会员分享，可在线阅读，更多相关《Scrum敏捷与DevOps浅谈PPT参考幻灯片PPT课件（29页珍藏版）》请在金锄头文库上搜索。
1、,敏捷与DevOps浅谈,1,2020/11/21,引言,敏捷的出现缩小了商业需求和开发之间的隔阂，有效的加快了产品开发的周期和效率。 开发和运维之间的隔阂需要解决，DevOps的理念应运而生。,目录,理解敏捷 敏捷开发流程 Scrum迭代式增量软件开发 DevOps理念 敏捷与DevOps,敏捷更符合软件开发规律,传统开发,敏捷开发,软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长 敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品,理解敏捷,敏捷开发是 “一种以人为核心、迭代、循序渐进的开发方法 ! ”,在敏捷开发中，软件项目在构建
2、初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。,谁在用敏捷,目录,理解敏捷 敏捷开发流程 Scrum迭代式增量软件开发 DevOps理念 敏捷与DevOps,敏捷开发流程,PO和开发团队对产品业务目标形成共识 PO建立和维护产品需求列表（需求会不断新增和改变）,并进行优先级排序 PO每轮迭代前，Review需求列表，并筛选高优先级需求进入本轮迭代开发 开发团队细化本轮迭代需求，并按照需求的优先级，依次在本轮迭代完成 开发团队每日站立会议、特性开发、持续集成，使开发进度真正透明 PO对每轮迭代（24周）交付的可工作软件进行现场验收和反馈 回到第3步，开始
3、下一轮迭代,目录,理解敏捷 敏捷开发流程 Scrum迭代式增量软件开发 DevOps理念 敏捷与DevOps,Scrum特点,Scrum将小型团队转化为自身命运的管理者 强调每个人的主动性与参与性 快速实现“频繁变更的需求” 关注交付与产出的商业价值,目的：促使整个开发过程迅速、自我驱动,Scrum角色,敏捷团队包括3个核心角色: PO(Product Owner) 传递来自市场的声音、提升项目的回报 确定产品Backlog中的优先级 从产品的角度确保团队工作方向 Scrum Master(Scrum教练) 管理Scrum流程，确保Scrum运转 确保每个Sprint目标的实现与产出，不受外界
4、干扰 Team(Virtual Team虚拟团队) - 由5-9人组成（开发，测试等）、评估每个Sprint工作,Scrum框架,迭代规划会议 Sprint Plan 一般不超过8小时。 前4个小时：产品负责人向团队展示最高优先级的产品，团队则向他询问产品Backlog的内容、目的、含义及意图。 后4小时：团队计划本Sprint的安排,迭代复审会议 Sprint Review 一般4个小时，由团队成员向产品负责人和其他利益相关人展示Sprint周期内的产品开发情况,迭代回顾会议 Sprint Retrospective 一般3个小时， Scrum Master将鼓励团队在SCRUM过程框架和实
5、践范围内，对开发过程做出修改，使它在下一个Sprint周期中更加有效和令人愉快,每日站立会议 Daily Scrum Meeting 在简会上，每个成员主要回答三个问题; 自上次SCRUM简会后的一天了（昨天），你做了什么? 从现在到下次SCRUM简会的一天里（今天），你要做什么? 在实现SCRUM及项目目标的工作中，你遇到哪些困难吗?,Scrum工具,团队： Sprint计划会议（Sprint Backlog） Daily 简会 评审会议、总结,Product Backlog 所有需要完成的产品清单，包括优先级、商业诉求，PO负责 Sprint Backlog 由团队主动选择完成的每个Spr
6、int需要完成的Story列表 每个Story包括了需求、优先级、工作量 一旦确定，不亦更改 Sprint Burn down 显示工作量趋势变化的图表 每天由Scrum Master更新,Story列表,故事是用来讲的、分享的、讨论的,有价值：从商业的角度阐述（非技术术语） 小、独立：简单的功能 可讨论：关于故事的交流更重要 动态的：伴随交流，确定细节、优先级 优先级、需要交付的截止日期,大需求可先写下大故事，再提炼、分解,Story列表,XXXXX,备注：XXX,内容,优先级,P1,Sprint,Sprint 1,细节1：XXX 细节2：XXX 细节3：XXX,Task 1：3 hour,
7、Task 2：2 hour,Task 3：3 hour,Task 4：3 hour,Task 5：2 hour,Task 6：3 hour,Deadline,2015XXXX,SP,8,估算时间(story point) 计划纸牌,Daily Meeting,每天 15 分钟，团队面对面站立成圈 晨会是为项目信息同步可视化,不是为了解决问题 避免无关的讨论(SM引导) 欢迎各界人士，但只有“猪”可以发言,任务看板-燃尽图,迭代结果的验收(Review),迭代结果的验收(Review),团队需要演示所完成的迭代工作 典型的做法是使用演示形式展示新功能或者底层架构的实现 非正式的 2小时的提前准备
8、 不需要正式演示文档 相关的利益相关者 邀请所有关注产品的人参加,一个好Demo的效果,1. 促进PO融入团队 PO真正被团队认可成为团队的一员，不再是“那个被Boss传递需求” 2. 判定演示成效： 符合故事结果预期 没有Bug 亮点可以是技术的革新，界面好，生产力提升等 每个评委都必须把不足点表达出，并请团队改进 3. 沟通： 每个故事Demo后，有1 3分钟沟通和提问，团队会直接直面客户的反馈,目录,理解敏捷 敏捷开发流程 Scrum迭代式增量软件开发 DevOps理念 敏捷与DevOps,DevOps的出现,开发团队要求的不断满足新的客户需求，并快速实现新的功能。 而运营最关心的是“稳
9、定压倒一切”，任何差错都有可能对生产环境中的用户造成直接影响。,如何解决开发和运维的隔阂,Wikipedia对DevOps的定义是： DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。 它是人们为了及时生产软件产品或服务，以满足某个业务目标，对开发与运维之间相互依存关系的一种新的理解。 . DevOps并不仅仅关注软件部署，它是部门间沟通协作的一组流程和方法。,打破了目前的rd-qa-op流水线的流程 例如： rd每次提交代码触发一系列的自动化步骤，包括编译，单元测试，代码覆盖率，功能测试，部署测试，性能/容量测试，rd，qa，op都在过程
10、中做质量保障。,如何解决开发和运维的隔阂,代码树-主干开发 所有的feature作为一个整体发布,Team Foundation Server,持续集成工具-开发测试一体,持续集成,持续集成的解决方案是简洁的。产品由SVN去管理，构建过程由CI server负责，而构建过程包含了编译，测试，发布，部署过程,Tools： Automated infrastructure（自动化，系统之间可集成） shared version control（SVN共享源码） one step build and deploy（持续构建和部署） feature flags（公司内部称为single branch，主干开发） Shared metrics （指标度量工具） IRC and IM robots（信息整合）,目录,理解敏捷 敏捷开发流程 Scrum迭代式增量软件开发 DevOps理念 敏捷与DevOps,敏捷与DevOps,敏捷/精益开发方法可以提高应变业务变化的能力，并内建质量。 DevOps把开发和运维的沟壑抹平。那么我们的development和ITIL就能够结合到一起了。,敏捷与DevOps,Go for the goal！,
