任务背景公司的集群架构已越来越robust(健壮), 但应用服务器上的代码升级和新产品的发布效率不高，甚至有代码发布到生产服务器后BUG太多，客户反应强烈的情况出现。公司的产品项目从需求分析,设计,研发,代码测试到发布上线的流程有问题，开发者开发的代码提交后有BUG没有反馈，运维也没有在测试环境下做有效地压力测试, 都是导致问题的原因。所以我们需要运用devops(开发与运维工作流有效结合)思路，通过CICD(持续集成 持续交付)来实现自动化的集成与交付工作。CI/CD（Continuous Integration/Continuous Deployment）是一种软件开发实践，旨在通过自动化的方式频繁地构建、测试和发布软件。CI/CD 可以显著提高软件交付的速度和质量，使团队能够更快地响应市场变化和用户需求。CI（Continuous Integration，持续集成）：持续集成是一种开发实践，要求开发者频繁地将代码集成到主分支，并且每次集成都伴随着自动化的构建和测试。这种方法可以快速发现集成问题，确保代码库的稳定性。CD（Continuous Deployment/Continuous Delivery，持续交付/持续部署）：持续交付是在持续集成的基础上，将通过测试的代码自动发布到生产环境或用户环境。持续部署是持续交付的下一步，指的是代码在通过所有测试后自动部署到生产环境，几乎不需要人为干预。任务要求1, 使用git提交代码到仓库2, 实现自动代码发布系统任务拆解1, 了解DevOps的发展历程与思想2, 学会git版本控制3, 会使用github公有仓库与gitlab私有仓库4, 了解CICD5, 使用jenkins实现自动发布学习目标了解DevOps的发展历程了解版本控制掌握git的安装掌握git的基本使用DevOps的发展历程DevOps是一种实现Dev(开发)与Ops(运维)工作流有效联合的思想。那么，我们为什么要了解什么是DevOps呢？因为我们下面所讲的课程内容最终的目的就是为了体现开发与运维有效结合方法，越是高级应用，越接近我们DevOps思想所阐述的做事方法。首先我们先来了解一下软件开发层面从软件开发出现时起至今，都经历了些什么？原始开发时代时代特色：软件程序员（单一物种）能做到一专多能，是多面小能手。软件程序员的公司那时还被称作实验室，程序员那时被叫做科学家。为了开发出一套优秀的软件，程序员们必须深入了解他们需要的应用相关的所有问题。他们必须清楚知道这个软件应用在什么场合，这个软件是必须在什么系统上运行。本质上说，程序员对所要开发的软件的所有环节都有透彻的了解，从规格说明书编写、到软件开发、到测试、到部署、再到技术支持。随着技术发展，人类需要软件程序员在软件开发方面具备更快的速度、更全面的功能，以便获取更多的用户等而软件程序员对自身的要求是一专多能，多面小能手，这样就制约了在软件开发方面的开发速度及添加更多功能的可能性。当然人类不会允许这种情况出现的，如果因为一个软件程序员开发速度跟不上，那么就要想办法进行优化，把软件程序员的工作进行细化、分配。在分配的过程中，就逐渐衍生出了类软件程序员的新物种，例如：软件工程师、网络管理员、数据库开发者、网页开发者、系统架构师、测试工程师等。随时新物种的诞生，被各物种划分的领域门头林立，各自为王，很少进行交流互动，只有在迫不得已的时刻才会进行沟通。由于新物种之间的分隔，导致客户的项目开发过程中出现的问题一拖再拖，无法进行有效解决，更无法在交付日期进行准时交付，让客户付出了昂贵的开发代价，甚至项目以失败告终。面对这种混乱的情况，有人想到了一种开发模式：瀑布开发。瀑布开发时代时代特色：各物种一专、多人瀑布流式协作这是一个非常了不起的创意，因为它利用了不同团队的开发者们只在必须的时候才进行沟通的这个事实。当一个团队完成了他们的工作的时候，它就会和下游的团队进行交流并把任务进行往下传，如此一级接一级的传递下去，永不回首。这种方式在一段时间内发挥了效用，但很快，一如既往，客户又开始提出更多的诉求。他们希望能够更多地参加到整个软件的开发流程中来，不时的提出他们的建议，甚至在很晚的时候还提出改需求这种丧心病狂的事情来。结果就是如大家有目共睹的事实一样，软件项目非常容易失败这个说法已经作为一个行业标准被人们所接受。数据表明超过50%的项目最终都是以失败告终的。更可悲的是，在当时看来，人们对这种情况是束手无策。值得庆幸的是，每一个时代总会有那么几个思想开放的英雄如漆黑中的萤火虫般冒出来。他们知道这些不同团队的开发者们必须要找到一个可以协同工作、进行交流、并且能够弹性的向客户保证对方将会拿到最优的解决方案的方式。这就是敏捷开发。适合于比较成型的业务模型，适合于工业设计、制造行业都可以。敏捷开发时代时代特色：物种一专、多人有效沟通、 协作、 拥抱变化最早可以追溯到1957年，伟大的约翰·冯·诺依曼和同行们的努力。但是我们最终却是等到2001年才收获到革命的果实，当时行业的十多个精英创造出了如今闻名世界的“敏捷宣言”。敏捷宣言十二条原则：首要任务是通过尽早地、持续地、交付可评价的软件来使客户满意乐于接受需求变更，即使是在开发后期也应如此。敏捷过程能够驾驭变化，从而为客户赢得竞争优势。频繁交付可使用的软件，交付间隔越短越好，可以从几个星期到几个月。在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。围绕那些有推动力的人们来构建项目。给予他们所需的环境和支持，并且信任他们能够把工作完成好。与开发团队以及在开发团队内部最快速、有效的传递信息的方法就是：面对面的交谈。可使用的软件是进度的主要衡量指标。敏捷过程提倡可持续发展。出资人、开发人员以及使用者应该总是共同维持稳定的开发速度。为了增强敏捷能力，应持续关注技术上的杰出成果和良好的设计。简洁，做工作量减法。最好的架构、需求和设计都源自自我组织的团队。团队应该定期反思如何能变得更有战斗力。

