一、 DevOps 的本质DevOps从本质来讲只是倡导开发运维一体化的理念（MindSet）。这个理念的提出是为了解决很多企业面临的转型挑战，也就是将业务数字化，并且缩短数字化业务上线的周期，快速试错，快速占领市场。DevOps并没有改变固有的软件生命周期：需求，设计，开发，测试，交付。但伴随着基础设施，软件设计方法等的改变，软件开发的思路，或者方式产生了比较大的变化。DevOps带来的最大好处是，软件生命周期数据链路的打通。这不仅仅是运维和开发的结合。从顶层视角看，这是业务和生产的紧密结合。以前从业务和开发是脱节的。想要查看需求的实现进度，需要大量的人工汇报，更别提运营了。而现在以一个微服务实现一个特性的粒度来看，可以从需求，开发，测试，部署一直追溯到这个特性运营情况。这也是DevOps成为数字化企业基因的原因，业务和生产实现了完美的结合。从敏捷实践的角度来讲，你会发现开发组织中参与者好似生物体中的神经元，大家各司其职，自成一体，接受反馈，并向外主动反馈。团队的自组织使得工作更加自然，能产生更大的效能。由以前的项目经理驱动，改为自我驱动的协作方式。每个人都可以给相关的团队以及责任人提需求，大家有机的协调在一起。二、 微服务、容器和DevOps的关系微服务只是一种设计思路，或者说他给出了如何用正确的方法来进行SOA的实施。理论上来讲他的确和DevOps没什么关系，但是从如何实践DevOps的角度来讲，微服务是非常有意义的。此外，随着诸如Spring Cloud以及微软Fabric等SDK的完善，微服务开发模式也逐步完善，实现了概念的落地Docker可谓是一种敏捷化的虚拟化技术（较之虚拟机而言）。其实微软Fabric或者CloudFoundry也都脱离开容器的概念提供了微服务开发的解决方案，所以这两者并不是强绑定的关系。但是容器用不可变配置架构实现了微服务从开发到运维的质量保真度，这恰好解决了粒度小，数量多的微服务所带来的运维难题。再加上K8S，Swarm等容器云的支持，docker容器已经形成了事实上的标准。如何利用这个强大的运行环境帮助企业敏捷，推进业务数字化，并且加快业务的投产？ DevOps为上面所说的开发模式提供了软件生产线。所以总结的来讲，企业业务敏捷是DevOps发展的直接推动力，容器云，以及微服务为DevOps提供了技术可行性。而敏捷帮助提高DevOps工作效能。对于团队的拆分，这个问题真的要结合产品规模来看。团队的拆分有很多办法，贝索斯说的two pizza team，是建议一个团队中的人尽可能少，不要超过两个Pizza能吃饱的规模。用敏捷实践来讲，可以分为多个特性团队，以及维护团队，不同的团队各司其职，合理分工。在我以前的实践中，三个人可以做一个Feature，来交付一个月迭代的工作量。当然将原有的巨石应用分割成更小的微服务是挑战很大的事情。因为理论上的微服务的设计对现有的团队组织结构，以及工程师设计能力都带来了一定的挑战。有些组织按照DDD（领域驱动的设计）的方式去实践微服务，会发现以前一个应用的复杂度变得很高，对项目管理来讲也是一件头疼的事情。现在有个比较新的看法就是，大家宣称做微服务（MicroService）的时候，实际上做的是迷你服务（MiniService）。迷你服务的粒度较之微服务的粒度更粗一些，关注度由一个域Domain，变成了能力。一个迷你服务提供一种能力，这种能力的提供也许是跨越多个域的。最好的方法是以一个团队能承担的任务划定微服务的界限比较好，这样以来，不论是任务管理，代码构建，产品部署都会比较好做。更关注服务的能力，这样也会减少因为跨域而带来的复杂事物处理。三、关于DevOps学习和运维的一些注意事项1、代码管理，很多公司对代码管理非常头痛，尤其是客户多了，版本就乱，一次升级就成了一场灾难，因此，代码管理确实非常重要。2、项目进展管理，时间、成本和质量是项目管理的三要素，作为项目经理必须做好平衡。也需要协调好甲乙方资源，推进项目的完成。3、问题管理，要常规运用事故管理的模式，对问题进行根源分析，提出改进意见。这里用好PDCA，RCA这些管理工具，非常有必要。4、系统架构的稳定，架构不是一成不变的，也不应有普世标准。我们看《淘宝十年》就会发现，在不同时期，不同的体量规模下，淘宝的技术架构也在不断调整，稳定中的迭代发展是必由之路。但无论是什么时期，一个稳定可拓展的架构会让系统运维起来更顺利，体验更好。5、测试问题，不说啥黑盒白盒测试了，反正我觉得测试这个环节做的蛮不好的，我们用的软件不说进行漏洞测试了，就是一些错误都是上线了再去发现。比较欣慰的是，医疗信息化软件未来可能会作为医疗器械进行管理了，这样一来，一定会提升行业对测试工作的重视程度了。6、知识积累及传递，一个公司一个部门多年的实践经验的总结，这些总结需要靠时间的积累，在经验和教训的积累下慢慢沉淀。当你拥有了丰富的行业知识，你也就成了老油条了。一个团队需要从老油条身上提炼出老油来，这样对于公司和单位的能力提升都很有好处。小鲜肉一抹此油，容光焕发呀。7、运维前端可配置，与用户接触最紧密的就是我们的运维工程师，用户对他提出的需求也最多，系统的灵活性体现在他能运用何种工具对所管理的系统进行客户化配置，以适应客户的大量且多样的需求。如果运维工程师啥都干不了，不但影响公司形象，也会大大拉低研发工程师的效率。8、性能监督和度量，监督和度量能够让我们了解系统的瓶颈和改变方向，尤其是利用一些锚点设置，更能了解用户的习惯，促进用户画像数据的产生，从而做到比用户更了解他自己，做出更好的产品。9、团队建设构建协作共进的IT文化，协作共赢，相互信任是DevOps的初衷和追求目标。而要达成这个目标，就需要培养团队成员之间的认同感。这种认同感不仅是在工作中产生，也需要通过文化进行熏陶和培养。10、采用必要的自动化管理工具，很多新的工具确实是当年没有的，一些新技术的运用，也让当年的一些模式和方法需要改进。自动化的工具会让我们工作更有效率，沟通更顺畅。（关于DevOps具体如何学习大家可以参考以下链接：cid:link_0）

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

