写点什么

西门子医疗如何同步提高软件交付的速度和稳定性

医疗保健领域驱动软件的交付转型

  • 2021-11-12
  • 本文字数:5833 字

    阅读完需:约 19 分钟

西门子医疗如何同步提高软件交付的速度和稳定性

在本文中,我们关注的是西门子医疗数字健康的软件交付过程。这一过程需要遵循医疗行业的严格规定。我们展示了我们将这一过程向速度和稳定转型的历程。这两项指标在转型过程中同时得到改善,证实了《加速》一书中的研究成果。

领域

西门子医疗是一家医疗技术公司,致力于推动创新,帮助人类活得更加健康长寿。在西门子医疗内部,团队协作的数字健康平台是医疗机构数字化转型的促成者,目标是将数据转化为成本节约和更好的护理。该平台为操作、临床和共享决策支持提供了易于操作的解决方案。它为将数字解决方案集成到临床常规提供了一个安全且符合法规的环境,促进了跨部门和跨机构的互操作性。此外,该平台还提供了用于数据驱动决策支持的途径和人工智能应用程序,它们出自于西门子医疗和策展合作伙伴。


迄今为止,已有来自 75 个国家的 6,500 多家机构和 32,000 个系统连接到该平台。这使得可以在各个机构访问超过 3000 万的患者记录。该平台对 SaaS 和 PaaS 合作伙伴都是开放的。SaaS 合作伙伴通过团队合作数字市场提供他们现有的应用程序。PaaS 合作伙伴利用团队协作 API 开发新的应用程序和服务。


这个团队合作平台是基于云的。它构建在微软 Azure 之上,在设计和默认情况下都具有隐私性和安全性。软件交付的速度和稳定性是团队协作的核心。2015 年,速度和稳定性都不够。有了这一认识,在同一年开始了软件交付过程的转型。转型的目标是使软件交付更快、更稳定。为了实现这一目标,多年来实施了大量的人员、流程、技术和法规变革。

转型路线图

作为转型过程的一部分,引入了大量的新方法:HDD、BDD、TDD、用户故事映射、结对编程、独立的部署管道、测试 DSL、SRE 和看板。在 InfoQ 之前的一篇文章“西门子医疗在团队协作中采用持续交付”中对此进行了详细描述。方法的采用和“粘性”因团队而异。下图描绘了转型随着时间推移的主要里程碑。

2015 年,改革的必要性已经变得显而易见。作为企业中的一个新兴平台,我们基于全企业范围的硬件和软件产品的法规性质量管理体系(QMS)交付,我们面临着无法满足的产品速度和稳定性需求的挑战。当时,产品所有者正在打入数字服务市场,这对公司来说是全新的。对于哪些服务会与用户产生共鸣,用户愿意为哪些服务付费,以及哪些功能集最有价值,我们一无所知。因此,将想法转化为软件的快速实验需求很高。每两周或每个月发布一次软件,并立即按需进行热修复,将受到产品所有者的欢迎。这与我们所要做的软件交付相去甚远。很明显,质量管理体系的变化需要监管部门的大量专业知识。我们开始了一项使质量管理体系更加精简的长期计划。在研发内部,我们更加重视自动化测试了。


2016 年,我们发起了 BDD 运动。在自动化测试改进时将它作为一部分完成了。它对需求规范、自动化测试、测试实现、测试报告和所有角色测试结果的可理解性都有广泛的影响。在过去,每个需求都很大,BDD 的引入迫使产品所有者将需求分解成很小的用户故事。每个用户故事开始被整个团队进一步分解为一组小型 BDD 场景(使用 Given / When / Then 语句的示例说明)。团队欢迎这些更改,因为它们解决了长期开发人员的担忧,即需求太大、太庞大,无法在短时间内实现。较小的需求促成较小的自动化测试。较小的自动化测试带来更稳定的自动化。尽管有这些重大和必要的改进,但总体上的转型速度相当缓慢。在 QMS 变更方面,我们做了一个分析,即在仍然保持所需的法规遵从性的同时,如何减少角色、可交付物、活动和工作流中断的数量。


