新闻动态

这里有最新的公司动态,这里有最新的网站设计、移动端设计、网页相关内容与你分享!

高效能不等于开发快,大模型时代如何正确提升研发效能?

从最初的敏捷软件开发方法到 DevOps 成熟度尊龙凯时app平台官网模型,研发效能的发展历程经过多个阶段。如今,基于大模型的 AIGC 技术正在催生软件工程的新范式,为研发效能的提升带来新的可能性。目前,越来越多的企业开始在实际的研发工作中,结合大模型增强软件开发在设计、需求、测试、发布和运维等各个环节中的能力,提高质量和效率。

在今年 9 月 3-5 日举办的 QCon 全球软件开发大会·北京站中,Thoughtworks 中国区总经理肖然担任《AIGC 浪潮下的研发效能提升》专题出品人,该专题探讨了 AIGC 浪潮下,大模型对软件研发工作流的改变,以及大模型是如何提升研发效能和质量的。以下为 InfoQ 与肖然的对话实录,经编辑。

InfoQ:您作为 2023 QCon 全球软件开发大会·北京站《AIGC 浪潮下的研发效能提升》专题出品人,能分享下您对这个主题的理解吗?对于这波大模型结合软件开发应用热潮,您观察到哪些有趣的趋势?

肖然:ChatGPT 一经推出,全球最活跃的是很多技术自媒体,给大家展示自动化的代码生成,一些实例甚至直接生成可运行的小应用和游戏。目前最成功的 GPT 应用是 GitHub 为开发人员推出的 Copilot,甚至于这个单词成了系列 AI 应用的代名词。所以说,大模型在软件研发中的应用实际上已经开始了。

软件工程领域有一个大家比较认可的定义,即软件开发是人类历史上最复杂的脑力协作。“脑力”给我们带来了工作量度量的麻烦,我们没法像控制肢体运动一样控制思考;“协作”当然也不是免费的,要让另外一个人按照你的想法来做事情,沟通和理解的成本很高。由此也造成长久以来软件研发效能管理上的巨大黑洞。

这两年由于数字化的深化,整个社会全产业对于软件的依赖性提升很快,客观上就推动了软件研发团队和组织的快速扩大。人多了自然效能管理就更重要了,但软件本身的“人月神话”等悖论,明确告诉我们用传统方式一定是越管越慢。虽然类似 DevOps、CloudNative 这些运动在向着正确的方向推动我们对效能度量和效能管理的认知,但实际上我们还是缺乏一些本质上的治理手段。

所以当 ChatGPT 出现后,在不同的技术社区就开始发酵,大家看到了这一波基于大模型的 AIGC 技术带来的可能性。我们以前重来没有思考过的效能提升视角也逐渐浮现出来,比如研发团队不同专业之间的知识管理问题,之前我们还是在不停地鼓励和训练大家换位思考、高效沟通,现在出现了一个可以包容各类专业知识的大模型,这个“超级队员”之前是不存在的。而这个超级队员的出现,必然会给我们带来新的效能提升思路和方式。就《AIGC 浪潮下的研发效能提升》这个专题,是值得我们接下来几年持续研讨的,也会是研发效能治理领域最热门的一个赛道。

InfoQ:有观点认为研发效能已经成为一家科技公司的核心竞争力,您是否认同?根据您的行业观察,这些年来企业的研发效能发生了哪些变化?

肖然:首先我们还是要明确研发效能的定义,目前也不是完全统一。比较好的定义可以参考类似 DORA 这样的全球报告,国内也有一些专家小组做了比较好的定义。总体上我们应该避免“高效能就是开发快”这样一个认知误区。当然,这些年在效能领域的一个显著变化是大家认知更透彻了,很多企业还结合自身的业务特点在看待研发效能,比如银行业监管机构都提出了“双模”,即两种研发节奏,明确不是所有系统开发都追求快,要适配业务模式。

在正确的效能定义的前提下,确实研发效能高是一家科技公司的核心竞争力。本质上未来的很多公司都是科技公司,因为业务在大面积的数字化,由此也带来了很多公司不断提升自身的科技人员占比。从这一点出发,这些年来企业在研发效能治理上投入是逐年增加的。很多企业抓住 DevOps 这个切入点,开始系统性的看待研发效能问题,从端到端的价值流视角来建立分析和改进体系。这点从行业角度看是可喜的。

