做云原生时代标准化工具，实现高效云上研发工作流

本文为 CODING 研发总监 王振威，在腾讯云 CIF 工程效能峰会上所做的分享。

文末可前往峰会官网，观看回放并下载 PPT。

大家好，我是王振威，CODING 研发总监。非常高兴能在这里给大家分享过去一段时间 CODING 的产品思考和升级，并为大家介绍 CODING 战略升级后的重磅新品。

首先，我们来看一下 CODING 的全景产品矩阵。这里标识出了过去一年里， CODING 做出的重要产品更新，其中有大量产品是全新推出的，也对一些现存的产品进行了升级，这张图几乎囊括了 CODING 现存的所有重要产品模块和功能。我们聚焦于软件研发阶段的管理，从团队协同到项目计划，从代码协作到构建集成，从测试管理到制品管理和部署上线，在部署上线后就完整对接了云基础设施 IaaS 和 PaaS，这样就可以理解为，如果客户使用了 CODING 并且使用了云，就可以形成一套全链路的云原生体系。

在过去一年里，CODING 坚持以客户为中心，朝着让开发更简单的方向，面向云原生的未来产业大规模增强了既有的产品，并打造了一些非常激动人心的新品。我将在接下来重点介绍一些其中的新品和重要的产品升级。

项目协同 2.0 —— 有条不紊

我们都希望所有的事情进展，都是按照有序的节奏来进行。那么我们知道，软件开发工作是高度复杂的，这需要各种不同类型的专业人员的协同，例如：产品经理、后端工程师、测试工程师、前端工程师、敏捷教练、UI 设计师等等，不同的公司也有不同的角色设置。但如果仅仅只是简单地把这些人员凑在一起，缺乏一套确定的工作交流机制，我想他们的协作将陷入一团乱麻。

CODING 面向开发者团队提供的项目协同，一直都是我们产品的重中之重，项目协同产品团队刚刚完成了产品的 2.0 重大升级，希望让协作有条不紊。这里我将简要介绍几个项目协同 2.0 的重要特性。

第一是新增自定义协作模式。我们都知道，项目管理软件铺天盖地，可能有非常多的选择，但传统的项目管理软件往往都是基于某一种特定的管理理论，比方说敏捷或是瀑布，针对某一种具体场景来深入设计。事实上这种设计方式明显缺乏灵活性，对于大多数企业而言，企业内部的事项往往无法被精准的归类为「需求」、「任务」或者「缺陷」。

例如对于一个金融企业来说，他可能需要管理「风险」这一概念；而对于初创企业来说，新的产品还没有完备的产品需求，他可能需要一个概念叫做「构想」或者「脑洞」；对于一个软件企业来说，可能专门有一类任务叫做「交付」或者「实施」。那么你可以看到，事实上不同的企业没有办法使用传统的项目管理软件里的概念，来表达自己的业务模型。

不论是「风险」、「构想」还是「交付」，项目协同 2.0 都可以非常灵活的应对，使用自定义协作模式不仅可以跳出敏捷和瀑布协作模型的限制，更可以自由依据企业的实际业务来具象化工作项的概念。风险这样的自定义概念不仅可以设置文本、数字、单选框等常规属性类型，项目协同 2.0 还支持非常多的内部信息关联。例如你可以设置一个脑洞的提出人为项目成员中的一个成员，甚至可以设置一个脑洞的预计实现周期为哪几个迭代。这些自定义的概念和自定义的属性，再配合自定义的流程，一套专属于企业自己的项目协作流程就完整建立起来了。

其中事项的状态也可以进行自定义，比如企业可以根据自身的情况，为不同类型的工作项设置如产品评审阶段、设计评审阶段、架构评审阶段、开发中、已测试、待上线、已发布等任何状态。如果新定义一个概念为「风险」，那么可以为「风险」设置：已发现、已识别、评估中、处理中、已消除等等不同的状态。并且这些概念在不同状态间转移时，我们可以定义其转移规则，设置只有某类成员可转换某个状态，例如只有测试人员可以把「开发中」的任务转移到「已测试」状态，这给企业事项流转流程带来了非常大的灵活性和便利性。

第二个是项目协同 2.0 带来的全新的项目集功能。项目集是用于管理在项目层级之外的跨项目事项进展。如图所示，项目集里的需求可以分解到不同团队的不同项目里，并可以在项目集视图进行集中管理和追踪。

下图是一幅经典的项目集页面信息，可以清楚的看到与项目不同，项目集有明确的时间期限，会设置若干个里程碑，整个项目集的里程进度在这里一目了然。此项目集里的任务在不同项目里的进度也记录的非常清楚。从项目集的推动者角度来看，如此透明的信息和明确的时间进度规划，可以高效推进跨团队的协作，