2017 年,我们引进了持续交付顾问,加快转型。来自 Continuous Delivery Ltd.的 Dave Farley 为管理人员、产品所有者、架构师和开发人员提供战略咨询以及培训。来自 Equal Experts Ltd.的许多顾问与我们在各地的产品所有者、建筑师和开发人员一起工作,使用许多新方法和新技术共同交付功能。具体来说,咨询活动期间重点应用了 BDD、TDD、用户故事映射和结对编程。通过与我们的团队合作,顾问向我们的开发人员、架构师和产品所有者展示了如何以新的方式工作,实现独立的部署管道,将可观察性落实到位,等等。此外,我们还邀请了 Johner Institute GmbH 的医疗 QMS 顾问,讨论了我们的 QMS 调整分析,确认可以在保持法规遵从性的同时进行这些调整。


2018 年,我们继续与顾问们合作,更深入地采用持续交付的工作方式。这一次不是要引入新的方法,而是要在可持续的基础上,将之前引入的方法嵌入到团队和团队成员的日常生活中。日本武术的精神概念守-破-离描述三个阶段的学习道路上掌握(守,跟随大师,破,学习其他大师和优化实践,离,想出自己的技术),我们的转型是从守到破的学习阶段。我们的目标是嵌入新的工作方式,这样就不再需要顾问的参与来支持新的实践。我们达成了一个阶段,持续交付成为所有新的数字健康产品的标准。在转型的监管方面,我们将基于 BDD 的需求工程正式引入了监管的 QMS。


2019 年,我们发布了第一个 QMS 版本,该版本使团队能够以持续交付的方式工作。同时发布了质量管理体系的工具。对于需求工程,我们使用验证计划和相关测试,以正式的方式验证了产品“Azure DevOps 的现代需求”。它简化了需求基线、需求评审过程和需求的可追溯性。


出于监管报告的目的,我们实现了自己的工具,称为“QTracer”。此外,使用验证计划和相关测试以正式的方式对该工具进行验证。新的 QMS 和相关工具的组合使团队能够更有效地制作符合法规的发布,同时减少法规性开销。


交付的稳定性是我们观察到的转型的整体影响的第一个迹象。与前一年相比,今年所有部署的生产部署失败率下降了一半。


2020 年,转型的突破成为可能。与前一年相比,今年所有部署的生产部署前置时间减少了 3/5。与此同时,与前一年相比,今年所有部署的生产部署失败率下降了一半。更多细节和相应的图表可以在后面的“速度和稳定性一起提高”小节中找到。


在 2021 年,软件交付的速度和稳定性的联同改进仍在继续。到目前为止,今年完成的所有部署的生产部署前置时间与前一年相比减少了 1/2。与此同时,与前一年相比,今年迄今为止所有部署的生产部署失败率下降了 2/5。更多细节和相应的图表可以在后面的“速度和稳定性一起提高”小节中找到。

转型易胜点

尽管转型是一个漫长而艰苦的过程,但在过程中也有点可以轻松取得胜利,详见下表:


改变解释
允许快速试验商业想法在全新的数字健康市场中,人们对产品类别和特定产品的了解甚少。对于产品和服务的支付意愿和有竞争力的价格点也是如此。在这种环境下,试验商业想法是商业活动的中心。利用快速商业实验探索市场的能力具有很大的竞争优势。在医疗保健领域,这就转变成了大约每两周到每月发布一次的产品需求。对于医疗设备软件产品,只要产品的预期用途保持不变,在首次提交监管后每月发布一次版本是可行的。对于非医疗设备软件产品,而受严格的非医疗法规(如ISO 9001)监管的公司每2-4周发布一次版本也是可行的。
将组织的文化转变为自发性文化在产品交付组织中,不同的小组和团队之间需要进行高度的协作,以进行频繁的发布。这自然会导致组织文化朝着自发性的方向发生积极的变化。自发性文化是以绩效为导向的。它的特点是高度合作、风险分担、不吝鼓励、探究失败等。当产品交付组织向更快的软件发布转变时,可以有机地支持这些特性。《加速》一书中的研究发现,自发性文化可以推动更高的软件交付和组织绩效。
改变软件交付的速度、稳定性和可靠性快速和稳定的软件交付需要高效的过程,如需求工程、开发、测试、部署、法规文档生成、发布和运维。这不仅可以在团队层面,也可以扩大到组织层面。有效地运维可以使产品实际迭代的可用时间最大化。

变革的主要挑战

在转型期间,我们遇到、减轻或解决了一些主要的挑战,详见下表:


挑战解释缓解
改变相关的质量管理体系(QMS)企业的法规性质量管理体系是基于来自所有相关地区的成文法、法规和审计结果的变化而逐年形成的。这导致质量管理体系中包含了团队所要满足的那些难以追溯起源的需求。此外,任何质量管理体系的变更都只能通过对原因进行审核证明的解释来完成,并证明所产生的过程以相同的方式履行了法律法规。综上所述,这些方面导致了质量管理体系管理者不愿意进行质量管理体系的变更,因为他们害怕使组织暴露于新的审计调查。我们尝试了以下方法来缓解这一挑战: 带领质量管理体系经理参观在受监管行业中仍实施持续交付的公司聘请在医疗器械法规方面有经验的顾问,与我们的质量管理体系经理共同设计质量管理体系变革对质量管理系统经理进行持续交付原则和方法的教育
改变人们的心态这种转型需要组织中所有角色对所有软件的交付进行彻底的重新思考。由于许多人、团队和团体同时改变了许多技术、组织和流程等相关内容,因此要避免变更不透明、模糊和晦涩,这是项很有挑战性的挑战。我们尝试了以下方法来缓解这一挑战: 为变更提供高层次的路线图解释变化的好处和所需的投资与选定的人员进行一对一地交流为选定的人员提供指导
展示转型快速取得的胜利那些没有积极参与正在进行的变革(例如提高交付速度)的人,他们所认为的变革结果需要很长时间才能实现,才能看的到我们尝试了以下方法来缓解这项挑战: 定期向领导汇报,解释所做的改变和取得的成果在公司范围内的活动上展示正在进行的转型和已经取得的收益
一边做事一边转型在转型期间,企业对新特性的需求一直居高不下。在新特性实现、转型活动和已有特性的运维中分解开发能力变得非常具有挑战性。因此,转型速度会相当缓慢。我们尝试了以下方法来缓解挑战: 为团队提供能力划分的指导方针帮团队理解在转型上做投入将获得的收益和好处
产品的架构解耦当转型开始时,所有的团队协作产品在体系结构上是紧密耦合的。为支持独立的产品发布,需要做必要的架构解耦,这需要很长的时间。针对新特性的架构解耦的优先级一直是一个主要的挑战。我们尝试了以下方法来缓解这个挑战: 将架构变更引入项目组合管理,在组织级别增加可视性向产品所有者解释架构解耦以支持独立产品发布有什么好处让架构师了解必要的架构解耦、解耦的原因、执行它们的好处以及可以实现的结果当一个主要的架构分离完成时庆祝成功促进团队之间的知识共享,使他们能够更好地估算重新构建服务所需的时间
使TDD成为默认的软件开发方法尽管TDD是一种持续交付的基本方法,但是使TDD成为默认的软件开发方法却是一个主要的挑战。 引入TDD的是有前途的。与有TDD经验的顾问一起工作是富有成果的。然而,随着时间的推移,应用TDD的团队和个人的数量减少了。我们没有设法让TDD在团队正在进行的编程工作中得到实践。我们尝试了以下方法来缓解这项挑战: 鼓励团队将TDD应用于新开发的代码鼓励团队重构正在编写的代码,为将来的TDD工作做好准备按需提供可供实践操作的代码类


总的来说,从定义上讲,涉及人员、过程、技术、组织和法规变化的长期过程调整将具有挑战性。一个有远见有勇气的领导是成长和保持势头的必要条件。在这个过程中,要不吝于展示和庆祝一次次的成功,这能极大地帮助人们保持旺盛的积极性,经受住新出现的挑战。


由于转型的各个方面有大量的选项可供选择,因此几乎不可能对这个过程进行特别严密的计划。一个可行的替代方案是,陈述转型的高层次业务目标,并进行适当地量化。然后让团队定义中间里程碑来探索他们实现目标的路径。

大变革的机会

尽管转型是一个漫长而艰巨的过程,但它抓住了重大机遇的关键,详见下表。


