华为云帐号：zand123微信：烧海Day05 今天的主题是：线上直播-大咖有话说：Devops论道，解析敏捷开发四大流派  （0）      听了老师们的讲解，对敏捷和DevOps的实施和应用，又有了更多更具体的理解。1） 敏捷实践是涌现式的，不是规划的，也不是有一定的公式可以直接套用。2） 敏捷和Devops的实践要与公司的业务目标保持一致，目的是为了更快更好的满足和支持公司业务。3） 各个工具可以联合使用，融会贯通，重要的思维和方法。 （1）      ScrumScrum 是英式橄榄球运动的一个专业术语，表示“争球”的动作。橄榄球是一项单位场地内寸土必争的运动，一方获得进攻权利，就会一步步地推进到敌方阵营。这样就类似团队进行开发项目时，通过团队合作把项目一步步推进，和打橄榄球一样迅速、充满激情，所以把这样的一个开发流程取名为 Scrum。 Scrum诞生于1990~1995年之间，由美国软件类资深专家Jeff Sutherland和Ken Schwaber联合提出。 Scrum 使用产品 Backlog 来管理产品的需求，产品 Backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。 Scrum 团队是一个跨职能的自组织团队。在 Sprint 中，Scrum 团队从产品Backlog 中挑选最高优先级的需求进行开发。挑选的需求在 Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，这被称为 Sprint Backlog。 在每个迭代结束时，Scrum 团队将递交潜在可交付的产品增量。增量式交付“完成”的产品保证了一个可工作产品的潜在可发布版本总是存在。  （2）DevOps为了按时交付软件产品和服务，开发和运维工作必须紧密合作。 DevOps是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。 DevOps是软件开发生命周期（SDLC）从瀑布式到敏捷再到精益的发展。DevOps超越了敏捷，它的关注点是从SDLC中移除浪费。 在DevOps的能力闭环中，关注的是：更早、更频繁地发布产品更新，更快速的响应变化。依托自动化工具（测试、部署），把开发、测试、发布、部署的过程整合，实现即时交付。 DevOps的涉众：开发、测试、运维，需要求同存异，为组织目标共同担当，紧密配合，提升产品交付能力。 DevOps实践的三个指导原则： 1）系统思考：系统中任务都是相互关联，共同组成复杂系统。某个阶段的延迟会影响到后续任务。对系统有全局思考能确定瓶颈在哪里，并解决或规避它们，以避免工作流中的排队现象。 2）促进反馈：在组织的各个部分之间创建，缩短和放大反馈循环。在末尾阶段查看结果，并根据结果信息，改进流程。例如，团队需要知道质量很差的结果，这样他们才能在测试阶段集中投入更多的精力去改进。团队也需要知道质量特别高的结果，让团队需要知道他们所做的工作是有成效的。 3）不断的试验和改进：创建一种既能保持不断实验和学习的工作文化。团队愿意冒实验的风险，不断的试验，以持续改进。他们相信团队的反馈流程，通过实验可以快速的发现问题。他们能够快速适应变化，不怕挑战流程，并习以为常。  （3）Kanban看板方法源自丰田的“及时生产”（JIT，just in time）系统。通过可视化、拉动式的方式促进开发流程的有序流动。解决系统瓶颈，提高交付效率。 工作流程形象化：l  把工作细分成任务，写在卡纸上，贴在墙上l  把栏命名好，来显示任务在工作流程中的状况 限制“在制品”（work in progress，简称 WIP）：明确设定限制在每个状态下同一时间能有多少工作任务度量生产周期（即完成一个任务的平均时间）：优化开发过程，缩短开发周期和使它更易于预测。  （4）XP极限编程XP，eXtreme Programming。使开发者能够更有效的响应客户的需求变化，哪怕是在软件生命周期的后期。XP方法是为小团体开发建立的，在2-10 个人之间。 XP是一种轻量开发方法，强调将任务/系统细分为可以在较短周期解决的一个个子任务/模块，并且强调测试、代码质量和及早发现问题。 XP有五个核心价值：沟通（Communication）、简单（Simplicity）、反馈（Feedback）、尊重（Respect）和勇气（Courage） XP方法包含：规划策略（The Planning Game）；结对编程（Pair programming）测试（Testing）重构（Refactoring）简单设计（Simple Design）代码集体所有权（Collective Code Ownership）持续集成（Continuous Integration）现场客户（On-site Customer）小型发布（Small Release）每周40小时工作制（40-hour Week）编码规范（Code Standards）系统隐喻（System Metaphor）  