当然我们也存在比较大的管理效能指标的问题。很多企业管理着希望能够“看见”,所以开始建立效能方向的指标体系。但这种通过指标体系来管理的方式也容易走上治标不治本的道路,软件开发过程中处理的复杂度很难通过指标来说明问题。本质上研发团队和专业人员的能力提升才是核心,不要因为建立了指标反而忽视了效能治理的关键命题。目前看大模型的出现也并不能替代研发专业人员,而未来的应用和系统因为大模型的加入会变得更加复杂。

InfoQ:过去大家提到研发效能一个比较头疼的点是,如何正确、有效的度量,结合 AI 技术,研发效能度量发生了哪些变化?AI 大模型在研发效能提升方面还有哪些独特的优势和潜力?

肖然:度量在过去几年有比较大突破,特别是 DORA 经过研究发布了 DevOps 领域的 4KM(四个关键指标)。软件研发的度量关键是尽量面向端到端的价值流,设计指标时关注协同效率,而不是单兵的生产效率。

大模型这个“超级队员”的加入,实际上让我们更加容易进行端到端的度量,很多协同工作是可以通过大模型来自动完成的,自然就形成了更为完整的过程数据。目前应用大模型上比较火热的是 AI Agent,我们可以预期未来针对效能度量和分析都会有相关的 Agent 出现。

InfoQ:Thoughtworks 围绕大语言模型结合软件开发有哪些探索?您能分享 1-2 个具体的案例,以及你们在其中的思考/踩坑经验吗?

肖然:首先肯定是类似 Copilot 这样工具在开发过程中的应用。由于 TW 崇尚结对编程的实践,所以 Copliot 的接受度很高。这种模式其他研发角色如 BA 和 QA 都会用自己的工具尝试,总体上我们认为是现有专业工作的增强,效果是明显的,比如 QA 在准备测试用例时采用大模型来自动准备,仅测试用例的数据准备就能够从半天缩短到十几分钟。