改变解释
允许快速试验商业想法在全新的数字健康市场中,人们对产品类别和特定产品的了解甚少。对于产品和服务的支付意愿和有竞争力的价格点也是如此。在这种环境下,试验商业想法是商业活动的中心。利用快速商业实验探索市场的能力具有很大的竞争优势。在医疗保健领域,这就转变成了大约每两周到每月发布一次的产品需求。对于医疗设备软件产品,只要产品的预期用途保持不变,在首次提交监管后每月发布一次版本是可行的。对于非医疗设备软件产品,而受严格的非医疗法规(如ISO 9001)监管的公司每2-4周发布一次版本也是可行的。
将组织的文化转变为自发性文化在产品交付组织中,不同的小组和团队之间需要进行高度的协作,以进行频繁的发布。这自然会导致组织文化朝着自发性的方向发生积极的变化。自发性文化是以绩效为导向的。它的特点是高度合作、风险分担、不吝鼓励、探究失败等。当产品交付组织向更快的软件发布转变时,可以有机地支持这些特性。《加速》一书中的研究发现,自发性文化可以推动更高的软件交付和组织绩效。
改变软件交付的速度、稳定性和可靠性快速和稳定的软件交付需要高效的过程,如需求工程、开发、测试、部署、法规文档生成、发布和运维。这不仅可以在团队层面,也可以扩大到组织层面。有效地运维可以使产品实际迭代的可用时间最大化。

速度和稳定性相辅相成

如前一章所示,在转型过程中,速度和稳定性都得到了提高。在下面的图片中可以看到速度和稳定性指标细节。


从转型多年的生产发布提前期趋势来看,在很长一段时间内,2016 年至 2019 年,提前期没有减少。相反,在 2019 年,尽管所有转型都在做出努力,交付时间却有所增加。然而,自 2020 年以来,交付提前期大幅下降:从 2019 年到 2020 年的交付提前期下降了超过 3/5,除此之外,从 2020 年到 2021 年的交货期下降了 1/2。也就是说,自 2019 年以来,生产前置时间减少到了 1/5!


下图显示了经过多年改造后的生产部署失败率趋势。结果表明,在 2016 年至 2018 年的很长一段时间内,故障率并没有下降。相反,在 2018 年,尽管所有的转型都在进行努力,但它达到了历史峰值。然而,自 2019 年以来,生产部署失败率稳步下降:2018 年至 2019 年为 1/2,2019 年至 2020 年为 1/5,2020 年至 2021 年为 2/5。也就是说,自 2018 年以来,生产部署失败减少到了 1/4!


上面的两张图片表明,自 2020 年以来,软件交付的速度和稳定性一直在同步提高。同时,生产部署前置时间和故障率也呈下降趋势。也就是说,软件交付速度越来越快,也越来越稳定。


由于以下原因,只有在经过几年的改造之后,速度和稳定性才得到提高:


  • 当转型开始时,组织对持续交付方法还缺乏了解。为了建立知识体系并得到一套适合组织并被组织接受的方法,需要恶补大量的知识、进行大量的实验。

  • “一边做事一边转型”:转型的同时,还在同步实现着使用新技术的面向客户的新特性。这是商业上的需要。特性实现占用了开发很大一部分精力,留给转型活动的并不多。

  • 由于转型和特性开发活动之间都占用开发的精力,诸如架构分离、创建每个团队独立部署的管道和测试重构等技术变革需要很长时间才能到位。

印证《加速》一书中的研究成果

由 Nicole Forsgren、Jez Humble 和 Gene Kim 撰写的《加速——精益软件和 DevOps 的科学:如何构建和扩展高效能的技术组织》一书介绍了基于对全球 400 多家公司的软件交付的调查研究。Randy Shoup 在他的演讲“大规模快速发展”中用下面的两张图片简要总结了这本书中的研究。


作为研究的一部分,研究人员分析了两类公司:高绩效公司和低绩效公司。在软件交付速度方面,高绩效的每天部署大约 10 次,交付时间不到一个小时。低绩效的大约每月部署一次,准备时间大约为 6 个月。


有趣的是,在这两类之间并没有很多公司。也就是说,接受调查的公司往往要么表现出色,要么表现欠佳。更有趣的是,根据上图所示的交付速度,绩效相同的公司在交付的稳定性方面也是相同的,如下图所示:


高绩效的生产部署几乎从不失败。即便是失败了,不到一个小时就能恢复。另一方面,低绩效的会有将近一半的生产部署失败。生产部署失败后恢复时间超过一天。


由于大多数公司在速度和稳定性方面是相同的,因此可以得出结论,在软件交付中,速度和稳定性是密不可分的。事实上,软件交付的速度越快,它就变得越稳定。


这听起来可能违反直觉。然而,《加速》一书中严谨的研究结果证明了这一点。在我们的软件交付转型过程中,我们可以直接看到交付的速度和稳定性是如何同时得到提高的。也就是说,我们的转型确实可以印证《加速》的研究成果。