在近期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项目误删的工作项能不能恢复？

本文分享自华为云社区《[当心，你搞的Scrum可能是小瀑布](https://bbs.huaweicloud.com/blogs/344133?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)》，作者：敏捷小智。 为了更好的拥抱变化，很多团队选择使用敏捷去管理组织或者团队的研发过程，Scrum作为最常用的敏捷框架之一，备受青睐。使用Scrum的团队叫做Scrum Team，Scrum Team（以下简称团队）按迭代进行交付，在一个迭代中，团队要完成需求的规划设计认领、编码、测试以及部署上线工作。 有的团队刚接触Scrum，一个问题令他们很困扰：迭代初期开发人员的工作较多，测试人员闲着；迭代末期开发人员闲着，测试人员的工作比较多，怎么解决资源等待的问题呢？ # 问题分析 造成以上问题的原因大致有以下几种： # 团队搞的Scrum其实是小瀑布 团队搞的不是真正的Scrum，而是披着Scrum“皮”的小瀑布——团队有SM、PO，需求使用用户故事记录，迭代中的活动比如每日站会、评审会议等一个不落的开展，但是，团队在迭代中依然按照瀑布模型进行运作——认领完需求进行开发，开发全部完成，交付测试，测试完成，项目上线，整个流程走下来，就造成资源等待。  # 需求拆分不够细 需求粒度偏大且没有做进一步拆分，这种情况导致开发人员完成需求的编码工作，就已经到了迭代末期，迭代前期测试人员设计完测试用例，就只能等待了。 # 开发和测试之间缺乏沟通 开发人员完成了某个新需求编码，没有告诉测试人员；测试人员也没有主动且频繁的向开发人员询问是否有已完成的新需求需要测试，直到迭代末期，开发人员才将所有开发完成的需求一并交给测试人员，造成了资源等待。 # 解决方法 ## 让团队了解真正的Scrum工作方式 小瀑布相比于传统瀑布，应对变化的能力可能有所提升，但小瀑布的运作方式和Scrum所倡导的做法还有差距。Scrum使用“Increment”（增量）来表示每一个即将交付的需求，作为Scrum的三大工件之一，Increment有两个重要特性：满足DoD、随时都可以发布，Increment这两大特性为敏捷应对频繁变化提供了保障。反观小瀑布——迭代前期开发、迭代后期测试，如果迭代过程中，突然要发布新需求，那显然是有风险的——因为代码没有经过测试。Scrum中，迭代运作过程更像下图，每个需求完成编码，都直接交给测试人员，测试通过即可准备上线（就绪即可，不是必须上线），在这种情况下，资源等待的问题就会被解决。  究其原因，还是团队对Scrum的理解不够深入，很多团队接到组织安排要进行敏捷转型，就将Scrum角色和流程搬进来，但团队不了解Scrum是什么，为什么，这样转型往往换汤不换药，也许有效果，但一定没有真正的Scrum运作效果好。 想改变这种情况，Scrum Master和Product Owner应该对敏捷有深刻的理解，这样才能影响团队甚至向上影响到组织高层，让高层也从根本上了解Scrum过程以及Scrum带来的好处，而不是关注有几个团队用了Scrum。 另外，聘请外部教练来帮忙做Scrum导入也是不错的选择，首先外部教练通常具备专业性，更了解Scrum的运作流程，Ta会帮助团队运作Scrum，并对各个角色进行Scrum相关知识的辅导，避免团队因为对Scrum理解不到位，而走弯路。而且，中国有句俗话“外来的和尚好念经”，不管对于团队，还是对于高层，外部教练相比于内部教练可能更容易说上话，提出的建议也更容易被听取。 ## 对需求进行拆分 当需求太大时，团队可以和Product Owner一起，将需求拆分、细化——一方面可以更好的提炼产品价值，另一方面可以更好的划分工作量。 需求拆分有很多方法，详情可以参考《[ 【 DevCloud · 敏捷智库】 如何拆分用户故事](https://bbs.huaweicloud.com/forum/thread-50136-1-1.html)》 。 加强团队成员之间的沟通 团队成员之间缺乏沟通，表面上看可能是由于成员之间业务、分工不同，实际也是由于对敏捷理解的不到位，敏捷宣言提到“个体和互动胜过流程和工具”，团队成员之间应该频繁沟通，就像DevOps打破开发、运维的壁垒一样，在Scrum Team中开发、测试之间也不应该有隔阂。 Scrum Master应该积极组织每日站会，通过站会让团队成员了解项目进度——哪些需求正在开发、哪些已经开发完成等待测试。 如果站会效果不理想，团队可以尝试使用电子或物理看板来记录需求及需求的价值流动，这样哪些需求待测试一目了然。  # 培养多面手 除了以上三种方法，还有一种方法可以解决资源等待问题，那就是培养多面手，比如开发人员既可以做开发，也可以对自己实现的功能进行测试。 实际上，Scrum确实提倡这么做，Scrum Guide中提到：“Scrum Team 是跨职能的（cross-functional），这意味着团队成员具有在每个Sprint中创造价值而所需的全部技能”，团队能力允许的情况下，培养多面手不单能够解决资源等待问题，还可以让团队更好的践行Scrum。 总结 本来想搞Scrum，结果却搞成了小瀑布，而不自知，这是造成资源等待问题的最主要原因，只有加强对敏捷理念的理解，才能让团队真正从Scrum中受益，想知道你的团队到底有多Scrum么？快来[华为云Dev SecOps专家服务——Scrum成熟度评估 ](https://devcloud.huaweicloud.com/expert/enterprise/assessment)测一测吧~

在 Very，我们从一开始就是一个远程优先的组织。随着时间推移，我们已经形成了一种远程文化，使我们能够一起构建软件和硬件，而不会陷入消磨时间的陷阱。通过授权工程师、实施敏捷策略和定义明确的职责，我们为远程物联网工程团队的蓬勃发展扫清了道路。领先于远程工作挑战随着公司希望在竞争激烈的招聘市场中招聘到最优秀的人才，对远程工作的需求继续上升。并且，随着混合工作模式的增加，远程工作已从奢侈品转变为依赖顶尖技术人才的公司的必需品。虽然远程工作人员是一个明显的竞争优势，但也存在一些风险，如失去可见性、责任感和清晰沟通等风险。对于一个软件团队来说，克服这些挑战本来已经足够困难，何况在一个号称“硬件很难”的行业里。那么，如何与构建连网设备的硬件团队合作呢？在 Very，我们创建了一种远程文化来解决围绕分布式工作的主要问题，这使我们在构建分布式硬件团队方面处于领先地位。优化分布式、敏捷物联网硬件工程的 3 个关键流程策略作为咨询公司，时间是我们最宝贵的资源，而且对我们和我们的客户来说，时间就是金钱。如果硬件工程师被耽误，或者软件团队被硬件团队耽误，那么这对我们业务和客户来说都是代价高昂的。这就是为什么我们的流程非常注重节省时间的原因所在。我们对这些流程的思考方式可以分为三类：授权工程师、敏捷流程和明确职责。1、 授权工程师赋予工程师权力使他们能够在没有第三方瓶颈或繁文缛节的情况下自行解决问题。为所有工程师提供一个资源充足的家庭实验室如果工程师不得不从团队成员那里借用工具，其中一些人可能远在 1000 公里之外，那么您将面临不必要的延误。为了避免这种情况出现，我们让工程团队成员从置办一个家庭实验室开始，在其家里配备我们认为能够满足物联网工程开发的工具。不要拖延小额支出该领域另一个节省时间的方法是自动批准购买工具、耗材和运输的小额费用。工程师花在等待一些新的专用硬件或补充常见用品上的时间可能会使团队陷入瘫痪，因此每个硬件和固件工程师都有一张公司信用卡，如果他们需要的话，可以自由购买最高 200 美元的商品，以便为客户进行交付。简化大宗采购除了自动批准小额费用外，硬件团队还具有一份更昂贵设备的活动清单，他们可以根据需要在未经批准的情况下购买这些设备。对于确实需要临时批准的大型订单，我们也有适当的流程，使我们能够以最少的繁文缛节快速审查和批准它们。2、 敏捷流程敏捷开发方法在软件领域已经存在了相当长一段时间，但硬件工程领域并没有很快采用它。尽管缺乏普遍性，但我们发现敏捷方法对于我们的物联网工程团队（包括硬件工程）来说是一个非常有用的开发流程。更有效地利用时间我们在 Very 使用敏捷开发，因为它有效地优先考虑了我们最宝贵的资源——时间。 对于 Very，敏捷开发最重要的原则是：▲不断为最终用户提供价值。▲在迁移到新功能之前，确保功能已准备就绪。▲尽早并经常测试。更快地构建有用的组件敏捷原则在我们硬件团队构建原型的方法中最为明显。如果遵循传统的行业路径，你将从一份完整的详细产品需求清单开始，然后开始一个长期的“数字工程”，在那里，设计是在计算机辅助设计（CAD）工具中创建和完善的。这个阶段可能要持续数月，并且通常会进行多次设计审查，在此期间，整个团队和其他关键利益相关方坐在一个房间里审查设计文件。最后，在项目几乎完成后，构建并测试一个原型。这种方法（也称为瀑布法）会导致较长的设计周期，并且在面对不断变化的需求或原型中发现意外设计问题时很脆弱。相反，我们将设计周期的重点放在构建能够提供用户价值的原型上。这意味着我们不是从详细的需求列表开始，而是从描述我们想要给用户带来的价值的列表开始。我们使用该列表来制定一个原型计划，该原型将开始提供一些价值。我们快速完成周期中的“数字设计”部分，并构建了一个初始原型，通常在项目开始后的一两周内完成。接下来，我们测试原型并开始计划下一个。这种快速、不断的原型开发循环会一直持续下去，直到我们拥有一个能够为用户提供必要价值的设备，并且在现实世界中功能齐全并经过测试。这是最小可行产品（MVP）。通过遵循这种方法，我们可以比传统的瀑布开发更快地获得MVP，并且风险更小。3、 明确职责通过清晰地定义职责，我们确保团队成员知道他们的职责是什么，以及当他们发现不属于他们的工作时该去找谁。对于硬件团队来说，这在集成工程师的角色中体现得最为明显。Very的集成工程师有望跨越电气工程和机械工程之间的界限，他们是将项目结合在一起的粘合剂。职责包括原型设计、提供设计反馈以及帮助指导项目走向生产。这使电气和机械工程师能够专注于设计，并从原型制作过程中获得有关其设计的高效、真实反馈。为了让团队成员以最有效的方式工作，团队在构建测试计划上进行协作，该计划清楚地记录了工程师在设置和测试原型时应采取的步骤。这可以防止不必要地干扰他人的工作，以回答如何设置测试硬件的问题。此外，我们将敏捷计划板上的所有工单分解为小块工作，并将每项任务分配给责任方。明确的职责定义确保时间不会浪费在重复工作上。持续改进即使我们成功地采用了基于经验的方法，我们仍然会发现需要改进的空间，并不断完善我们的流程，为我们的团队消除障碍。通过不断改进远程工作方法，我们远程物联网工程团队提供的速度和价值震惊了客户和同行。（作者：Bill Flaherty；编译：iothome）