一、业务背景我们项目中收支记录、账本数据需高频并发写入系统 。此前，用户记账操作成功率低至 70%，大量用户因记账失败、体验差而流失，严重阻碍业务发展 二、原因分析 全量数据一次性提交，超出系统承载能力当用户批量录入多条记账记录（如导入账单、批量补记）时，前端未做分批处理，直接将所有数据（可能达数百条）通过单次请求提交至后端。后果：单条请求数据量过大（如 100 条记录的 JSON 体积超过 1MB），导致网络传输超时（尤其弱网环境下）；后端接口可能因 “单次请求数据量超限” 直接拒绝（如网关层设置请求体大小限制），或处理时内存占用激增，触发超时熔断未适配设备性能差异，固定逻辑引发低端机崩溃不同设备（如高端旗舰机 vs 入门级手机）的 CPU、内存、网络能力差异显著，但前端采用统一的处理逻辑缺乏操作进度反馈，用户误判失败批量记账时，前端未展示实时进度（如 “已完成 30%”），用户在等待过程中因 “无响应” 误以为操作失败：可能手动刷新页面或重复提交，导致重复请求冲突（如同一笔记录被提交两次），后端因 “数据重复” 返回失败；长时间无反馈触发用户焦虑，直接关闭页面，导致未完成的操作中断三、解决思路动态分批处理：针对全量数据一次性提交超出系统承载的问题，采用 “按需拆分、动态调整” 策略进度可视化与交互反馈：针对用户因无反馈而误判失败的问题，通过 “实时感知、明确反馈” 增强操作透明度异常处理与重试机制：针对网络波动、系统异常导致的写入失败，通过 “容错兜底、自动重试” 降低失败概率四、解决方案4.1 数据分批处理（基础分批逻辑）当用户触发大量记账数据录入操作时，利用 ArkTS 的异步任务调度能力，将数据按固定批次拆分。通过迭代数据数组，每次截取指定数量（初始 20 条）的数据作为一批，调用封装的写入方法逐批处理，避免一次性加载全量数据导致内存溢出或 UI 阻塞// 写入方法async function batchWriteAccountingData(data: AccountingDataItem[]): Promise<void> { const batchSize = 20; for (let i = 0; i < data.length; i += batchSize) { const batch = data.slice(i, i + batchSize); await writeBatchData(batch); // 异步写入，避免阻塞主线程 }}// 记账明细interface AccountingDataItem { id: string; amount: number; type: 'income' | 'expense';}4.2 动态分批调整（结合设备状态）借助鸿蒙系统提供的 hidebug 模块获取设备内存占用信息，实时判断设备内存状态。定义内存阈值（需结合实际设备测试确定），动态调整每批数据量：内存充裕时增大批次（如 30 条）以加快处理；内存紧张时减小批次（如 15 条）import { hidebug } from '@ohos.hidebug';async function getDynamicBatchSize(): Promise<number> { const memoryUsage = hidebug.getNativeHeapAllocatedSize(); // 根据实际设备性能测试调整 const lowMemoryThreshold = 1024 * 1024 * 200; // 200MB const highMemoryThreshold = 1024 * 1024 * 500; // 500MB if (memoryUsage < lowMemoryThreshold) { return 30; } else if (memoryUsage > highMemoryThreshold) { return 15; } return 20;}async function dynamicBatchWrite(data: AccountingDataItem[]): Promise<void> { const batchSize = await getDynamicBatchSize(); for (let i = 0; i < data.length; i += batchSize) { const batch = data.slice(i, i + batchSize); await writeBatchData(batch); }}4.3 进度可视化与交互反馈（UI 组件集成）在记账操作页面，使用 ArkTS 的 Progress 组件实时展示写入进度。通过计算已处理数据量与总数据量的比例，动态更新进度条数值。同时，结合 Toast 或弹窗反馈关键状态（“数据写入中”“写入完成”“网络异常重试” ），增强用户对操作流程的感知@Entry@Componentstruct AccountingWritePage { @State progressValue: number = 0; @State isWriting: boolean = false; private totalDataCount: number = 0; build() { Column() { Text('记账数据写入中') .fontSize(20) .margin({ bottom: 10 }); Progress({ value: this.progressValue, total: 100 }) .width(300) .height(20) .margin({ bottom: 20 }); if (this.isWriting) { Text(`已完成 ${this.progressValue.toFixed(1)}%`) .fontSize(14) .color(Color.Grey); } else { Button('开始写入') .onClick(async () => { this.isWriting = true; const data = await fetchAccountingData(); this.totalDataCount = data.length; await this.batchWriteWithProgress(data); this.isWriting = false; // 写入完成反馈 Toast.show({ message: '记账数据写入完成！' }); }); } } .padding(20) .width('100%') .height('100%') .justifyContent(FlexAlign.Center); } private async batchWriteWithProgress(data: AccountingDataItem[]): Promise<void> { const batchSize = await getDynamicBatchSize(); const totalBatches = Math.ceil(data.length / batchSize); let processedCount = 0; for (let i = 0; i < data.length; i += batchSize) { const batch = data.slice(i, i + batchSize); await writeBatchData(batch); processedCount += batch.length; this.progressValue = (processedCount / this.totalDataCount) * 100; // 业务逻辑 await new Promise(resolve => {}); } }}4.4 异常处理与重试机制在分批写入过程中，捕获网络请求异常、系统写入失败等错误。通过设置重试次数（如 3 次），针对失败批次自动重试；若重试仍失败，记录失败数据并反馈给用户，支持手动触发重试或跳过失败项const MAX_RETRY_COUNT = 3;async function writeBatchDataWithRetry(batch: AccountingDataItem[], retryCount: number = 0): Promise<boolean> { try { await writeBatchData(batch); // 写入 return true; } catch (error) { if (retryCount < MAX_RETRY_COUNT) { // 重试 return writeBatchDataWithRetry(batch, retryCount + 1); } else { // 记录失败数据，可存入本地缓存待后续处理 saveFailedBatch(batch); console.error('写入失败，已达最大重试次数：', error); return false; } }}// 在分批写入循环中替换为带重试的方法async function dynamicBatchWrite(data: AccountingDataItem[]): Promise<void> { const batchSize = await getDynamicBatchSize(); for (let i = 0; i < data.length; i += batchSize) { const batch = data.slice(i, i + batchSize); await writeBatchDataWithRetry(batch); }}五、方案总结本方案通过以下核心技术解决性能问题：动态分批处理技术，通过结合设备状态动态调整数据分批大小，形成一套灵活、高效的动态分批处理机制，可复用至其他需批量数据处理的业务场景，优化数据写

华为云软件开发生产线CodeArts是一站式、全流程、安全可信的云原生DevSecOps平台，覆盖需求、开发、测试、部署、运维等软件交付全生命周期环节，为开发者打造全云化研发体验。华为云CodeArts目前已上线28款研发工具，服务于300多万开发者，应用于10多个行业，覆盖开发全场景。2025年2月，CodeArts发布了代码托管、部署、测试计划相关新特性，具体内容如下： 代码托管 CodeArts Repo新特性批量导入外部仓库新增支持Gitlab、自建Gitlab、Gitee代码托管平台代码仓的导入体验优化支持.cn域名访问页面创建合并请求时采用时间倒序拼接的提交记录生成默认描述部署 CodeArts Deploy新特性执行部署任务支持通过Assume委托调用体验优化主机连通性验证失败时，前端添加悬浮展示失败原因测试计划 CodeArts TestPlan新特性一个测试用例可以关联多个需求特性编号支持文件导入刷新开放测试用例步骤中图片的上传接口和创建特性目录的接口测试执行页面支持上传附件新增URL编解码函数导入导出支持特性目录层级支持批量编辑用例属性字段（类型、标签）质量看板支持进度报表，可基于特性目录进行统计测试进度体验优化接口测试、检查点下拉框中比较符展示优化手工测试套件执行时支持对用例进行检索测试设计生产用例和归档用例页面优化测试设计用例编号规则功能优化测试步骤页面优化目前，华为云CodeArts已携手百万级开发者，在政府、物流、金融、教育、制造等10多个行业落地，助力企业构建了敏捷、高效、安全的数字化生产模式。使用华为云CodeArts，中国海油构建了供应链一体化数字化平台，研发工时节省了30%，智能油田管理系统集成、调试、部署时间从1周缩短为1天。中国邮政储蓄银行通过使用华为云CodeArts盘古助手打造智能开发平台，代码生成采纳率超30%，单元测试代码采纳率超60%，已自动生成29万余行高质量代码，高效支持超过200个应用系统的开发，实现了更好的智能化开发体验。未来，华为云CodeArts将积极增强软件开发的全流程智能协同，不断实现智能化创新，提升全流程研发效能，为开发者创造更多的业务价值，促进中国软件生态的繁荣。

如何让单选框选中后下次进入后还能保持选中啊？或者如何让网页自动判断单选框被选择过？

在近期Gartner发布的——企业机构在2022年需要探索的重要战略技术趋势中，“Composable Applications组装式应用”占得一席。何以如此？这背后，业界对可组合性的追求不容忽视。什么是组装式应用？“组装式应用由以业务为中心的模块化组件构成，具备更易使用和可重复使用的代码，可加速新软件解决方案的上市时间，并释放企业价值。”具体如何实现组装式应用呢？Gartner提出了“封装业务能力”（Packaged Business Capability，简称PBC）这个概念作为组装式应用的核心。与微服务架构不同的是，前者交付的依然是封装应用，而基于PBC的组装式应用交付的是一个数字化的平台。在这个平台中，PBC更像一个个原子，而组装式应用是把这些原子重新组合起来的一个个分子。理想状况下，业务部门可以从云端或是企业的应用商店里去下载所需要的PBC。PBC可以是一个对象的数字孪生或者是某一个小功能，这个对象或者功能被模块化之后，业务用户就可以根据自己的需要把PBC下载下来，在合适的组合平台上将PBC组装到应用程序中，如用低代码的方式构建出定制化的应用。有利于更安全、更高效和更快的变革在不断变化的业务环境中，业务适应性需求将引导企业转向使用支持快速、安全和高效应用变化的技术架构。组装式应用增强了这种适应性，而采用可组合方法的企业机构在新功能的实现速度上将比竞争对手快80%。在充满不确定性的时代，可组合的业务原则帮助企业机构驾驭对业务韧性和增长至关重要的加速变化。组装式应用引入模块化的理念，使得技术和业务团队可以更敏捷、更有效地重用密码。企业如何去提高商业的韧性和效率，本质是一个如何创新地利用技术来加速数字化的问题。对于组装式应用的重要性，Gartner是这样说的：“没有它的现代企业机构可能会失去在市场中的前进动力和客户忠诚度。”实践出真知，提升敏捷性、减少重复劳动从各个行业来看，组装式应用已被许多组织所应用和推广。例如金融行业，美国Ally Bank已经创建了具备可重复功能的PBC，如欺诈警报功能，其融合团队可以在低代码环境中进行组装，节省了超过200,000小时的人工工作。在运动用品制造行业，阿迪达斯使用可组合应用程序，缓解融合团队囿于低价值重复工作的泥淖，从而使解决方案数量增加了近十倍，同时缩短了数周的交付时间。可组合性，已是近些年的关注重点从Gartner发布的《2021年企业低代码平台魔力象限》中已可看出，可组合性已为各行业所认可：采用应用程序组合技术，以加快程序的融合效率。低代码应用平台LCAP是推动应用服务、功能和能力的可组合性关键技术之一。此外，Gartner还在2022年十二大战略趋势的报告中提及，到 2024 年，新 SaaS 和自定义应用程序的设计准则将是“可组合的API优先或仅API”。通过快速、应用程序编程接口 API驱动的集成，为组织提供敏捷性，也使各种应用程序之间能够实现无缝通信。各组织均应重视可组合性与敏捷性的建设具备可组合性的应用程序，将为各个组织的办公模式带来更大创新、提供更多的敏捷和便捷，各部门之间的协作配合也达到更高水平：开发团队可以将精力集中在速度和创新上，而运营团队可以更多地把时间用于进行后端更新、合规性发布和测试。以上均可在不影响前端或后端操作的情况下完成，因此开发、运营、营销、电子商务、数据、财务和其他领域，都可以保持一致并成为一个敏捷平台、协同工作，不再存在孤岛，产品也可以快速有效地推向市场。重视普及组装式应用的同时，商机同在对于做to B 业务的厂商来说，也不妨围绕顺势在云计算时代形成基于API的“被集成能力”。在《中台战略》这本书中提到一个非常重要的观点——“API即服务”，在万物皆可云的时代，如果客户愿意将自己的应用构建在SaaS上，只要组织将自己的API集成到第三方伙伴的业务中，最终客户每订阅一份服务，API就有机会获取一份相应的客户收入分成。这也就形成了“订阅”的商业模式。因此，在充分关注和重视组装式应用成为战略趋势、借此达到新功能的实现速度上比竞争对手快80%的同时，各组织还可留意组装式应用的业务潜在商机，为新年业务更添浓墨重彩的一笔。*本文转自百家号-补丁铺子，原文链接：https://baijiahao.baidu.com/s?id=1722987557049446359&wfr=spider&for=pc，如有侵权立即删除。