转型回顾

对这次转型进行回顾,可以加深以下经验教训。


  1. 这次转型从一开始就不是以数据驱动的方式驱动的。只有在随后的过程中,才在组织和团队层面制定了持续交付的速度和稳定性指标。我们建议从转型一开始就制定这些指标。这可以根据Steve Smith的《测量持续交付》一书来完成,该书详细描述了部署管道所有阶段的速度和稳定性指标的定义和实现。速度指标结构为生产部署、提前时间和生产部署频率。稳定性指标结构为生产部署失败和生产部署恢复时间。


拥有组织和团队层面的指标,可以使组织中的人就转型所要实现的目标更快更深入地达成一致。此外,它使团队能够以数据驱动的方式设定自己的速度和稳定性中间目标。最重要的是,这些指标允许在整个组织中适当地应用改进型工具,将持续改进作为推动转变的一般方式:


步骤描述速度和稳定性指标的应用
1得到的方向表示为长期的速度和稳定性目标
2把握现状通过查看当前速度和稳定性指示值
3建立你的下一个目标条件表示为下一组速度和稳定性目标
4通过实验来达到这个目的进行技术、流程、组织等方面的变更,并使用速度和稳定性指标衡量变更的影响


2.SRE 的引入和总体的可操作性是在后期的改造中完成的。我们建议在转型过程的早期迂回完成这些方面。这满足了在转型过程中“构建,运行”的态度、过程和工具的成长,而不是在建立了持续交付之后被视为另一个大的转型步骤。此外,可靠性 SRE 指标可以定期用于改进型工具。


例如,可以针对服务可用性占比和时间建立可用性指示器,以便在不可用时重新建立可用性。可以在可用性指标下定义长期和中期目标,并不断迭代。


3.在以新方式工作方面,我们学到了,既向人们提供新方法的知识,又由熟练使用这些方法的人进行指导,是一种强有力的组合。也就是说,在为人们分配学习时间时,仅仅提供学习材料或培训是不足以改变习惯的。出于同样的原因,仅仅提供接触到教练的机会是不够的,大家无法充分理解为什么要接受指导。所以,单靠指导也不能改变习惯。


相比之下,往往在有经验的教练的指导下,将最初的学习和长时间的应用相结合,才会改变个人和团队的习惯。最初的学习理解了应用新方法的潜在原因、好处和背景。随后,与一位经验丰富的教练一起应用新方法,通过一个频繁而有力的反馈环,在小范围内调整过程,将新方法融入到日常工作中。


4.通过在架构、测试、部署、法规遵从性、发布和运维方面分离服务,可以减少生产部署的前置时间。随着独立服务数量的增加,需要一个轻量级的治理,以便集中维护组织范围的最佳实践、协议和规则,同时尽可能让团队保持独立性。


建立治理可以受益,例如使用一个严格的平台,将最重要的控制节点编成法典。这些活动应该是转型的一部分,而不是在转型显露出成功迹象之后再做安排。通过这种方式,可以有机地开展必要的治理,从非常小的步骤开始,比如服务和环境的命名。


我们在转型的后期开始了治理活动,建议在构建第一个独立服务时推广该实践。

总结

加速软件交付是一个长期的转型过程。可以使用速度和稳定性目标有效地引导该过程,并使用相应的指标进行测量。畅销书《加速》中的研究表明,速度和稳定性是相辅相成的。在此之后,这两项措施应该同时改善。西门子医疗团队数字健康平台的软件交付转型印证了这本书中的研究。在转型过程中,速度和稳定性都得到了提高。

致谢

他们在推动西门子医疗团队数字健康平台软件交付转型中发挥了重要作用,我们表示感谢:Thomas Friese、Carsten Spies、David Schottlander、Fabio Giorgi、Frank Schneider、Frank Stanischewski、Philipp Guendisch 等。


此外,我们还要感谢以下持续交付顾问,他们在转型过程中提供了无价的帮助:持续交付有限公司的 Dave Farley,以及来自Equal Experts有限公司的 Neha Datt, Ryan Bayly, Marcel Britsch, Keerthana Jayaram, Louis Abel 和其他许多人。


最后,感谢 Akshith Rai 维护了团队中的持续交付指标。


作者简介:


