叶青-工业嵌入式DevOps转型实践

目录 1 2 前言 持续交付X.0 3工业DevOps建设挑战及实践 4Q&A 简介： •14+敏捷相关经验，资深咨询师 •覆盖业务敏捷、团队敏捷、DevOps •精通SAFe、Scrum、KANBAN、Designthinking、LeanUX、LeanStartup等 •熟悉金融业、制造业、游戏行业的业务模式及IT结构 •作为专家级咨询顾问主导大型机构敏捷转型、DevOps建设 咨询与实施案例（汽车）： •前言：DevOps发展趋势 敏捷\DevOps兴起 持续交付1.0持续交付2.0 持续交付X.0 •CMMI •敏捷转型 •体系融合 •更多团队开始敏捷 •互联网、金融行 •甲方认可 •制造业 •汽车 •持续交付适用 •证明IT团队的价值 •精打细算 于工业领域 •效能提升提出进 •多数团队的认可， 业转型 •团队试点 一步需求 在公司全面推广 •不计成本 •团队的认可 •新能源 •效能提升 小成就 破土萌芽 生长花开小成就成熟新赛道 小成就 新趋势 •CMMI •Scrum •UserStory •DOD/DOR •LeSS •CI/CD •Docker •Jenkins •落地了Scrum、 KANBAN； •搭建了完整的开发到发布的工具链 •代码解耦 •分支 •git •咨询 •带教 •沟通能力 •试点带教 •从0至1 •规模化实践 •度量体系 •规模化推广 •工业领域的工具： •敏捷与DevOps的落地尝试 •总结了一套工业领域的实践 •敏捷与DevOps，线下与线上相结合的推广落地方法论 小成就 •与运营价值流结合 •总结了一套动态指标建设体系 •DevOps落地解决方案 •资源配置优化 •DevOps用起来 技能养成 从0至1落地推广落地 监测 运行 快速实现/验证 构建 业务收益 收集 维持/继续增长 持续交付 精炼 决策 X.0 价值探索 调整 研发价值流 锚定 追求资源 度量 最优配置 优化 运营价值流 共创提问 第一次工业革命 蒸汽技术革命 第二次工业革命 电力技术革命 第三次工业革命计算机及信息技术、新能源技术等革命 第四次工业革命 人工智能、虚拟现实、量子通信等 18世纪60年代-19世纪40年代 19世纪60年代后期 20世纪四五十年代开始 21世纪-22世纪中叶 •造车4.0 第一次革命 第二次革命 第三次革命 第四次革命 机械化生产-蒸汽动力 电气化生产-燃油动力 自动化生产-电池动力 规模化自动生产-智能化 对应于工业1.0时代。在这个阶段，汽车制造主要依赖机械化生产，通过蒸汽动力驱动机器取代人力，从而实现了手工业从农业中的分离，正式进化为工业。 对应于工业2.0时代。在这个阶段，电力开始广泛应用于汽车制造中，取代了蒸汽动力，使得零部件生产与产品装配实现了分工，汽车工业也因此进入了大规模生产的时代。 在这个阶段，自动化技术开始被引入到汽车生产中，大大提高了生产效率和制造精度。机器人和自动化设备取代了部分人力，使得汽车制造更加高效和质量可控。 在这个阶段，互联网化和智能化成为了汽车发展的主要趋势。通过引入物联网、大数据、人工智能等先进技术，汽车制造实现了高度数字化和智能化。 未来汽车就是一个智能移动空间 车外系统泛互联网类业务 互联网营销与品牌管理： 汽车厂商通过监测互联网上的媒体动态，了解消费者对汽车产品的关注点和需求，以优化营销策略。 互联网金融服务： 包括汽车贷款、保险、融资租赁等金融服务，通过互联网平台实现线上申请、审批和放款，提高服务效率和用户体验。 智慧出行与共享服务： 如网约车、共享单车等，通过互联网平台实现车辆资源的共享和优化配置，满足用户多样化 车内应用层软件开发： 主要涉及车辆的高级软件部分 车联网（V2X）系统： 传统软件开发还可以用于开发车联网系统，这些系统通常基于互联网协议和标准，可以实现车辆与周围环境和其他车辆的通信和协作。 车载娱乐系统： 传统软件开发可以用于开发车载娱乐系统，如音频播放器、导航系统等。这些系统通常基于通用的操作系统和开发工具，并与用户进行交互。 智能驾驶辅助系统： 传统软件开发也可以用于开发智能驾驶辅助系统，如碰撞预警、自动泊车等。这些系统通常基于机器学习和人工智能技术，可以 进一步提高车辆的安全性和舒适性 嵌入式开发： 主要涉及车辆的硬件和底层软件部分 实时操作系统（RTOS） RTOS用于管理嵌入式系统的任务和资源，以确保系统的实时性和可靠性。在汽车领域，RTOS通常用于控制车辆的各种功能和系统 传感器和执行器 传感器用于监测车辆的状态和环境，而执行器则用于控制车辆的各种动作。嵌入式开发需要编写软件来驱动这些传感器和执行器，并确保它们能够正确地工作。 汽车电子控制单元（ECU） ECU是汽车的大脑，负责控制车辆的各种功能和系统，如发动机控制、悬挂系统、刹车系统等。嵌入式开发需要对硬件进行设计和编程，以确保ECU能够正确地控制这些系统。 。 的出行需求。 度量 收益与效能脱离 四大挑战 文化 组织心智 不一样的工具不一样的孤岛 DevOps无法落地 工具 不要指望一蹴而就：从DevOps落地蓝图规划开始 不要缺失持续的带教体系 不是工具不行，而是推进方式出了问题 基于AUTOSAR标准的工具数量是相当多的，但具体数量可能因不同的供应商、开发商和应用领域而有所变化。一些典型的基于AUTOSAR标准的工具包括VectorCANoe、ETASINCA、dSPACE ControlDesk等 2.0：RTE环境配置自动化。 自动： 1、解析.arxml；2、结构化字段，形成 解析 .arxml 映射矩阵定义基线 去同求异 映射矩阵；3、识别稳定要素，定义基 线；4、去同求异，灵活配置；5、即时 构建，快速反馈 问题反馈 灵活配置 预编译 RTE 生成RTE 定时触发 连线配置 .arxm 添加配l置库 问题反馈 1.0：用最快的速度获取反馈，即使失败， 也能快速发现并定位问题。 自动： 1、分析ISOLAR-AB中的.arxml文件存放路径，并添加到配置库管理工具中管理 2、建立组织级流水线，从配置文件修改即可触发至预编译的job，提交即触发 手工：连线配置 预编译 RTE 生成RTE 定时触发 •工具挑战：落地过程——局部自动化 •工业领域DevOps转型挑战及实践 度量 收益与效能脱离 动态SPICPI 四大挑战 文化 组织心智 不一样的工具不一样的孤岛 DevOps无法落地 工具 不是工具不行，而是推进方式出了问题 1、整体规划 启动会议 2、基础设施建设 访谈调研 指导种子教练，并形成SOP 方案设计及发布 确定种子教练及虚拟赋能机制 3、标准化 培训及宣贯SOP内部全面推广 4、内部落地 缺乏全局视角：各个团队可能只关注自己部门的利益和需求，而忽视了整个组织或项目的全局视角。这可能导致在推进标准规范落地的过程中出现局部优化而全局受损的情况。 •推进方式：标准规范用得不好，就是“虚假繁荣” •标准是规范不了团队所有人员的操作， •标准是基线，识别偏差 •偏差很多时候是好事，取其精华，去其糟粕。 •糟粕需要治理，精华需要汲取 •如果一味强推，会是什么后果，如下图： •DevOps要成功落地并不容易，需要一整套科学推进的方法论落地 度量 收益与效能脱离 动态SPICPI 四大挑战 文化 组织心智 不一样的工具不一样的孤岛 DevOps无法落地 工具 不要指望一蹴而就：从DevOps落地蓝图规划开始 不要缺失持续的带教体系 不是工具不行，而是推进方式出了问题 在复杂环境下，肯定会做预测，传统的燃尽图可以跟踪Sprint的中进度变化，但是整体项目进度偏差？成本偏差？如何度量，始终是个难题，其实在PMP中本来就有答复，但是传统SPI\CPI指标，是基于不变的初始整体计划作为基线，导致数据不敏感，失真等问题，在DevOps中，我们落地了SPI、CPI、EV。 成本绩效指数（CostPerformanceIndex,CPI），截止到某时点衡量成本绩效的一种指标，也就是实际每花一元钱，完成做了多少钱的事（花钱的效率），CPI=EV/AC进度绩效指数（SchedulePerformanceIndex,SPI），截止到某时点衡量进度绩效的一种指标，也就是实际完成的工作量与计划完成工作量之比，SPI=EV/PV 计划价值（PlannedValue,PV），截止到某时间点计划要完成工作量的价值，也就是计划要做多少事； 挣值（EarnedValue,EV），截止到某时间点实际已经完成工作量的价值，也就是实际做了多少事； 实际成本（ActualCost,AC），截止到某时间点实际已经发生的成本，也就是实际花了多少钱； 需求 开发 测试 验证 发布 活动时间等待时间 1天2天4小时4小时1天 2周（可行性等待） 1周（审批等待） 2周（IT支持等待） 1周（测试等待） 流动时间=47天总活动时间=5天流量效率=11% DevOps工具链，优化了哪些步骤？是否真正的端到端？互联网和传统 可改进点 a需求处理效率 b变更电子化c 变更 e白盒自动化f黑盒自动化测试g d开发分支 缺陷 测试 企业区别在那里？ 1 问题 需点求追溯 5 2产品需求 3产品版本计划 4代码审核墙 质量门禁6 测试报告 7 制品发布 吸引顾客 快速报价 贷款申请 资格验证 确定贷款信息 复刻贷款 设置付款条件 还钱 结清贷款 还款加利息 行业务 核心银 级业务 信用评 放业务 贷款发 渠道 DVS 基于业务假设转换为提供客户价值的活动序列，需要的技术解决方案步骤 OVS 是向客户交付 产品或 服务所需的一系列活动 快速报价 贷款申请 资格验证 发放贷款 获取收益 活动时间等待时间 1天2天4小时4小时1天 1天（发放审批） 1天（信用评级） 1天（审批等待） 1天（报价核算） 流动时间=9天总活动时间=5天流量效率=56% 可改进点 a资源的合理配置b客户旅程地图c闭环反馈d持续改进 DevOps工具链，识别运营价值流并改进 问题 1资点源配置 2业务流程3收益可视化 4用户满意度 •运营价值流 运营价值流（OVS）是向客户交付产品或服务所需的一系列活动。 消费者提供保险产品或履行电子商务销售订单， 电商行业。 制造将原材料转化为客户购买的产品，制造业。示例包括消费类产品、医疗设备和复杂的信息物理系统。 软件产品提供和支持软件应用程序和解决方案，以出售给最终用户或企业，软件行业。示例包括ERP系统、SaaS以及桌面和移动应用程序。 支持价值流是各种重复性和内部支持活动的端到端工作流，支撑类行业。示例包括员工招聘、建立和执行供应商合同、执行年度审计以及完成企业销售周期 •工业领域DevOps转型挑战及实践 度量 收益与效能脱离 动态SPICPI 四大挑战 文化 组织心智 不一样的工具不一样的孤岛 DevOps无法落地 工具 不要指望一蹴而就：从DevOps落地蓝图规划开始 不要缺失持续的带教体系 不是工具不行，而是推进方式出了问题 文化变革：组织心智 文化变革：组织心智 75%的传统企业转型为什么会失败，不是工具的问题，不是流程的问题，不是组织结构的问题，企业转型最难的从来不是用什么招式，而在于看不见、摸不着的组织心智。一旦形成，难以改变。 中国DevOps社区峰会2024·上海