版本：20.9.0文档上描述的是接口仅支持 token 认证的方式，默认30分钟，这样获取镜像API列表是可以的，但是如果我同时要通过 docker pull 的形式来拉 swr 上的镜像，有统一的认证方式吗？华为云cce 提供了长久的 AK SK 来同时支持 API 接口和 swr 认证，请问敏捷版私有部署怎么获取？https://support.huaweicloud.com/usermanual-swr/swr_01_1000.html

1.张老师昨天讲的用户故事地图，对产品迭代规划很有用，DevCloud有用户故事地图的工具么？【张老师答复】DevCloud暂无用户故事地图管理工具，一般大家在线下讨论利用便利贴贴到墙上完成用户故事地图分析，最后录入到项目管理工具中进行跟踪，在录入时需要给每个用户故事打特性和优先级等标签。2.华为的哪个产品线在用这种开发模式？【张老师答复】涉及云服务产品研发的基本都在用敏捷DevOps开发模式。3.燃尽图具体是做什么的，按照什么维度管理，影响地图呢？【张老师答复】燃尽图按照每个迭代以故事点维度进行统计，共涉及两条曲线：理想和现实，通过两条曲线实际情况对比来及时识别项目进展是顺利还是有风险，交付进度迟缓的话需及时调整交付策略；影响地图可以用传统的思维导图工具进行Why->Who->How->What分析。4.task的状态都有哪些？如何在需求故事看板泳道下合理的展示任务看板？【张老师答复】系统默认有6种状态，工具支持用户自定义状态。由于用户故事Story都会拆解成多个Task进行管理，建议站会重点审视Task状态变化，后续通过使用高级自动化能力，当一个Story下所有子Task都关闭，该Story会自动变成关闭状态，无需再手动处理Story状态。5.story和task怎么区分呢【张老师答复】它们是父子关系，一个Story可拆解成一个或多个Task，每个Task只能分配给一个人去处理。6.我是重度jira使用者，可以讲devcloud把大部分需要scriptrunner定制的内容都做了，模板也很贴心。我可以有rest api来爬取我项目里面的issue信息么？我需要做大数据分析。【张老师答复】DevCloud提供对外OpenAPI来统计自己项目里的相关信息。7.devcloud的燃尽图不能按照任务进行展示么？【张老师答复】燃尽图是统计故事点，只有用户故事Story才可以录入故事点信息。8.工时在实际维护过程中数据的有效性怎么确保高呢？【张老师答复】建议多在团队内宣传确保大家每天下班前录入工时，另外也可在每天站会时快速审视工时报表及时识别无效工时。

1.很多时候业务的变化，需求的插入和临时优先级提高，那这种情况就不能按照之前计划好的迭代走，这种一般是如何去处理呢【张老师答复】这是一个常见的情况，个人建议如下：（1）规划好的迭代周期强烈建议不要延期，中间出现高优先级需求插入，可以移除对等故事点低优先级工作到下一个迭代计划中，保证整体故事点不变，计划不受影响；（2）如果迭代规划预留了部分缓冲时间，可评估插入需求工作量是否能抵消缓冲时间，保证迭代计划不变；2.产品原型是必需的吗？一般在scrum迭代的什么活动或者时间点输出？【张老师答复】针对系统涉及大量前端页面场景，建议提前准备好高保真原型图。个人建议当前迭代开始后，UCD和PO就要准备启动下一个迭代计划的原型图设计。3.故事点估算一般在什么阶段进行？【张老师答复】一般可能在迭代计划会议中进行；当然团队也可根据实际情况专门预定一个评估会议对一个或者近期几个迭代的用户故事整体进行故事点评估。4.迭代的演示会是内部演示么？是否可以包括用户？【张老师答复】迭代验收会议建议邀请用户代表参与验收；它不止是内部演示，不过无需准备正式的演示文档。5.华为云在规划产品时除了今天说的这些方法还有没有其它方法？你们估算也用了打扑克吗，这样的估算感觉太费时了，老师您怎么看？【张老师答复】估算扑克是敏捷推荐的故事点估算工具，可能也有其它估算方法，不过我个人经历主要用这个工具。团队可以探索更适合自己的高效评估方法。6.PO获取到需求后，要估算故事点吗？【张老师答复】不用立即估算或者一次性全部估算完，按照实际迭代计划安排有序组织相关会议进行估算。7.故事点就是我们wbs拆分之后说的任务吧，故事点相当于需求？【张老师答复】故事点是基于用户故事(Story)进行估算。传统项目管理WBS拆分任务并没有明确对应用户故事，具体看WBS拆分的单个任务是否可以在一个迭代中完成。8.探究性的任务应该怎么开展比较好？【张老师答复】敏捷开发模式更适合探索性任务，迭代周期可以更短，确保多和用户保持沟通，及时纠正航向。9.张老师有没有遇到过身兼多职的情况【张老师答复】遇到过Scrum Master由团队开发主管、项目经理或者测试人员兼任情况，建议Scrum Master专人负责，也可以团队成员轮值。10.用户故事的独立性如何理解？一个大的需求拆解为多个用户故事时，必然会有关联关系吧？【张老师答复】独立原则要求编写的用户故事之间应当是相互独立而不是相互依赖的，和故事之间的关联关系不冲突，用户故事的相互独立可以降低需求的优先级排序和迭代计划制定的难度。

*学习敏捷上云开发要点，提升就业机会**体验Java,Node.JS,C#真实应用上云开发案例**收获华为无线耳机、拍立得、机械键盘、京东卡等丰富好礼* △适合人群：对敏捷DevOps开发有转型需求，渴望提升云上研发能力的开发者△活动时间：2022.5.16-2022.6.30△活动参与方式： 报名活动：点此链接，填写报名表即完成报名，点此了解活动详细规则；加入学习社群：完成本报名后请务必扫码进入学习群，专家全程跟踪辅导，伙伴比肩共同进步； 完成学习任务，赢取积分奖励本帖为邀请好友完成上云实践截图反馈帖。邀请好友在三个代码上云实践中任选一个，完成至部署成功，请好友按要求截图回复至本帖中。回复要求：好友华为云账号+邀请人华为云账号+截图（截图中包含部署成功界面且需露出好友本人的华为云账号）每增加一个好友的有效回复，可增加10积分每个好友在三个实践中选择任一个完成即可，每个好友只记一次积分，多次完成、多次回复不重复计入积分。加油~~ 

