Scrum敏捷与DevOps浅谈

1、1 敏捷与DevOps浅谈2引言敏捷的出现缩小了商业需求和开发之间的隔阂，有效的加快了产品开发的周期和效率。开发和运维之间的隔阂需要解决，DevOps的理念应运而生。3目录p 理解敏捷p 敏捷开发流程p Scrum迭代式增量软件开发p DevOps理念p 敏捷与DevOps4敏捷更符合软件开发规律传统开发敏捷开发软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品5理解敏捷敏捷开发是“一种以人为核心、迭代、循序渐进的开发方法 ! ”在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项

2、目的成果都经过测试，具备可视、可集成和可运行使用的特征。6谁在用敏捷7目录p 理解敏捷p 敏捷开发流程p Scrum迭代式增量软件开发p DevOps理念p 敏捷与DevOps8敏捷开发流程PO和开发团队对产品业务目标形成共识PO建立和维护产品需求列表（需求会不断新增和改变）,并进行优先级排序PO每轮迭代前，Review需求列表，并筛选高优先级需求进入本轮迭代开发开发团队细化本轮迭代需求，并按照需求的优先级，依次在本轮迭代完成开发团队每日站立会议、特性开发、持续集成，使开发进度真正透明PO对每轮迭代（24周）交付的可工作软件进行现场验收和反馈回到第3步，开始下一轮迭代迭代每日工作站立会议特性开

3、发特性测试持续集成交付可以工作的软件迭代计划回顾确定一个迭代的工作内容产品和利益相关人、9目录p 理解敏捷p 敏捷开发流程p Scrum迭代式增量软件开发p DevOps理念p 敏捷与DevOps10Scrum特点Scrum将小型团队转化为自身命运的管理者-强调每个人的主动性与参与性-快速实现“频繁变更的需求”-关注交付与产出的商业价值目的：促使整个开发过程迅速、自我驱动11Scrum角色敏捷团队包括3个核心角色: PO(Product Owner)-传递来自市场的声音、提升项目的回报-确定产品Backlog中的优先级-从产品的角度确保团队工作方向Scrum Master(Scrum教练)-管

4、理Scrum流程，确保Scrum运转-确保每个Sprint目标的实现与产出，不受外界干扰Team(Virtual Team虚拟团队) - 由5-9人组成（开发，测试等）、评估每个Sprint工作12Scrum框架迭代每2-4周Daily SCRUM每24小时高优先级可运行的软件工作项分解产品订单Product Backlog迭代订单Sprint Backlog新的功能增量迭代规划会议Sprint Plan一般不超过8小时。前4个小时：产品负责人向团队展示最高优先级的产品，团队则向他询问产品Backlog的内容、目的、含义及意图。后4小时：团队计划本Sprint的安排迭代复审会议Sprint R

5、eview 一般4个小时，由团队成员向产品负责人和其他利益相关人展示Sprint周期内的产品开发情况迭代回顾会议Sprint Retrospective一般3个小时， Scrum Master将鼓励团队在SCRUM过程框架和实践范围内，对开发过程做出修改，使它在下一个Sprint周期中更加有效和令人愉快每日站立会议Daily Scrum Meeting在简会上，每个成员主要回答三个问题;自上次SCRUM简会后的一天了（昨天），你做了什么?从现在到下次SCRUM简会的一天里（今天），你要做什么?在实现SCRUM及项目目标的工作中，你遇到哪些困难吗? 产品负责人Scrum主管开发团队13Scrum

6、工具团队：-Sprint计划会议（Sprint Backlog）-Daily 简会-评审会议、总结Product Backlog-所有需要完成的产品清单，包括优先级、商业诉求，PO负责Sprint Backlog-由团队主动选择完成的每个Sprint需要完成的Story列表-每个Story包括了需求、优先级、工作量-一旦确定，不亦更改Sprint Burn down-显示工作量趋势变化的图表-每天由Scrum Master更新14Story列表故事是用来讲的、分享的、讨论的-有价值：从商业的角度阐述（非技术术语）-小、独立：简单的功能-可讨论：关于故事的交流更重要-动态的：伴随交流，确定细节、

7、优先级-优先级、需要交付的截止日期大需求可先写下大故事，再提炼、分解15Story列表XXXXX备注：XXX内容优先级P1Sprint Sprint 1细节1：XXX细节2：XXX细节3：XXXTask 1：3 hourTask 2：2 hourTask 3：3 hourTask 4：3 hourTask 5：2 hourTask 6：3 hourDeadline2015XXXXSP816估算时间(story point) 计划纸牌17Daily Meetingl每天 15 分钟，团队面对面站立成圈l晨会是为项目信息同步可视化,不是为了解决问题l避免无关的讨论(SM引导)l欢迎各界人士，但只有

8、“猪”可以发言 18任务看板-燃尽图19迭代结果的验收(Review)迭代结果的验收(Review)n团队需要演示所完成的迭代工作n典型的做法是使用演示形式展示新功能或者底层架构的实现n非正式的n2小时的提前准备n不需要正式演示文档n相关的利益相关者n邀请所有关注产品的人参加20一个好Demo的效果1. 促进PO融入团队 PO真正被团队认可成为团队的一员，不再是“那个被Boss传递需求”2. 判定演示成效： 符合故事结果预期 没有Bug 亮点可以是技术的革新，界面好，生产力提升等 每个评委都必须把不足点表达出，并请团队改进3. 沟通： 每个故事Demo后，有1 3分钟沟通和提问，团队会直接直面

9、客户的反馈21目录p 理解敏捷p 敏捷开发流程p Scrum迭代式增量软件开发p DevOps理念p 敏捷与DevOps22DevOps的出现开发团队要求的不断满足新的客户需求，并快速实现新的功能。而运营最关心的是“稳定压倒一切”，任何差错都有可能对生产环境中的用户造成直接影响。23如何解决开发和运维的隔阂Wikipedia对DevOps的定义是： DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。 它是人们为了及时生产软件产品或服务，以满足某个业务目标，对开发与运维之间相互依存关系的一种新的理解。 . DevOps并不仅仅关注软件部署，它

10、是部门间沟通协作的一组流程和方法。打破了目前的rd-qa-op流水线的流程例如：rd每次提交代码触发一系列的自动化步骤，包括编译，单元测试，代码覆盖率，功能测试，部署测试，性能/容量测试，rd，qa，op都在过程中做质量保障。24如何解决开发和运维的隔阂代码树-主干开发所有的feature作为一个整体发布Team Foundation Server持续集成工具-开发测试一体25持续集成持续集成的解决方案是简洁的。产品由SVN去管理，构建过程由CI server负责，而构建过程包含了编译，测试，发布，部署过程Tools： Automated infrastructure（自动化，系统之间可集成） shared version control（SVN共享源码） one step build and deploy（持续构建和部署） feature flags（公司内部称为single branch，主干开发） Shared metrics （指标度量工具） IRC and IM robot