华为云帐号：zand123微信：烧海Day04今天学习了徐磊老师的《持续交付》。 （1）持续交付的挑战：软件开发中的三级耦合l  代码级耦合l  组件级耦合l  服务级耦合（2）团队协作的全新思路，Infra/Config as Codel  基础设施即代码（Infra as Code）l  配置即代码（Configuration as Code）工具链的全新定位：Infra/Config as Code —— 配置管理->自动化->云。l  配置管理：不仅仅是代码管理，不仅仅为开发服务，版本管理的基础l  自动化：不仅仅是编译构建，不仅仅为开发服务，连接一切l  云：自助自主，按需使用，版本管理的延申将运维服务转变为运维能力提供给开发团队，将稳定性、性能、安全性等要求作为约束传导给开发人员。  （3）Docker对于DevOps的价值Dock：码头Container：集装箱Docker：码头工人 Container：容器Docker：代码集装箱装卸工人 Docker对代码进行封装、转移、管理的标准化工具，Container是容器。一次构建，多处运行。配置一次，运行任何应用。 （4）容器编排平台的价值 单体应用架构：单体应用一般对应到某一业务领域所需要的各种功能和能力，并按照功能进行分层设计，如：Web，业务逻辑层和数据层。通过在多套服务/虚拟机/容器中整体复制的方式进行扩展。 微服务应用架构：微服务应用根据功能拆分为不同的可以独立运行的服务中。通过在服务器/虚拟机/容器中克隆服务的方式继续进行扩展。 单体应用架构（养宠物，坏了要修复）->微服务应用架构（养牛，坏了杀掉旧的、重启新的）。 支持使用不同的开发语言和框架实现服务，支持部署到不同的环境（公有云、私有云、独立数据中心、虚拟机和实体机）。 （5）测试金字塔和测试受创面测试层越高，开发复杂度越高测试层越低，单元隔离性越强。 特点：界面测试：测试受创面最大，开发复杂度大，交付进度受影响。单元测试：测试隔离性最强，定位问题越容易，受创面最小。 成本与收益：界面测试：短期收益大，长期维护成本高单元测试：短期收益小，长期维护成本低 一般公司会先做接口自动化测试等折中的测试。 建议：业务发展初期先做短期收益大，维护成本高的界面测试，而且一般多为人工测试。随着业务的发展，逐渐将一些业务总结为接口测试、单元测试等自动化测试，提高效率，降低成本。 （6）Git特性分支模型和CI/CD流水线使用Feature分支做功能开发，持续集成、构建、部署。从测试环境到生产环境的每个环境，都是这样。测试都通过以后，合并到master。保证master的稳定。

华为云帐号：zand123微信：烧海Day 03今天学习了姚冬老师的《混沌工程与反脆弱的能力构建》。 （1）这是一个VUCA时代Volatility 易变性，Uncertainty 不确定性，Complexity 复杂性，Ambiguity 模糊性。 （2）墨菲定律没，有什么是不可能发生的……如果有两种或两种以上的方式去做某件事情，而其中一种选择方式将导致灾难，则必定有人会做出这种选择1） 任何事情没有表面看起来那么简单2） 所有的事都会比你预计的时间长3） 会出错的事总会出错4） 如果你担心某种情况发生，那么它就更有可能发生我们永远不可能在实验室里验证现实世界中的一切 （3）反脆弱三部曲：在生产环境中注入故障来恢复和学习将持续改进变成日常建立公正和学习的文化 （4）混沌工程的原则1）建立稳定状态的假设Ø  假定监控指标Ø  假设注入事件，系统依然稳定2） 多样化现实世界事件Ø  根据现世界设定事件Ø  注入事件是被认为系统可以处理的事件Ø  只需要注入哪些频发发生影响重大的事件3）在生产环境运行实验Ø  混沌实验离生产越近越好4）持续自动化运行实验Ø  自动执行实验Ø  自动分析实验结果Ø  自动创建的实验5）最小化影响范围Ø  对线上业务影响最小范围Ø  先小范围，在不断扩大Ø  避免在高风险时间段进行实验 （5）我们怎么做我们工作在复杂系统中无法从局部行为来解释系统行为同样的事情做两次，结果未必相同失败在复杂系统中经常会发生故障不可避免->不问责->学习型组织Good decision comes from experience, experience comes from bad decision.