获奖名单公布各位小伙伴们久等啦，获奖名单已经出炉，恭喜大家获奖！！！！✿✿ヽ(°▽°)ノ✿重点说明：1. 积分排行榜中出现积分相同者则排名并列，名次向后顺延，按照活动规则，最终取积分排名前34位小伙伴获奖；2. 同时满足多个获奖条件的小伙伴非常优秀，按照不重复获奖原则，为大家安排方便领取的电子卡奖品或相对高价值的奖品；3. 在升级玩法—邀请好友报名和邀请好友完成上云实践环节，满足抽奖条件的开发者中，未在其他环节中获奖的用户数少于活动规则中的奖品数，故略去抽奖环节，100%获奖；请大家在7月15日之前将奖品收货信息反馈给我们，反馈地址 >>>奖品收货信息反馈   我们将在您填写完整领奖信息后14个工作日内，统一发出奖品，不额外收取任何费用。由于获奖用户自身原因（包括但不限于提供的联系方式有误、身份不符或者通知领奖后超过30天未领取等）造成奖品无法发送的，视为获奖用户放弃领奖。升级玩法邀请好友报名&邀请好友完成上云实践：活动积分排名公布升级玩法邀请好友报名&邀请好友完成上云实践：*学习敏捷上云开发要点，提升就业机会**体验Java,Node.JS,C#真实应用上云开发案例**收获华为无线耳机、拍立得、机械键盘、京东卡等丰富好礼* △适合人群：对敏捷DevOps开发有转型需求，渴望提升云上研发能力的开发者△活动时间：2022.5.16-2022.6.30△活动参与方式：报名活动：点此链接，填写报名表即完成报名；加入学习社群：完成本报名后请务必扫码进入学习群，专家全程跟踪辅导，伙伴比肩共同进步；完成学习任务，赢取积分奖励：点此链接，GET全部学习任务入口NO.积分项积分任务积分奖励任务入口回复地址1学习在线课程完成指定在线课程学习，学习进度100%即代表完成本课程学习。回复要求：无需回帖，只需使用华为云账号登录学习平台完成学习，后台可记录学习完成度。10积分学习课程任务入口/2代码上云实践按照实验手册完成指定实践内容，并按实验手册要求对完成的步骤进行截图（含创建项目、代码托管、编译构建、部署成功），如实验顺利完成，只提交部署成功的截图即可，截图右上角露出华为云账号，将截图回复至指定帖子中。如无法完成实验，做到哪一步提交哪一步的截图即可，将根据实验完成进度奖励积分。实验过程中遇到任何问题、有任何意见或建议，可跟随截图一起回复至帖子中，将为您尽快解决。回复要求：华为云账号+截图根据实验完成进度奖励积分完成至创建项目 10积分/实践完成至代码托管 15积分/实践完成至编译构建 20积分/实践完成至部署成功 30积分/实践如一个实验部署成功，默认前序步骤已全部完成，则奖励30积分，三个实验全部完成将获得90积分奖励。如无法完成实验，将根据提交的截图，按实验完成进度奖励积分。回帖中反馈实验遇到的问题、意见或建议   10积分/有效反馈Java实验入口Node.js实验入口C#实验入口Java项目上云实验反馈帖 Node.JS项目上云实验反馈帖C#项目上云实验反馈帖3参加评测考试根据在线课程学习成果，完成指定考试内容，根据考试得分不同，获得不同积分。回复要求：无需回帖，只需使用华为云账号登录考试系统完成答题，后台会记录考试分数。考试前请务必完成实名认证，否则证书无法显示真实姓名，只显示用户名代码哦！0<考试得分≤60，奖励10积分60<考试得分≤80，奖励15积分80<考试得分≤100，奖励20积分评测考试入口/4发布代码上云对比评测根据用户在代码上云实践中的体验，与使用非云端部署做对比，可在使用的工具、搭建的环境、需要的资源、用时长短等维度进行对比，以博客形式发送至华为云开发者社区。回复要求：华为云账号+博客链接发布有效评测，奖励30积分评选为优秀评测，奖励50积分/评测文章反馈帖5邀请好友报名活动邀请好友报名活动（系统自动统计，无需回复）邀请报名人数≥10人，奖励10积分；邀请人数每增加10人，给邀请者增加5个积分，以此类推，增量不满10人则不追加积分奖励邀请入口/6邀请好友完成上云实践邀请好友在三个代码上云实践中任选一个，完成至部署成功，请好友按要求截图回复至指定帖子中。回复要求：好友华为云账号+邀请人华为云账号+截图（截图中包含部署成功界面且需露出好友本人的华为云账号）每增加一个好友的有效回复，可增加10积分每个好友在三个实践中选择任一个完成即可，每个好友只记一次积分，多次完成、多次回复不重复计入积分。10积分/好友有效回复好友有效回复指好友完成任一实验的部署步骤，即部署成功，截图右上角露出好友华为云账号，将好友华为云账号+邀请人华为云账号+截图回复至指定帖子中。/邀请好友完成上云实践反馈帖7参加满意度调研完成活动满意度调查问卷回复要求：无需回帖，只需使用华为云账号登录问卷系统完成调查问卷。10积分调研入口/本活动上云实践需使用华为云代金券购买ECS RDS等云产品，代金券将由活动主办方提供，请按实验手册完成指定操作后，按示例截图并将截图反馈至指定帖子中。截图需包含右上角华为云账号，戳此进入代金券领取帖回复要求：华为云账号+截图小助手将在收到截图后为您尽快发放代金券兑换码，发放时间为每天11点和每天3点2个时间段，未收到代金券的小伙伴可在社群中@小助手加急处理哦。△活动奖励：积分排名奖品活动期间总积分排名第1名攻城狮豪华大礼包（含富士拍立得1个，雷柏机械键盘1个，无线鼠标1个，华为手环1个，定制双肩包1个）活动期间总积分排名第2-3名雷柏机械键盘1个活动期间总积分排名第4-10名攻城狮精致礼包（含定制鼠标垫1个，定制水杯1个，定制T恤1件）活动期间总积分排名第11-30名攻城狮实用礼包（含三合一数据线1个，定制水杯1个，定制T恤1件）邀请好友参与活动，赢取升级奖励邀请条件奖品名称抽奖名额完成上云实践的有效邀请人数≥50HUAWEI FreeBuds 3 无线耳机 有线充版（陶瓷白）1完成上云实践的有效邀请人数≥30荣耀FlyPods青春版 真无线耳机（铃兰白）2完成上云实践的有效邀请人数≥10100元京东卡3完成上云实践的有效邀请人数≥550元京东卡5邀请条件奖品名称抽奖名额完成报名活动的有效邀请人数≥50150元京东卡2完成报名活动的有效邀请人数≥30100元京东卡3完成报名活动的有效邀请人数≥1050元京东卡5如何邀请好友？第一步：点击报名 一行代码秒上云应用开发实训营>>>第二步：点击分享有礼第三步：通过任意方式分享给好友第四步：好友报名活动，在三个代码上云实践中任选一个，完成至部署成功，请好友按要求截图回复至指定帖子中。△奖品发放说明：活动期间，同一用户不得重复获奖，以所获最高奖励为准进行发放。本次活动抽奖将采用巨公摇号平台（https://www.jugong.wang/random-portal/）进行抽取，将对抽奖过程做录屏公示，如您对评奖方式有异议，请勿参加本次活动。每位参加活动的用户理解并同意，为联系获奖用户以及奖品发放的需要，用户须在参与活动之时提供诸如姓名、联系方式、电子邮箱、通讯地址等真实个人信息，活动主办方将仅为前述目的以及适用法律规定的最小限度内收集和使用用户的个人信息,本次活动所收集的个人信息将在活动结束后删除。（用户在向华为云提交个人信息之前，应阅读、了解华为云《隐私政策声明》；用户参加本活动视为理解并同意华为云《隐私政策声明》，华为云《隐私政策声明》网页地址如下：https://www.huaweicloud.com/declaration/sa_prp.html）。获奖用户在领奖界面填写获奖信息，活动结束且用户填写完整领奖信息后14个工作日内，将统一发出奖品，不额外收取任何费用。由于获奖用户自身原因（包括但不限于提供的联系方式有误、身份不符或者通知领奖后超过30天未领取等）造成奖品无法发送的，视为获奖用户放弃领奖。为保证活动的公平公正，华为云有权对恶意刷活动资源（“恶意”是指为获取资源而异常注册账号等破坏活动公平性的行为），利用资源从事违法违规行为的用户收回抽奖及奖励资格。本活动规则由华为云在法律规定范围内进行解释。华为云保留不时更新、修改或删除本活动规则的权利。所有参加本活动的用户，均视为认可并同意遵守《华为云用户协议》，包括以援引方式纳入《华为云用户协议》的《可接受的使用政策》、《法律声明》、《隐私政策声明》、相关服务等级协议（SLA），以及华为云服务网站规定的其他协议和政策（统称为“云服务协议”）的约束。云服务协议链接的网址：https://www.huaweicloud.com/declaration/sa_cua.html 如果您不同意本活动规则和云服务协议的条款，请勿参加本活动。

