本文为 CODING 协同产品总监张路宇 在腾讯云 CIF 工程效能峰会上所做的分享。文末可前往峰会官网,观看回放并下载 PPT。
欢迎各位朋友,来到腾讯云 CIF 工程效能峰会的分论坛,我是 CODING 的产品经理路宇,很高兴能以这种方式与大家见面。在接下来的主题环节中,会由我先为大家带来 CODING DevOps 研发平台的产品理念和全景解读,我们还邀请了几位今年下半年的新产品负责人给大家带来关于项目协同、WePack、以及全新产品持续部署 Oribt 和研发流程管理 Compass 的分享 (讲稿已在陆续发出)。
我加入 CODING 已经三年了,此前有近十年的研发管理经历,我同时是一个不折不扣的效率工具爱好者。过去几年里我看到了本土研发团队、业界,以及 CODING 产品对研发工具理念理解的三个阶段性变化:从工具、到工具箱、再到软件工厂。
西方经典管理理论认为,组织效率可以归为劳动效率、组织效率和人的效率。美国管理学家泰勒所著的《科学管理原理》被德鲁克誉为“20世纪最伟大的发明”,劳动效率说认为分工提升生产效率,福特的流水线就是分工和工业化的典型代表。经济学家亚当斯密在《国富论》描述了螺丝制造的十八道工序,分别由十八个专门的工人负责完成。以马克思·韦伯为代表的组织理论家认为,有效的划分岗位,形成官僚组织结构能够释放效率,合理、合法的权利是促进组织达到自身目标的必要条件。组织效率最大化的手段是专业化水平与等级制度的结合。用我们今天的话说,就是让不同专业能力的人匹配适合的岗位。 玛丽·芙丽特则提出了「以人为本」的人力资源管理理论,更加关注人的心理,管理中需要平衡员工需求与组织发展的目标。
现代数字化、平台化企业强调创新和协同,在经典管理理论的基础上又提出了新的挑战,仅仅分工已经不能满足市场的需要,我们发现:
1.强个体的价值崛起, 最有价值的创新是由企业内少部分人完成的;
2.影响组织绩效的因素由内部转向外部, 所有员工都需要关注交付内容的价值和客户需要。效能 = 价值 X 效率。如果价值为 0,再高的效率也于事无补;
3.由于需求多样化和快速变化,驾驭不确定性成为组织的核心挑战。 不确定性是一把双刃剑,能够把握不确定性便是专注了企业发展的机会。
以上,是我们认为的数字化协同的理论根基,管理逻辑正在从分工走向协同,好的工具需要遵循经典的分工理论,但更加需要注重数字经济时代的协同需求。
我们提出这样一个问题 —— 软件研发还是数字化协同的领军行业吗?我找了这样一张 DevOps 2021 年的生态地图,如下图所示,像这样的图片想必大家近年来看到了许多。围绕代码的构建、测试、部署、运行环境、监控、项目管理以及信息流等等的工具层出不穷,这反映了我们所处的技术环境正在快速变化,软件从业人员的确越来越善于使用工具。
你的团队可能在用 Jira 进行项目管理,用 Gitlab 管理代码,用 Jenkins 实现持续集成,用 JFrog 管理制品……但是,一个研发团队需要使用如此多的工具,作为技术决策者在选择时面临不少的压力。从学习、部署再到应用,成本经不起计算。一位新同事入职,需要开上七八个账号,数字资产的管理面临潜在风险。
更重要的是,我们认为在这种工具集形态下,没有给开发者和管理者提供一个真正有效、柔性边界协同的环境。
显然,相比一些高集成度的数字化行业,甚至传统行业,我们不能自信的说我们正保持领先。技术决策者们刚刚走出工具时代,正停留在工具箱时代,迫切的需要一个新形态的协同环境迎接挑战。因此,CODING 提出了数字化软件工厂的概念。这也恰好符合 CODING 产品的演进路线。
2014 年,CODING 率先推出基于 Git 的代码托管服务工具,成为国内领先的代码托管服务平台,也是在此时提出了「云端开发,让开发更简单」的理念。2018 年,我们推出项目协同、持续集成、Cloud Studio 等产品,形成了一系列的必备研发工具,这些工具经过时间的打磨已经达到了国内较领先水平。去年,CODING 首批获得了信通院 DevOps “卓越级”认证,这也是国内最高级别的 DevOps 工具体系认证。今年,我们提出战略升级,结合现代软件工程实践和先进理念,推出研发度量、研发流程管理 Compass 等产品,打造有开放生态能力的数字化软件研发工作流。
“要充分发挥勤勉认真的技术人员的技能,建立一个自由豁达、轻松愉快的理想工厂。”——这是索尼公司已故创始人,井深大先生在公司成立之初写在《成立宣言》中的一句话。我个人非常喜欢这句话,并以它为团队管理和产品设计的信念愿景。
作为软件企业,需要站在现代软件工程理论之上和技术前沿之上,没有工程师可以脱离技术谈效率。同时,管理效率不仅仅来自于分工,更来自于协同。我们对先进研发管理工具有三点基本理念:
1.注重协同效应,1+1 > 2, 每个人都能获得交付价值所需的信息上下文环境,让团队中强个体能够更强;
2.超越流程,基于卓越工程实践。 既要打造优秀的单点工具,也要紧紧围绕云原生、DevOps 等技术理念,让每一个研发团队以更短的路径运用卓越团队的工程理念;
3.一致性、沉浸式的融合体验。 紧密的集成用户界面和数据,为每个开发者创造能保持专注的线上工作环境。
接下来我将为大家介绍 CODING DevOps 一站式全景。下图体现了 CODING 的主要能力分布,从能力维度上,我们可以将其划分为项目协同、流水线、测试管理、制品管理、持续部署、知识管理、研发流程管理、PMO Office 及团队管理几大模块。
为了便于理解,我们可以将其中几大模块对应一些朋友熟悉的 Jira、Jenkins 等,基本覆盖了成熟软件工程实践中的全部所需。我们可以从项目管理、工程管理和团队管理三个视角对它进行解读。在 CODING 中,「项目」是基本的协作容器单位。它可以泛指一个有生命周期的工程,也可以代表一个固定工作方式的项目团队。当需求进入需求池后,研发团队可以使用以 Scrum 为代表的敏捷模型,也可以使用偏向计划驱动的经典瀑布模型。史诗代表可以横跨迭代的大粒度需求,需求、任务、缺陷等是基本事项分解单位。CODING 包括了一个成熟的代码仓库服务,需求和代码提交、分支之间能够进行关联。
运用全新的研发流程管理产品 Compass, 研发负责人可以对项目的工作流进行约束和自动化配置。例如需求变更状态时,检查对应的代码分支是否通过了自动化测试,开发者提交代码时需要遵循代码分支的命名规则等。
从工程管理视角看。CODING 涵盖了一套健壮的可视化流水线能力,包含持续集成、制品管理、持续部署等。持续集成的目的是实现更快的发布频次,运用「测试左移」的理念,结合代码扫描和自动化测试的能力,研发团队可以实现每天几十次的可靠集成与发布。集成所产生的编译结果将被纳入到制品管理之中,便于版本索引和加速测试和发布过程。制品扫描功能可以在不访问源代码的情况下,通过扫描二进制组件及其元数据,找寻组件中存在的漏洞。
持续部署能以自动化方式,频繁而且持续性的将软件部署到生产环境,使软件产品能够快速的交付使用。持续部署模块中,涵盖了测试、生产环境的发布目标环境信息。根据发布计划,可以应用蓝绿发布、金丝雀发布等多种发布策略推送制品至线上环境。到这里,工程实现了从需求到发布的 DevOps 完整闭环,全环节的价值流、代码流、制品流上下文在 CODING 平台中清晰、透明。
缺乏对人力资源的管理是过去散装研发管理工具的弊端。为了适应不同规模研发团队的管理需要,结合本土研发团队的管理特点。CODING 在跨团队、跨项目的横向侧提供了一系列团队管理工具,深度发挥了一站式产品高数据集成度的优势。
同时 CODING 包含了一个全新的 「知识管理」 模块,知识空间可以挂载在项目之下或单独使用。可以使用 Markdown 或富文本的形式编写和组织产品文档,基于块集元素的文档结构可以让团队成员在文档中自由嵌入例如需求卡片、思维导图、表格等多种内容结构。
通过「团队目标」功能,可以在组织层运用 OKR 管理方法,CODING 中可设置公司级、部门级与个人级的目标视图,关键结果可与需求进行关联实现执行分解和跟踪。如果团队成员都能够通过目标管理机制,从「要我做」转变为「我要做」,毫无疑问这将会是一个充满机动性与高效能的团队。
团队视角的管理是今天更多成熟组织关心的产品能力,CODING 在平台层已经涵盖了组织架构管理、集中权限管理等等,我们期待能够吸纳和传递更多卓越团队的管理实践。在稍后的环节里,我也将为大家介绍今天发布的两款新的团队级管理工具:研发度量和工作负载。
话说回来,我们相信工具和平台是以人为本,为人服务的。工程师的极客精神和惯性信念是「自己动手,丰衣足食」,技术决策者也面临自建工具,和公有云平台之间的选择。那么为什么 SaaS 平台好于自建工具呢?我在这里打一个比方。自建工具与云上平台的关系,好比宠物与牲畜的关系。宠物,例如猫、狗,是娇贵的,需要持续付出成本与精力细心养护,人为宠物提供关爱与服务,以换取情绪价值;牲畜,例如牛、马,则是人类经过演化筛选的生产工具,天生是为人类提供生产价值的。
仍然有相当多研发团队为自建工具无意识的、不计成本的投入,少则投入几人,多则投入几十人成立工程团队,进行学习、搭建、维保和开发工作。这种宠物思维忽略了工具的生产为主的天性,也忽略了云技术的演进和社会分工能带来的巨大效率优势。 值得一提的是,CODING 拥有了可能是国内 DevOps 领域最大规模的高水平研发团队,团队成员有着丰富的技术、工程和用户体验积累。我们建议,技术决策者可以从运维成本、配置成本、易用性、权限管理、度量与规范等各个角度去做一次理性选择:是自建工具更好,还是一站式平台更好。
此外 CODING 还拥有以下优势:
希望以上我的介绍,能让大家对一站式研发管理平台的理念和优势,有一个概览性的认识。现在为大家带来我们一系列的新产品,首先是研发度量。
德鲁克曾写道:“你如果无法度量它,就无法管理它。”这句话充分体现了度量在管理中的份量。对于注重研发效能的团队来说,我们渴望去测量和提升创造价值的速度,我们渴望通过度量去及时发现和改进质量问题,渴望能够比较组织内团队之间,甚至与行业内其它团队之间的工程效能,我们渴望有这样一把好用的尺子。然而,度量确实在许多研发团队的实践中是一个复杂的问题。我们见过许多团队从使用 Excel 去归集各处的报表,到搭建基于 SQL 查询或更复杂的数据仓库的基础设施。度量涉及到数据源的规整和清洗,涉及到指标的选取和基线的设定,涉及到对指标的有效解读和改进措施的判断。
CODING 利用一站式平台的数据集成优势,给注重效能改进的研发团队带来了可对全平台产生的数据进行多维度分析的研发度量工具。它的特征是开箱即用、高度可视化、自带效能指标体系模型,促进 DevOps 工程透明化。
研发度量覆盖从需求、代码、制品到发布的全链路数据源,可以自由组织个人视图和团队视图,度量视图带有健全的权限管理机制。使用度量查询器,团队负责人、PMO 可以定制复杂的可视化报表,数据可以下钻,可以导出,也可以共享投屏。研发团队其实没有必要去进行过度的指标设计,通过少数指标(一般不超过 20 个)基本能覆盖团队和项目主要维度的统计,更重要的是抓住关键指标的有效改进措施。
基于 DevOps 成熟度模型,这里我们选取了一些参考性指标和基线。例如需求交付周期、缺陷修复时长、自动化测试率等等。以往可能覆盖这些关键指标有相当多的工序要配置,尤其是对于中大型组织,覆盖较多团队、较多项目,甚至交叉团队、交叉项目的情景。
CODING 研发度量将预设基于成熟度模型的效能视图和质量视图,视图内有预定义好的指标设计,通过一键开启这项功能可以便捷的应用到你的团队当中,无需进行复杂的配置即可直接使用。随着使用深度增加,研发团队可以自定义适合自己的公式化指标。
最后我为大家带来的是工作负载,这是 CODING 提供的一项全新的人力资源管理工具。这款工具定义了一个工作饱和度的指标,能以直观、可视化的方式度量一组研发人员工作并行的的情况。尤其适用于计划驱动型团队的需求排版,识别闲置开发资源和过度饱和的开发资源。这款工具现在已经上线,可以在 CODING 线上版本中直接体验和使用。
以上就是我今天为大家带来的内容。如下图所示,感谢过去一年这些团队与我们共创产品。CODING 希望通过打造一站式研发平台,让人们相信数字化软件工厂是可以实现的。我邀请您加入,和其他团队一道,迈入高效能研发的数字化工作体验。
点击观看 CIF 峰会回放