另外一个类型的尝试就是关注专业角色的协同,比如我们开源的 Boba 平台(https://martinfowler.com/articles/building-boba.html),就是整合了多个相关大模型应用,完成从市场研究到需求拆分的产品设计全过程。这种尝试目前还没有专业增强那么成熟,更多起到了“help me to learn”的效果。但我们认为这个方向在研发领域是潜力无限的。

踩坑主要还是数据和信息安全问题,为了得到更为准确的生成结果,不可避免我们需要提供更多的上下文给大模型。目前类似 OpenAI 这样的大模型厂商并不能提供企业级数据和信息安全的保障,所以往往一些核心业务系统仍然难于使用。随着越来越多的开源模型发布,我们也帮助不少企业开始部署和微调私有的大模型。私有大模型一般会采用企业自己的系统作为语料去微调模型,在采用了类似 Llama 2 这样的基础模型之后,生成代码的可用度已经能够达到 50%以上。

也有企业从成本和风险角度考虑,希望仍然采用公有大模型,这个时候我们就需要针对企业数据进行脱敏处理,并且建立相关的矢量存储来作为企业私有知识的管理。目前相关的架构在逐步稳定,开源的工具也越来越多。

InfoQ:当前 AI 研发效能提升的技术瓶颈和挑战是什么?如何评估 AI 研发效能提升技术的性能和效果?

肖然:目前最大的挑战实际不在于大模型本身,而在于人员能力的提升。大部分研发人员开始时都是单一问题的 0-shot prompt,不能够很好的和模型互动,由此得到的生成结果也不尽如人意。

另外一个挑战就是很多企业认为只要有了大模型,每个人跟模型提问互动就是应用了。曾经在 Hadoop 兴起的大数据时代,很多企业也认为只要部署了 Hadoop,就是拥有了大数据能力。显然如果希望大模型在企业里变得普适可用,有很多工程化和平台化的基础工作是要预先设计和部署的。

目前其实还不适合去做评估,可以进行一些数据的采集,反应大家真实的使用感受。评估很可能带来的副作用是大家不愿意真实的反应实际情况。比如一个季度前,我在内部和 BA 社区开会研讨,很奇怪为什么使用反馈很少。线下找到老同事了解,才知道原来大家担心公司管理层知道了使用大模型提升效率,造成后续更多派活或直接减员。显然这个担心是多余的,但评估可能传递这样的错误信号。

就当前阶段,我的建议还是在条件允许的情况下,鼓励大家多使用、多尝试,欢迎大家提炼总结新问题和新方法。

InfoQ:目前市面上存在很多结合大模型的研发效能工具,但在一些企业的端到端落地过程中并不理想,也没有实现提效的突破,这背后存在哪些挑战?在不同场景下,如何选择和调整 AI 研发效能提升技术来满足不同的需求?

肖然:首先还是需要明确采纳的方向和目的,如分享 TW 采用大模型经验,我们会从“专业增强”和“协同增效”两个主要方向去考虑大模型的应用:

基于这两个方向,可以考虑不同的具体场景,场景选择上要结合研发组织自身的特点。比较好的方式是举办内部的创新应用比赛/黑客松,利用这样的形式让更多的人来一起想、一起实验。由于大模型技术本身仍然在快速迭代,依靠自上而下地规划反而容易造成应用不接地气,难有真正成果。

InfoQ:您认为大模型在软件研发工作流中最大的价值是什么?大模型对软件研发工作流的改变,将会如何影响软件开发行业的未来发展趋势?

肖然:软件研发本身是隐式知识的显式化过程,通俗讲就是用户开始说不清楚要什么,之后通过产品一轮又一轮的迭代慢慢清晰。从这点出发,我认为大模型在软件研发过程中最大价值是知识管理,因为这个“超级队员”的知识存储能力超过了任何人类个体和团队。

一旦大模型真正有效成为了知识的管理员,我们软件研发的专业分工就要发生变化。这种变化还不仅仅是我们现在可以看到的“全栈工程师的复兴”,而是真正意义上的角色重新定义。当然这并不意味着我们专业人员变少了,相反新的专业分工可能出现,比如维护大模型的工程师、测评大模型的分析师等等。

我们已经无法预测未来的发展趋势,但我想在开放的心态下,我们应该躬身入局,建立自己的感知网络,从而能够持续进化。

InfoQ:大模型会对程序员带来哪些冲击?程序员如何和大模型更好地共生?

肖然:程序员需要更加关注原则和设计。大模型自动生成代码和应用只会日趋完善,但生成的质量仍然是需要程序员来判断,一些关键问题,如性能和安全,更是需要程序员来负责。所以程序员需要更多思考一些原则和本质的东西,这样才能支持有效的判断。

大模型是生成式的 AI,生成内容的质量很大程度取决于问题的质量,也就是我们现在经常谈的 prompt engineering(提示语工程)。目前很多模式正在被提炼和总结出来,每个程序员都应该持续学习。但即使有了问题的模式,问题的内容仍然是程序员个体决定的。这就像使用 TDD 的高手,面对复杂需求总能够庖丁解牛一般找到合理的任务拆分。同理,能够通过 prompt 一步步引导大模型生成高质量的内容本身就是一项关键能力,而这个能力跟程序员的设计思考是密切相关的。只有善于设计的人,才能够和大模型进行有效的互动。

InfoQ:AIGC 的未来发展和趋势是什么?您认为未来 AIGC 技术会对研发效能提升带来哪些新的机遇和挑战?

肖然:在软件研发上下文下,我觉得 AIGC 最重要的发展趋势是多模态 MultiModal,即听说读写样样精通。结合前面提到的知识管理,研发效能的提升将很快突破单个专业的提效,产生整体质的飞跃。想象未来客户描绘了一个场景,大模型帮助下快速转换为视频故事,在做产品前就能够让客户有身临其境的感觉,同时也可以通过高度的可视化让团队快速共识理解。

这样的可能性在即将到来的多模态时代应该说潜力无限。软件研发对于每个从业者来说最重要的还是持续提供可学习的知识。而通过多模态,我们专业个体的学习能力也会被千百倍的放大。作为一个专业研发人员,我也很期待将大模型多模态的能力应用到我们的研发过程中去。

肖然,Thoughtworks 中国区总经理,中关村智联创新联盟秘书⻓。在过去 10 年时间里,肖然带队先后为金融、保险、通信、物流、零售等核心产业的头 部企业提供了⻓期的从战略执行到组织运营各个方面的咨询服务,以务实的工作作⻛得到了行业内的广泛认可,也成为了中行、招行、华为等头部企业的高管参谋,为企业的⻓期发展出谋划策。

下一篇:没有了