一、起源2014年：Lenny Liebmann提出DataOps的概念，在《3 reasons why DataOps is essential for big data success》这篇文章中，Lenny提出DataOps是优化数据科学和运营团队之间协作的一些实践集。2015年：Andy Palmer将这个理念发扬光大，提出了DataOps的四个关键构成，数据工程、数据集成、数据安全和数据质量。2017年：Nexla的Jarah Euston把DataOps的核心定义为从数据到价值。这个是首次把DataOps和业务价值关联起来的定义。2018年： Gartner将其纳入到数据管理的技术成熟度曲线，标志着DataOps正式被业界所接纳并推广起来。 DataOps的概念自2014年提出至今已有8年之久。Gartner在2018年将DataOps纳入数据管理技术成熟度曲线，预计未来5-10年能达到成熟的水平。然而在2021年的报告中，DataOps仍然处于技术的“萌芽期”，预计未来2-5年可能达到成熟水平。现在看，留给DataOps的时间可是不多啦。二、定义IBM：IBM将DataOps定义为DataOps是人员、流程和技术的有机结合，用于快速向数据公民提供可信的高质量数据。Gartner：DataOps是一种协作性的数据管理实践，专注于改善整个组织的数据管理者和消费者之间的沟通、整合和数据流的自动化。 Wikipedia：DataOps是一套实践、流程和技术，它将综合的、面向流程的数据观点与敏捷软件工程中的自动化和方法相结合，以提高质量、速度和协作，促进数据分析领域的持续改进文化。中国信通院：数据研发运营一体化（DataOps）是一种面向数据全生命周期，以价值最大化为目标的最佳实践。聚焦于协同从数据需求输入到交付物输出的全过程。明确研发运营目的，细化实施步骤，在价值运营、系统工具、组织模式、安全风险管理的支撑下，实现数据研发运营的一体化、敏捷化、精益化、自动化、智能化、价值显性化理念。三、现状从定义上来看，国外的一些机构纷纷给出自己的一些定义和理解，强调了DataOps的实践、敏捷、协同等特点。普遍认为DataOps是一种先进的数据分析、开发、管理理念。2022年，中国信通院联合各行业组织机构对DataOps定义为一种由价值运营、工具、组织管理和安全加持下的最佳实践，并突出了一体化、敏捷化、精益化、自动化、智能化和价值显性化的特征。从实施上来看，尽管Gartner的预测与实际发展变化难以完全契合，但从2018~2021年连续的报告上来看，DataOps长期处于“萌芽期”的位置，这也一定程度上反映了国内外组织对DataOps的实践还依然处于摸索尝试的阶段，鲜有组织明确的宣传自己的“成功”案例。整体上来看，组织对DataOps的实践状态一直处于雾里看花、盲人摸象的阶段。虽然我们注意到越来越多的企业开始了对DataOps实践的尝试，越来越多的厂商试图开发适应DataOps理念的工具，但是“我们好像实践了DataOps，但又好像没有”，这句话很好地描述出了不少企业的现状。2022年4月，中国信通院联合工商银行、招商银行、农业银行、平安银行、浦发银行、南京银行、阿里云、腾讯云、新炬网络、深算院等20余家单位对DataOps的定义、标准框架、能力特征等细节进行了深入的交流和探讨并达成了一致。未来我们将结合中国的数据发展情况，打造一套适合我国数据行业发展的DataOps体系。来源：中国信通院云大所

