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