华为云帐号：zand123微信昵称：烧海Day02今天学习了许舟平老师的《跨越敏捷与DevOps的鸿沟》。 （1）      业界软件阶段：瀑布->敏捷->DevOps。从1950年代的戴明和全面质量管理（TQM），到1980年代精益制造&改善，到1990年代的CMM&IT服务和基础架构库（ITIL），到最近2000年代的敏捷开发、2010年代的DevOps。（2）      研发交付的目的：Sustainable Deliver High Quality Working Softare Faster。Faster，业务能力。Deliver，研发能力。Working，技术能力。Sustainable、High Quality，工程能力。（3）      各个部门的希望、文化和利益不同，难免有隔阂或者鸿沟，需要调节。运维部门，希望稳定：服务文化（归档、监管、支持）开发部门，希望交付：产品文化（软件开发）业务部门，希望赢单：市场文化（客户至上）客户/用户，希望价值：实用文化（价值至上）Lean Startup解决客户与业务部门之间、以及整体各个部门之间的鸿沟。Agile解决业务部门与开发部门之间的鸿沟。DevOps解决开发部门与运维部门之间的鸿沟。（4）      敏捷4条价值观：个体和互动高于流程和工具。工作的软件高于详尽的文档。客户合作高于合同谈判。响应变化高于遵循计划。（5）      敏捷12原则：1)       客户满意：我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。2)       拥抱变化：欣然面对需求变化，即使在开发后期也一样。善于掌控变化，帮助客户获得竞争优势。3)       持续交付：经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。4)       跨职能：业务人员和开发人员必须相互合作，项目中的每一天都不例外。5)       充分信任：激发个体的斗志，以他们为核心搭建项目。提供他们所需的环境和支持，相信他们能够达成目标。6)       面对面：不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。7)       可用的软件：可工作的软件是进度的首要度量标准。8)       可持续开发：敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。9)       不断完善：对技术精益求精，对设计不断完善，将提高敏捷能力。10)    简洁：以简洁为本，极力减少不必要工作量。11)    自组织：最好的架构、需求和设计出自于自组织的团队。12)    回顾总结：团队定期地反思如何能提高成效，并依此调整团队的行为。（6）      持续交付是持续集成的自然延伸，持续部署看业务需求。（7）      几点理念。1)       不要信任权威2)       技术能力第一，而不是看学历、年龄、地位或其他3)       任何事情都应该亲手尝试，知行合一事上练4)       良好的坏习惯 —— 打破常规5)       另一条路 —— 勇于创新6)       拒绝平庸 —— 别忘记了你的对手与你一样  谢谢许老师的讲解！

华为云账号：zand123微信昵称：烧海结业实践任务1-使用DevCloud进行敏捷项目规划：结业实践任务2-使用静态代码检查确保编码规范的有效落地：结业实践任务3-使用Git代码托管支撑敏捷团队持续交付：

华为云帐号：zand123微信昵称：烧海Day 01今天学习了王立杰老师讲的《实例化看板》。 与XP、Scrum相比，看板更灵活。看板目的是平衡大家的工作量，加速价值流动。 看板的起源：（1）      第一个软件看板系统始于2004年，在微软公司XIT软件维护团队中实施。（2）      kanban方法指的是2006年 -- 2008年间在Corbis公司涌现的渐进增量式的过程改进方法学。（3）      作为一种变革技术的看板方法，自2007年敏捷大会展示后，开始广受社区关注。（4）      2010年，看板方法的创始人 David Anderson 发布了其著作《看板方法：科技企业渐进式变革成功之道》。 看板的6大核心实践是：（1）      可视化 —— 如果有条件，尽量全价值流。将整个团队所有工作任务都在看板中显示出来， 从想法、需求，到分析、研发、测试、完成等，都显示在看板中，每个状态还可以有子状态。所有人都可以看到每个任务的状态、每个成员的工作。（2）      限制在制品 —— 基于你瓶颈的承受能力。每个团队、每个角色都有自己的工作上限，而且看板的工作量是拉动式的，那么根据成员和能力，就可以确定出每个状态的WIP。这样就能显而易见地看出瓶颈在哪里，可以有针对性地优化瓶颈。优化瓶颈这项任务，也可以作为看板中的一项任务，体现出来。这样不断地明确瓶颈、修复瓶颈、增加输入量、修复下一个瓶颈循环，让输入和输出平衡，提高团队的工作效率。（3）      管理工作流 —— 监控、度量、全局优化。首先是理想状态下，团队协作，看板中的任务有序流动去完成。实际工作中，会有等待、积压等的情况出现，通过看板，可以快速定位到需要优化的点，先去做可以去拉动到下一环节的工作。对于资源和问题的平衡，可以结对工作解决问题，也可以主动协助他人完成工作。（4）      制定清晰的过程准则 —— 完成的定义、团队准则。团队对于完成，要有统一的定义，也就是DoD（Definition of Done）。对于大家工作的行为规范和要求，也要有团队的统一准则，大家都遵守同样的要求。尤其当出现需要解决的问题时候，大家知道应该遵守什么样的准则去处理，而不是手忙脚乱。当遇到有特殊的紧急问题需要处理时，那么可以使用看板中的紧急通道，就像高速路上的紧急车道一样，大家齐心协力把紧急通道上的任务优先做完。（5）      实现反馈机制 —— 不要等待反馈。反馈机制就像PDCA环，要持续进行，要主动进行。从三个级别上进行反馈：个人或团队自身反馈，这在每日晨会中就进行了；个人或团队间反馈，这在定期的团队内部会议中可以进行；向你的客户寻求反馈，定期与客户沟通。（6）  协作式改进，实验性进化 —— 使用模型和科学方法。看板是要团队协作，在协作中，不断优化不断改进，也就是Review Kata、改进 Kata、每日Kata。实现标准化的过程改进。 王老师的讲解深入浅出，辅助了卡通形象，非常生动有趣。看板简单实用，方便大家在工作中应用。谢谢王老师！

收藏，很不错