本文分享自华为云社区《[传统企业敏捷转型常见3大疑虑及解答](https://bbs.huaweicloud.com/blogs/346712?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=paas&utm_content=content)》，作者：敏捷小智 。 全球经济已经进入数字化和VUCA时代，充满变化和不确定性，敏捷方法—Scrum以其能够快速响应市场变化，提升研发效率等特点逐渐成为主流研发管理模式，越来越多的传统企业认识到改革的必要性，并开始准备引入敏捷的概念用于软件开发团队的管理。  但是转型就意味着一场变革，变革就意味着阵痛，转型过程中肯定会遇到一定的阻力和问题。那么敏捷转型是否需要先决条件呢？当在这些条件不能满足时，是否就不能完成敏捷转型呢？如果敏捷转型如何获取外部支持？本文将对敏捷转型常见的担忧和疑虑进行分析和解答。 # 1. 敏捷转型是否需要先决条件？ 有些传统企业，在决定进行敏捷转型之前，通常会存在这样的疑虑，敏捷转型是否需要先决条件？也就是我们常说的敏捷基因，答案是肯定的，下面总结敏捷转型的6个关键因素帮助您的转型有个正确的开始。 ## - Scrum团队 敏捷开发有着清晰的管理逻辑和规范，它需要建立在Scrum团队之上，团队成员需充分理解和认可敏捷开发，并能在工作中实际落实敏捷开发理念。Scrum团队具有以下几个特点： • 团队规模小：5~9人，小于5人生产力下降，多于9人则增加协调和沟通成本。 • 跨职能团队：完全具备交付产品增量的各项技能。 • 自组织团队：团队被授权自己管理自己的工作过程和进度，并自己决定如何完成工作。 • 全职工作：保证项目成员专注于单个项目。 • 集中办公：便于面对面交流，消灭信息孤岛，信息通畅。 ## - 一个明确的指标 在开始敏捷转型之前，团队需要知道转型成功会是什么样的。管理层和团队都需就将要采取的措施达成共识，以确认新工作方式是否确实有效。这个指标不应该从某个职能角色，比如测试人员、开发人员等出发，而应该从项目管理全局，比如说用户的满意度，从版本的交付频率等角度去考虑敏捷开发带来的绩效优化。 ## - 合适的Scrum Master Scrum Master的专业度、情商、控制力、逻辑思维能力和计划策略执行力、业务熟悉度、IT专业知识储备度、部门权限等，都是决定敏捷转型是否成功的关键因素。优秀的Scrum Master是敏捷项目的推动人，在促进敏捷活动开展，方向把控，保持进度，调节团队氛围，获取外在支持等方面都起着重要的作用。 ## - 合适的产品负责人 产品负责人（PO）是敏捷开发中至关重要的角色 ，是团队和敏捷转型的关键。产品负责人可以有效激励团队，对团队有强烈的信任。他清楚的知道团队的愿景和目标，以及需要做什么，怎么做能够带领团队达成这个愿景和目标。产品负责人一定是全职的，每个团队一个PO并不能保证敏捷转型成功，但多个团队一个PO无疑是一场灾难。 ## - 外在的支持度 来自企业内部高层、客户、跨职能部门的支持，支持的力度越大意味着我们在敏捷转型过程中提出的诉求会得以满足，保证敏捷活动的正常开展，甚至能够得到试错和经验积累的机会。 ## - 研发流程的自动化 敏捷开发每个迭代就要交付一个可运行的产品增量，也就是说理论上至少在每个迭代结束之前需要集成和发布一次应用，而在实际敏捷开发过程中为保证产品是可集成可交付的，其实是每天一次，甚至是每天多次的去集成和发布，就要求具备端到端无缝集成，实现源代码的自动拉取构建、代码自动扫描检查、测试环境的自动部署、API测试自动化等去保证高频率的交付。 # 2. 组织文化如果没有敏捷基因的话，那这个组织是否适合继续推进敏捷转型？还是应该放弃？ “没有一个时代像现在这样，变化如此之快，转型升级已不再是选择，而是必须。在这个飞快向前的时代，每个人、每个组织只有超越外部变化的速度，才有可能在这个时代致胜未来。”——拉姆·查兰在8月9日《哈佛商业评论》中文版举办的第四届“人才经济论坛”上如是说。当你在了解并想尝试敏捷转型的时候，是不是就意味着你所在组织的研发模式已经跟不上瞬息万变的市场需求了呢？不管是企业、组织还是个人都需要与时俱进，才不会被时代淘汰，拥抱变化、响应变化才是应万变的诀窍。那么有人就会提出这样的质疑，上面说了敏捷转型时需要前提条件的，我们的组织不具备这样的条件，如何实现敏捷转型？ 一般来说，不具备敏捷转型条件的组织不适合大刀阔斧的去转型，一切盲目的行动大部分都不会有好的效果。首先我们意识到敏捷转型的必要性，在不确定的情况下，可以尝试选择一个项目、一个业务做试点，或者组建一个团队，实现新的运营及决策机制，这是非常重要的探索尝试敏捷开发的方法。这么做的一个原因是小范围试点比较灵活可控，敏捷环境比较好搭建，即便不成功，造成的伤害也比较少。另一个原因是小范围尝试成功后可由点及面循序渐进的辐射到整个组织内部的开发中去，这也正符合了敏捷小步快跑交付的思想理念。 组建敏捷团队时如果内部人员Scrum经验不足，目前业内有丰富的敏捷支持服务可供选择，在专业的敏捷指导下进行敏捷试点落地，学习业界标准做法、获取实践经验，从而可以和企业实际情况和需要结合，以便制定更有针对性、更适合企业自身的下一步的推广和落地方案。 # 3. 如何获取团队或部门的支持？ 还有另外一个大家比较关心的问题是，推动敏捷过程中遇到团队或部门的抵触要如何处理？  一般来说抵触敏捷开发转型的人都对敏捷存在错误看法或观念，比如： • 敏捷没有过程控制。 • 敏捷意味着不确定性，不可预估，存在风险。 • 敏捷团队不做计划，因此无法对客户做出承诺。 • 敏捷对于简单的项目是可行的，但我们的系统过于复杂不适合敏捷开发。 同时，对敏捷存在误解的领导可能会认为敏捷团队是自组织团队，敏捷转型后自己将无事可做；对敏捷存在误解的成员可能不喜欢变化，对新的工作方式缺乏安全感，觉得如果有人告诉我该做什么，会更有安全感。 基于以上问题，我们在引入敏捷开发要预见性的抵触问题，而避免用领导者的权力蛮横改革。我们可以采用包括但不限于以下措施： • 运行一个试点项目，团队包括抵触敏捷开发人员，让他们参与新过程的设计中，这是减少抵触的一个不错方法。 • 确保试点项目之外的人员能够看到采取敏捷开发的效果。 • 提供培训，讲述Scrum成功故事，通过参加讨论会或区域间的敏捷兴趣小组等。 • 改变团队人员组成。 • 鼓励正确行为，树立模范。 • 找到真正阻碍，判断个体抵触Scrum的深层原因 最后，要知道即便你能证明自己是正确的，赢得别人的支持也是比较困难的，尽管当前的开发环境存在很多问题，但是在真正相信有更好的方法可以替代之前，大多数人是不愿做出改变的，给团队足够的耐心，了解他们的担忧和顾虑，帮助解决问题，消除顾虑。价值高的事情总是需要花大量时间的。 以上解答了敏捷转型中的担忧和疑虑，希望对您的转型之路有所帮助，但是没有一条成功的道路是可以完全复刻的，我们就要结合自身的公司文化、管理层以及人员本身等情况探索自己的转型成功之路。  本文由DevSecOps专家服务团队出品，前往 专家服务 ，获取更多DevSecOps工程方法、工具平台、最佳实践等干货。

作为DDDChina的发起者之一，看着越来越多的技术人员加入到领域驱动设计（Domain Driven Design，DDD）社区，分享经验、总结实践、甚至于辩论观点，确实十分高兴。然而，有些忧心的是并未看到很多非技术人员参与其中，这与当初力推DDD的目的仿佛渐行渐远 —— 我们一直认为DDD是促进业务和技术在系统架构上逐步达成共同认知的一种好方法。只有共同认知才能共同演进，才有能够避免一次又一次上演的遗留系统惨剧。也许是疫情给了我们更多独立思考的时间，我们也清晰地认识到没有能够吸引更多的非技术专业人员加入，应该说并非是我们声音不够大，更重要是DDD所涉及的方法仅仅瞄准了整个企业架构建模过程的一个阶段，对于我们希望吸引的非技术群体，他们有着自己更需要参与并负责的阶段。 这促使我开始从整个企业的视角去考虑架构建模问题，目标也不仅仅局限于让系统架构能够跟随业务需求的变化而持续演进。面对这个数字化时代，企业的数字化底座成为了核心基石，而这个底座的架构是高质量可持续发展的关键。我希望去解决当下很多人都已经看到的传统企业架构方法带来的问题，从不同的视角去尝试新的方法，找到破局之路。1.从静态走向动态“Be water, my friend.” - Bruce Lee（李小龙） 随着数字化进程的持续深化，企业越来越依赖于自身的信息化和数字化系统，甚至很多新兴业务的诞生就源自于技术的发展，比如现在大家习以为常的人脸识别认证方式，正是由于机器学习技术在近5年的快速突破才得以实现。这样的依赖性一方面激励着企业在信息和数字化系统研发方面持续加大投入，另一方面也让系统的全局复杂度快速攀升。过去从企业内部运营视角出发形成的简单通用信息系统划分，如ERP、CRM等，已经完全不能满足数字化时代企业的需要了。于是我们也看到阿里这样的互联网巨头提出了业务强绑定的“中台”系统概念。移动互联给我们展现了数字化业务的潜力，而未来的元宇宙、Web3.0将有可能带来更多的创新、甚至颠覆性的业务。由此企业所依托的信息化和数字化系统必然会要求很大程度上的“定制化”，这也让针对全局设计的企业架构（Enterprise Architecture，EA）工作变得越来越重要。然而，已有的企业架构方法，如TOGAF、Zachman，更多关注的是企业架构治理的流程和参考内容模型，希望从一个抽象层面指导企业产出适合于当前业务的企业架构全局视图。为了驾驭日益复杂的业务场景，往往需要将设计和实施步骤越来越细化，从而能够调动不同的的专业细分人员来完成固定事项。在企业实际应用过程中，这样的企业架构方法带来了两个比较显著的问题：产出的架构模型及组件划分更多是以确定性的“静态”视图呈现，每个阶段的产出往往是通过特定人群“翻译”上一个阶段模型而得出的，这样的工作模式有违软件需求的基本特征，即需求的澄清实际是通过可工作的软件交付来迭代完成的；对于未来业务的变化和创新“设计”不足，往往只能将感觉变化比较快的领域，如移动互联网应用，划到产出的架构模型之外，美其名曰“非模型”需求。不少企业架构专家提出信息化系统在一些行业的主干业务上应该是比较清晰的，由此，类似TOGAF方法的“静态”产出应该是适合的。然而，我们需要看到，这样的假设实则非常危险：在通信行业，从2G、3G到4G的连续发展，给了大家类似的预期；然而5G的到来，很大程度上颠覆了过去十几年积累的系统模块划分，于是全球各大运营商纷纷开始高喊数字化转型，其中很大一部分工作就是要改变过去的信息化系统架构。国内不少大型银行都在实施基于Zachman方法的企业架构，希望通过统一的业务模型和IT模型来驱动新一代信息化系统建设，从而能够支撑未来的数字化业务发展。然而即使如清算这样看似稳定的底座，真的就已经业务上明确了吗？数字货币和区块链技术应该说才刚刚崭露头角，未来的具体影响还不得而知。我们更应该尊重这个科技时代的客观规律，不能一边高喊着“主动求变”，一边却在为系统的演进设定“确定性”的障碍。这样一时的大力而为，埋下的是未来的诸多隐患，苦的是为了业务连续性而需要持续开发和维护系统的研发团队。由此，我们希望用动态的“建模”，来替代大家习以为常静态的“架构”。我们希望推动一系列针对企业价值定位的、可持续的、可落地的建模活动，来促进整个企业的系统体系得以持续的演进，从而能够通过持续提升组织的整体架构认知，完成对业务发展的支撑和创新的使能。2.针对软件开发本质去建模软件带来的新产品形态在这个数字化时代被越来越多的人认知。作为程序员，我们曾经很难向业务同事解释为什么之前加一个按钮一天完成，现在加一个类似按钮需要三天。而现在大家都知道软件从第一行代码开始就是会被持续修改的，是否易于修改成为了开发效率的基础。真正的难点是如何让软件在面对未来源源不断新需求时，持续保持较低的修改成本。这件事情对于一个单体软件已经是非常困难的事情，而在我们的企业架构上下文里，面对的是一个成百上千软件组成的系统，这件事情就更是难上加难。在这样的环境中，我们没有办法预测未来的需求，只能通过持续提升团队对于“好修改”的认知，并落实到大家的日常工作实践中来应对。显然，在过去的企业架构方法中，我们鲜有看到对软件这个本质属性的关注。更像是今朝有酒今朝醉，明日问题归别人的视而不见。在总结这套方法的同时，很欣喜地发现在不同企业架构阶段的建模活动设计上，早有全球专家意识到了过去这些静态架构方法的危害。比如已经提出近20年的领域驱动设计（Domain Driven Design，DDD），目前在云原生的微服务时代被很多组织引入，作为系统和平台设计的方法，其精髓就在持续地构建广泛的、跨业务和技术层面的“统一语言”，减少翻译工作，从而能够让系统的架构随着业务的变化快速持续演进。 最近两年行业内从“逆康威定律”出发，转换了在服务组件和技术架构设计上的单一视角，从组织和团队划分出发，明确组件设计目标带来的对应团队特征的不同，并能够从持续发展的视角来设计团队的动态划分和演进。这种团队拓扑（Team Topologies）的思想，实际上已经为我们提供了在技术实现层面上的持续建模活动蓝本。站在这些新思想和方法之上，让我们一起来定义针对数字化企业的建模方法：我们认可业务和应用架构的重要性，但更重要的是持续价值建模，任何业务和应用架构只是实现预期商业价值的一种支撑；我们认可系统和平台架构的重要性，但更重要的是持续领域建模，任何系统和平台架构只是应对复杂问题分治的一种结果；我们认可服务和技术架构的重要性，但更重要的是持续组织建模，任何服务和技术架构只是高效实现组织划分的一种映射（康威定律）。在以上的定义中，业务架构阶段指明确架构所需满足的业务目标的定义过程，由于越来越多的数字原生业务，技术和业务的高度融合造成不少企业直接采用应用的说法。系统架构阶段，或云时代越来越多的平台型架构，明确相关软件程序和数据的各方面设计原则及高阶架构。技术架构阶段，或服务化架构下，主要是明确技术实现框架、组件（服务）划分等落地细则。随着市场和用户需求的持续变化，以上建模方法中的活动也应该持续迭代进行。更由于这些变化不可预期，我们更应该关注建模活动带来的相关人员和团队认知的提升，不同视角的架构视图是阶段性共识的可视化呈现。对于架构视图，我们推荐大家采用类似C4（https://c4model.com/）这样的轻量级可视化工具，重要的是关键人群之间的沟通、论证和确认。一言以蔽之，我们更关注产生企业架构的建模协作活动和实践工艺，而采用轻量级治理流程和过程文档。我们认为这样的建模方法符合于《敏捷宣言》所倡导的工作方式，因为：更强调人通过互动协作的认知提升，而不拘泥于每个活动的专业对口；更强调建模工作的迭代演进，而不拘泥于追求某一个时刻的绝对明确；更强调价值驱动，而不拘泥于现有业务的框架；更强调持续响应变化，而不拘泥于繁琐的流程和文档。任何方法都存在局限性，从数字化企业的视角，这套方法不包含两个重要方面：商业模式和组织文化。前者不能脱离各行业背景，在这个产业互联的时代，行业的重塑、整合、创造不断发生，着实很难抽象出相对能够广泛应用的方法。文化则是一个需要更多阅历的领域，就现在的个人经历来总结组织文化的方法，难免贻笑大方。 下文中我们将整体介绍这个敏捷建模方法框架的含义，三个建模过程和两大运营闭环的细节，将在后续的文章中进一步展开。3.三个建模过程从业务架构设计到最后的技术架构落地，我们抽象了三个高阶建模过程域，分别是：价值建模、领域建模和组织建模。通过这三大过程域帮助企业明确端到端的建模活动，从而能够高效组织不同角色协同完成整个企业架构的设计。建模过程中应该遵循“共识大于正确性”的原则：企业架构每个阶段的产出是相关角色或团队协作过程中形成的共识，而不是某个专业角色或团队的单独交付物。在任何一个时间点，都应该坦诚认知的局限性，通过保持协作的开放性来兼收并蓄。一、价值建模：面向商业成功业务架构一直以来被认为是企业架构的起点，然而面对这个数字化时代，真正的起点应该是我们的客户/用户，这点已经成为了企业管理者们的普遍共识 —— 只有持续创造客户/用户价值，才能够实现企业的持续发展。 由此，我们认为针对客户/用户的价值建模是数字化企业的必然起点。企业需要针对自身的行业及客群定位，确定相关的价值模型，作为不同专业背景角色同事们共识的基础。在很多企业中，我们看到业务和技术的融合都被提升到了组织战略层面，但由于没有从价值建模出发，在实际的执行过程中没有建立起来统一语言，造成客观上难以融合的困局。 招商银行采纳的价值三角模型，让组织能够围绕客户价值来行动。来源于TWLive 2021年分享：https://insights.thoughtworks.cn/cmb-value-driven-lean-transformation/我们也要正视数字化技术带来越来越多元化的价值创造可能性，一家企业可能同时经营非常不同的业务模式，比如不少互联网2C服务起家的企业希望抓住下一波企业2B服务的浪潮，这样的场景下，应该有针对性的不同价值模型。而不应该由于是一家企业，所以就强制性只能有一套价值模型或一套企业架构。驾驭这种多元化是数字化企业未来的核心竞争力。在共识的价值模型下，首先还是需要从产品/服务组合的视角去明确优先级，切忌搞大而全，时刻保持对变化的敬畏心。敏捷宣言签署者之一的Jim Highsmith老先生为此提供了一套比较完整的方法框架EDGE，在《EDGE：价值驱动的数字化转型》一书中有比较完整的介绍。其中的关键实践精益价值树（Lean Value Tree，LVT）在亢江妹老师的《轻量级规划实践方法——精益价值树》也有了具体的介绍。 明确了企业级的价值定位，产出业务架构的方法和实践已经有不少的积累。比如服务设计（Service Design）方法，从关键的用户旅程切入，通过端到端的用户场景来明确用户触点及前后台的支撑系统。服务设计方法下的用户场景化梳理，从用户行为出发，明确能力支撑及前、后台的业务服务设计。具体推荐的方法和实践我们将在后续专门的系列文章中展开。这里值得提醒企业的管理者们：价值建模是业技融合的起点，也是一个组织是否真正践行客户为中心的标志。希望大家时刻不忘“客户价值”这个数字化时代的北极星指标！在一些相对信息化积累比较好的行业，如银行业，也可以采用类似付晓岩老师在《企业级业务架构设计：方法论与实践》一书中介绍的工序比较明确的方法。但仍然需要注意定期审视用户价值随着市场变化而发生的迁移。二、领域建模：面向统一语言软件行业几十年的积淀形成了一个共识原则：关注点分离（Separation of concerns，SOC）—— 在复杂场景中，把不同的关注点分离开来，分别处理，以应对复杂性。这个原则最早由图灵奖获得者，荷兰计算机科学家埃格斯·迪克斯特拉（Edsger W. Dijkstra）在上世纪70年代提出，而后成为了我们在计算机建模领域及系统设计领域的底层范式。时下我们的系统和平台架构某种意义上是其支撑的复杂业务的一种映射，所以我们在这个阶段处理的问题是比产生业务架构更为挑战的。在此基础上，需要再次提醒大家对于变化的预期，即使当下再完美的业务架构也会在未来某个时刻变得不合时宜的，所以系统和平台架构必然需要考虑面向未来持续修改的灵活性。 这是一个很难解决的命题，要求更深层次的业务和技术人员的融合，背后是我们需要在企业里建立一套业务和技术人员都能够理解的“普通话”。2003年提出的领域驱动设计（Domain Driven Design，DDD）无疑给我们提供了统一语言的落地思路。很多人认为2015年开始流行的微服务带火了DDD，但实际上是由于越来越多的企业感受到了在系统架构这个层面日益膨胀的复杂度，同时之前依靠外部购买系统套件搭建起来的信息化系统开始成为新数字化业务发展的障碍。DDD思路下的具体方法，类似事件风暴Event Storming，实质上就是在促进业务和技术人员统一语言的建立。在领域建模阶段，我们仍然还有很长的路要走。在走访不少采用了DDD的企业会发现大多数都是技术人员在关注DDD战术层面的模型应用，讨论最多的是具体的模型如何映射到分层的架构实现。很多企业的研发团队对于和业务建立统一语言这件事情感到失望，甚至于从思想上放弃了这方面的努力。我认为企业架构这个话题在近两年的崛起，是我们解决业务人员加入系统和平台设计阶段的契机。在这个领域建模的过程中，我们需要注意以下两点：1. 建立业务和技术都能够理解的简单语言体系。在这一点上事件风暴Event Storming方法给我们呈现了一个简单有效的实例。当然由于各企业所经营业务的多元化，我们还需要更多的方法和实践。2. 划分领域时综合考虑业务和技术的不同约束条件。争论领域到底是业务的、还是技术的是毫无意义的，我们产出的系统或平台领域划分是综合考虑企业经营情况的结果，这里面既有我们对业务相关性的考虑，也有我们对于底层运算平台特性的利用。基于以上两点，我们认为一个良好的领域建模过程首先要让大家明确使用的语言体系，即不论是业务还是技术，都需要学会普通话。然后是一套行之有效的协作流程和实践，能够保证大家在正向约束的条件下进行领域建模，产出系统和平台架构。最后，在这个阶段不少组织存在对于产出物的纠结。业务侧认为需要看到具体的UI才踏实，技术侧觉得没有代码框架都是虚幻。我们并不否定一些界面视图或技术原型可能在确认共识方面的必要性，但重要的是达成共识的协作过程。即使这些细节的文档材料对于不同的个体来说也是有不同理解的，而过于细节的材料反而容易造成未参与研讨过程的文档读者迷失在不必要的细节关注里。三、组织建模：面向团队演进长久以来，在具体的软件架构上，我们更多还是从技术范式和框架的视角在设计，从简单的MVC架构Web应用，到时下SaaS、PaaS、IaaS的分层模型。被忽略的一个客观事实是：软件开发仍然是强依赖于人的行业，流程、架构和工具某种意义上都必须围绕如何让软件开发个体和团队更高效作为出发点。在软件行业里，我们也逐步形成了对于康威定律的共识 —— 组织形态决定产品形态。Conway’s law: Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.- Melvin Conway (1967)简要翻译：组织设计的产品/服务等价于这个组织的沟通结构。这个定律对于持续变化的市场和客户需求来说是非常不利的，即我们目前的组织结构会随着未来的变化而变得不合时宜。这种不合时宜会反映出组织交付的产品和服务不能够满足市场和客户的需求。在这个时代，运营超过三年的研发组织或多或少都经历了这样的痛苦，很多的“遗留系统”实际上就是这样产生的。这背后的核心原因是我们的组织结构并没有随着外界的变化而变化，大家过多地期望仅仅是从技术的角度去调整架构，让各个组件更为灵活，但却忽略了组织结构才是长期的制约因素。每次识别出的技术架构问题，往往在最后落地时没有了组织支撑，成为了空中楼阁。 由此，我们希望直接从组织结构视角去建模，通过组织的划分及交流沟通结构的确立来表达对应的服务和技术架构。从这个视角出发，团队拓扑Team Topologies已经给我们提供了非常好的方法，弥补了过去我们在组织视角的两大盲点：1. 组织内部团队的划分没有明确的目的驱动。针对技术本身的复杂度，组织划分成小团队是一种常态，这不仅仅是开发效率上的考量，也是出于不同目的性的考虑。比如在功能开发团队之上，我们往往会有跨功能的平台团队存在，解决一些共性的能力封装问题；2. 团队和团队之间的沟通互动没有明确的设计。多个团队的协同问题在各个研发组织里十分普遍，经常有不同的角色抱怨“会多”。大家并没有刻意去规划团队和团队之间合理的互动模式，在具体协作过程中自然也无法明确哪些会议是合理的，哪些是由于某个团队工作不到位造成的。通过团队拓扑来完成组织建模对于我们“逆康威定律”的帮助是巨大的，业务和系统架构的变化直接就会映射到团队结构的变化上，而团队的变化自然会驱动技术架构的改变。当一个简单MVC架构的web应用随着市场拓展而越来越复杂的时候，这种变化展现在组织建模上很可能的结果是前、后端团队的分离，这种团队的分离自然而然牵引了架构上的前后端分离。 值得一提的是，在云原生和微服务为主导的技术架构时代，大家更容易忽视组织结构的问题。由于单个微服务对比传统架构的代码量少很多，对应的开发团队自然小很多，无形中给了大家组织已经是灵活小团队的假象。然而，不能忽视的是业务的复杂度依旧，多个微服务的集群才能真正实现业务，小团队组织结构下可能增加我们的沟通互动成本，并且组织结构可能形成“静态小团队膨胀”，即当一个新需求出现时，团队不是去考虑是否应该改变现在的微服务，而是默认增加新服务。长此以往，微服务的个数越来越多，小团队之间的沟通越来越繁琐，开发的效率越来越低。所以考虑团队划分的演进是我们保持高效组织生态的必然。4.两大运营闭环面对持续的变化，我们拥抱敏捷的工作方式，由此也产生了在保证数字化业务持续经营的两大运营闭环，分别是：“顺时针”的市场驱动，和“逆时针”的创新驱动。我们认为在企业架构中明确这样的持续运营闭环是保证大家采用“动态”视角来看待持续建模工作的关键。这正如任何成功的数字化产品和服务，上线面客仅仅是开端，真正的客户价值创造关键是后续的持续运营和迭代演进。这也是为什么我们在企业架构设计过程中，需要从“建模”活动视角来强调这种可持续性。第一环：“顺时针”市场驱动科学应变不论是业务架构还是最后落地的微服务，都是服务于我们在价值建模过程中认定的商业机会。根据企业经营的情况，初始的价值认定会得到验证，而根据验证结果我们就有必要进行业务架构、系统架构的调整，最终驱动技术落地上的迭代。这样的市场驱动也适用于持续的新机会发现，包括一些新技术驱动下的业务可能性的探索。需要强调这并不意味着我们只有一套大而全的业务模型涵盖所有可能业务，相反由于这些新产品和服务的持续探索，一家企业很可能在这些新领域采用独立的、更为轻量级的架构模型，从而能够保持在投资上的灵活性。在落实这样的运营闭环时，我们应该有相关的管理部门或赋能团队来保证闭环的持续运作，特别是在一些拥有上千人研发队伍的大型组织里。EDGE首次提出的“价值实现团队”（Value Realization Team，VRT）就可以作为一个很好的参考，帮助组织推动这个顺时针运营闭环的持续落地。第二环：“逆时针”创新驱动主动求变在这个充满挑战和机遇的市场环境下，创新正成为一家企业的生存必备能力，但大部分组织在如何有效进行创新上却存在很大困惑，更不要说建立支持持续创新的架构。 虽然商业创新很多时候可以从商业模式的打造上切入，很多企业的高管也在强化自身的战略投资能力。但不可否认让企业内部的团队，甚至个体，发挥自身的创新能力，已经成为一家企业是否建立数字化基因的基本衡量之一。由此我们需要在建模活动中支持团队主动发起变化，不少的企业都在利用虚拟团队进行跨产品和服务的整合创新，而过去数年全球在学习型组织方面的研究，也为我们提供了基于实践社区CoP(Community of Practice)持续运营方式。CoP围绕着一群有共同关注或热情的人，定期展开互动学习和创新尝试，比如基于自动化技术RPA的CoP，或者人工智能方面的算法CoP。这种机制的重要性在于保持团队对于市场和技术发展的开放性，通过持续多点尝试来主动发起改变。不少企业在激发自身产品和服务一线创新的组织机制上，采取了成立内部或联合外部的孵化器模式，允许来自于不同团队的员工自由组队，提出基于企业赛道或能力平台的创新想法，并提供必要的落地支撑。这种模式短期可能取得不错的效果，但需要持续推进长效机制的建立，避免成为赶时髦的昙花一现。5.甄别借鉴，与时俱进 开篇对比了TOGAF和Zachman这样的经典企业架构方法，帮助大家明确我们为什么从“建模”的视角来切入现代数字化企业架构。但这些经典方法仍然是值得肯定的，它们的提出也是源自于一些先进企业之前数十年推进信息化工作的提炼和总结。 对于很多企业来说，信息化仍然是数字化的重要支撑，没有良好的信息化系统，数字化业务就无从谈起。从这点出发，我们需要对这些方法的思路和实践进行甄别和借鉴，比如TOGAF针对组织架构能力建立的框架Architecture Capability Framework，就是比较好的帮助组织建立架构治理能力全局视野的可行方法。当然在一些领域，如架构变更管理Architecture Change Management，和我们这里提出的敏捷建模，就是截然不同的思考。很多研发组织在实践敏捷开发方法时经常会陷入一个“非标准化”误区，即认为敏捷开发都是提倡个人匠艺，团队层面则不存在什么约束。事实上敏捷开发方法面向的是规模化的软件工程，对比传统强流程管控的方法（如CMMi），在轻量化流程的基础上，实质是增强了对于个人工艺纪律性方面的要求，比如经典的测试驱动开发TDD，就要求开发者遵循先设计自动化验收测试、再进行功能实现编码的纪律。同样的思路应用到企业架构设计上，我们认可一些主流方法在“流程和工具”方面的积累，我们希望从轻量化的视角去选择性采用。而我们的敏捷建模方法更关注的是协作和工艺上的实践，强调在企业架构设计中“人和互动”带来的组织级认知的持续提升。改变的道路从来都是充满挑战的，在企业架构重要性日益凸显的数字化时代，我们希望通过这个敏捷建模方法DEAM（Digital Enterprise Agile Modelling）的提炼，帮助更多的人意识到软件研发的本质，并能够更多从组织持续成长的动态视角来构建企业架构的能力，从而奠定数字化时代高质量可持续发展的核心组织支撑。原文链接：https://blog.csdn.net/csdnnews/article/details/124161797

我们看到资本如何在时代浪潮中，获得生命的延续。我们看到不可知的市场需求，从大公司到创业公司，以及中小创业公司所带来的机会。我们看到创新和科技不断推动人类生活向前迈进。但是当下大多数人似乎还没有意识到，我们已经过上一个更好的时代。我们正在以飞一般的速度推动公司和科技生态系统的发展和进步。随着社交媒体用户总量翻番，人们认为我们正在过上一个数字化的时代。但事实并非总是如此，我们正在过一个基于手机和社交媒体的时代，而不是真正数字化的时代。这篇文章将帮你更深入地了解今天科技生态系统的变化，以及它对于下一代生意的意义。我们将从最初的科技生态系统的兴起说起。如今，基于物联网和大数据的新型数字生态系统已经在生产效率、透明度和治理方面取得显著进展。大多数人似乎还不知道的是，我们正在迈向“精益智造”的时代。这一精益智造是围绕如何最小化成本、最大化产出、高品质生产和满足用户需求等主题的实践。这也是我和团队在我们最新专注于的领域。我们正在探索这一变革的潜力，更快、更智能、更便捷，以使我们的生活更便宜、更快速。物联网是第9次工业革命，它正在帮我们构建一个生态系统。首先，我们将研究物联网的前世今生。物联网（iot）最早出现20世纪在20世纪80年代早期，如果人们想要控制汽车，他们需要通过一系列可靠而高效的单品控制器来进入数据中心，使得互联网与其匹配。当iot出现后，所有物理设备都可以联网，其中包含大量传感器，可以对生产设备的每一个位置，以及从何处开始制造物料进行感知，从而进行远程操控。物联网的核心是感知和数据收集。因为感知和收集的需要，这一感知过程被称为物联网（iot）。其次，iot和各种智能设备的发展，包括智能可穿戴设备和各种智能家居设备都将在整个智能产业链中起到关键性作用。智能设备的不断发展，将更快速地对社交媒体、移动互联网和物联网的发展速度造成冲击。它们将成为企业的核心竞争力，并推动整个产业变得更快、更智能和更便捷。最后，通过基础设施和服务进行移动连接，物联网产业使得数百亿甚至数千亿的工业设备联网。为了把物联网这个主题带入主流文化，我们将研究“精益智造”（leaninnovation）。精益智造（leanor）是以产出作为目标，通过产出实现经济成功或企业价值。如果要实现这个目标，关键是提高供应链和生产系统的效率。在供应链方面，制造商应该将产量快速调整到可持续或健康状态，尽可能提高产能，以提升产品的可靠性或精确度。

scrum项目误删的工作项能不能恢复？