Vladyslav Ukis 博士毕业于德国埃尔兰根-纽伦堡大学计算机科学专业,之后又毕业于英国曼彻斯特大学。毕业后加入西门子医疗,在软件架构、企业架构、创新管理、公私云计算、团队管理、工程管理和数字化转型领域工作。自 2018 年以来,他一直担任西门子医疗团队数字健康平台和应用的软件开发经理,推动持续交付和 SRE 转型。自 2021 年以来,他还担任所有西门子医疗数字健康产品的可靠性经理职务。


原文链接:


Improving Speed and Stability of Software Delivery Simultaneously at Siemens Healthineers


译者简介: 冬雨,小小技术宅一枚,从事研发过程改进及质量改进方面的工作,关注编程、软件工程、敏捷、DevOps、云计算等领域,非常乐意将国外新鲜的 IT 资讯和深度技术文章翻译分享给大家,已翻译出版《深入敏捷测试》、《持续交付实战》。

2021-11-12 13:558632

评论

发布
暂无评论
发现更多内容

国庆节,零代码帮你搞定假期美食菜单,体验赢定制好礼

华为云开发者联盟

人工智能 企业号九月金秋榜

UI 自动化测试应不应该投入?有没有前途?怎样做最明智?

测吧(北京)科技有限公司

测试

软件测试 | 测试开发 | Python 自动化测试(三): pytest 参数化测试用例构建

测吧(北京)科技有限公司

测试

SBOM:缓解软件供应链风险的关键

SEAL安全

DevSecOps 软件供应链 SBOM 软件供应链安全

Java中Interface天天都在写,你知道其背后的原理是什么吗?

wljslmz

Java 接口 9月月更

一道React面试题把我整懵了

beifeng1996

React

vue项目性能优化-前端加分项

bb_xiaxia1998

Vue

面向对象设计原则,历久弥新

有态度的马甲

【web开发基础】PHP快速入门(5)-PHP运算符之算术运算符和字符串运算符详解

迷彩

运算符 php开源 9月月更 web开发基础 算术运算符

从URL输入到页面展现到底发生什么?

loveX001

JavaScript

互联网进入存量博弈时代,小程序技术创造移动应用新机遇

FinClip

finclip

软件测试 | 测试开发 | Junit5 架构、新特性及基本使用(常用注解与套件执行)

测吧(北京)科技有限公司

测试

Java进阶(三十七)java 自动装箱与拆箱

No Silver Bullet

Java 9月月更 自动装箱 拆箱

面试官让你说说react状态管理?

beifeng1996

React

new Vue的时候到底做了什么

bb_xiaxia1998

Vue

小程序化:系统集成行业降本增效的破局思考

FinClip

P5~P9应该具备的核心能力是什么

博文视点Broadview

源码学习之MyBatis的底层查询原理

京东科技开发者

Java sql 源码 mybatis mybatis源码

keep move!滑动窗口中位数与滑动魔方

掘金安东尼

算法 9月月更

orbeon form 通过 url 的方式同第三方应用集成的开发明细

汪子熙

Java SAP commerce form 9月月更

软件测试 | 测试开发 | UI 自动化测试实战(二)| 测试数据的数据驱动

测吧(北京)科技有限公司

测试

软件测试 | 测试开发 | Pb协议的接口测试

测吧(北京)科技有限公司

测试

软件测试 | 测试开发 | PageObject(PO)设计模式在 UI 自动化中的实践总结(以 QQ 邮箱登陆为例)

测吧(北京)科技有限公司

测试

sentinel-dashboard-apollo 1.8.5 发布,支持 apollo 持久化的定制版

铁匠

一键实现设备高稳定高安全管理——设备管理运维类

阿里云AIoT

分布式数据库 安全 监控 物联网 存储

Python 测试开发实战进阶,技能对标阿里 P6+,挑战年薪 50W+!

测吧(北京)科技有限公司

测试

大数据ELK(八):Elasticsearch安装IK分词器插件

Lansonli

ES 9月月更

仅需30行代码,轻松集成HMS Core视频编辑服务屏幕录制能力

HarmonyOS SDK

编辑 视频

禅道项目管理软件App使用

禅道项目管理

项目管理 App 禅道

Ohos-MPChart——支持多种图表绘制的组件

OpenHarmony开发者

OpenHarmony

软件测试 | 测试开发 | Python 自动化测试(四):数据驱动

测吧(北京)科技有限公司

测试

西门子医疗如何同步提高软件交付的速度和稳定性_文化 & 方法_Vladyslav Ukis_InfoQ精选文章