相比传统的应用研发流程，以微服务架构为基础的研发团队更需要和依赖整体流程的敏捷属性。为了帮助更多将要或者正在以微服务为架构的项目，了解和解决诸多敏捷开发流程中的问题，特邀腾讯微服务平台（后简称TSF）产品研发团队部分核心成员，对TSF自身如何落地敏捷开发做相关介绍，并经由笔者整理和输出，希望能对以微服务架构构建的项目起到一定参考作用。
崔凯
腾讯云 CSIG 微服务产品中心产品架构师
多年分布式、高并发电子商务系统的研发、系统架构设计经验，擅长主流微服务架构技术平台的落地和实施
目前专注于微服务架构相关中间件的研究推广和最佳实践的沉淀，致力于帮助企业完成数字化转型
腾讯微服务平台（Tencent Service Framework，TSF）是一个围绕着应用和微服务的 PaaS 技术平台，提供应用全生命周期管理、数据化运营、立体化监控和服务治理等功能。TSF 拥抱 Spring Cloud、Service Mesh 微服务框架，帮助企业客户解决传统集中式架构转型的困难，打造大规模高可用的分布式系统架构，实现业务、产品的快速落地。TSF 以腾讯云中间件团队多款成熟的分布式产品为核心基础组件，提供秒级推送的分布式配置服务、链路追踪等高可用稳定性组件。此外，TSF 与腾讯云 API 网关和消息队列打通，让企业轻松构建大型分布式系统。
在 TSF 的微服务架构体系中，服务总数并不多，大概40+左右，就数量而言 TSF 本身的架构规模属于偏中小型的微服务架构。这是因为，TSF 产品本质上是一整套业务支撑技术平台，其微服务架构表面看显得十分精巧，相比大型系统架构为了应对高并发、海量存储等因素而产生的架构复杂性，TSF 架构设计的权衡与内涵思考则主要体现在产品的稳定、内聚、高可用等方面。
从组件分布上看，TSF 整体功能主要分布在管控平台、注册中心、分布式任务调度平台、分布式事务平台、Mesh 平台等各个子平台中，每个子平台又包含若干个数量不等的服务。
TSF 本质上的产品属性——业务支撑端平台，决定了它属于一个相对典型的轻量级微服务架构，其敏捷开发落地实践经验对于中小型微服务架构项目具有独特的参考意义，可以从不同侧面帮助研发团队快速切换到微服务架构下的敏捷开发流程中。下文将以整体研发流程的视角，从项目、需求、研发、测试、构建、文档等各个方面向读者做简要的分享。
腾讯内部经过多年的沉淀，已经积累了丰富的敏捷研发实践经验和敏捷模型工具，TSF 的迭代周期和节奏跟随着腾讯内部研发大环境的发展也逐步稳定。整个项目的管理流程基本趋向于流程化、标准化，几乎不存在明显的阻塞点，下面将从项目管理中 TSF 相较其它产品不同的几个点进行阐述。
目前 TSF团队 的研发流程基本符合腾讯研发体系一直在实践的敏捷开发理念（如下图），并且产品整体秉持前沿、开源、创新的技术风格，一般会先在公有云上进行内测、公测来磨合产品，将最新的前沿技术普惠到国内企业和用户，在用户积极不断的帮助产品进行功能上的迭代之后，产品会继续通过多种渠道、方式进行“私有化”，使得本身继续在定制环境的兼容性、易用性上不断完善，为腾讯持续输出最大化商业价值。
从工具角度讲，可以看到整个项目管理过程以 TAPD 为中心，通过工蜂进行源代码管理，通过蓝盾进行编译、构建、打包，通过 WeTest 进行测试用例、缺陷跟踪、自动化等管理，通过蓝鲸进行发布部署及运维管理。从团队角色上讲，TSF 研发团队主要由以下几种角色构成，每个角色都有各自的主要职责，但遇到突发情况或一些责任边界模糊的地带，团队内部主要通过鼓励人员的自主能动性来解决。
由于 TSF 作为微服务技术平台，主要服务于企业用户，B端客户（尤其是大客户）的需求提出到实现所预留的时间一般非常短，这就需要项目经理介入进行资源、排期等方面的协调，尤其是在进度管理方面扮演重要的角色。比如，根据功能优先级、客户重要程度、研发及测试资源等等情况进行统筹安排，同时能否保质保量交付客户，不仅仅是项目经理一个人的事情，是需要研发、测试、产品、交付等多方共同思考和努力才能完成的。
比如，与国有大行的一次重要需求对接过程中，从方案设计定稿到交付客户原本至少需要4个月的正常周期，但由于客户自身技术平台改造及业务应用的上线 deadline 迫在眉睫，需求讨论、研发设计、功能测试、交付部署等方面的时间被严重压缩到2个月左右。由于项目经理前期及时的介入和持续跟进、协调，最终使得这次需求迭代可以赶在客户技术平台改造之前完成交付部署，赢得了客户信任的同时，也保证了团队内部没有因为这次紧急的需求而打乱未来的版本开发计划。
需求管理是研发流程中非常重要的一环，TSF 的需求管理主要包括需求汇总、需求分析、需求变更。在整个需求管理的过程中，TSF 团队成员会持续思考当前需求究竟解决了客户的什么根本问题，如此是否解除了用户痛点，这般又是否超出用户预期，以此为本质核心，持续不断的推动产品以满足用户本质需求为目标迭代进化。
TSF 产品需求的来源主要包含：产品经理对友商的对标产品(尤其是重要特性）的分析、开源技术能力或趋势的跟踪、架构师反馈的客户声音，还包括一些内部反馈，比如测试人员提出的体验问题、研发提出的非功能性需求、关联产品（如容器服务、虚拟机）的兼容性或打通需求等等。针对以上需求来源，产品经理们会通过建设、维护需求池，对自身负责的功能模块进行需求的汇总、分类和拆解。
每种需求来源都有各自不同的价值点，都是为了解决一类具备共性的问题，比如重要特性往往会成为大客户投标过程中评价各厂商产品的主要竞争点，未来市场上的技术趋势关乎产品未来的发展方向，架构师深耕客户所挖掘出的需求点也丰富了产品的使用场景。
在完成需求汇总后，TSF 的产品经理会针对每个需求进行深入分析，并与开发人员进行多轮沟通。需求沟通的主要内容包括，需求的可行性、通用性、大致的实现逻辑、任务的优先级等。TSF 在需求分析阶段，会更注重产品功能是否更符合 Paas 技术平台的定位，即以中间件技术平台的方式帮助用户更好更快的完成业务应用的搭建，比如是否影响到产品本身的可扩展性、可用性和多租户等方面。
其中，开发人员在可行性方面除了完成最基本的功能实现外，还会从当前架构体系角度对稳定性、兼容性等方面进行考量，如新功能的技术选型是否符合产品未来3-5年的发展方向、目前的技术实现方案是否是简洁的、对目前架构影响是否是最小的、对于客户正在使用的已有版本的兼容性保障方案是如何等等。
另外，需求的通用性也是中间件产品需求分析中一个比较重要的考量因素，一般情况通用性较强的需求相比定制化偏重的需求，对于广大用户来讲，能够产生更多的产品价值，在需求的优先级排序上也会更侧重通用性较强的需求。
最后，不同大小的需求（大小指实现需求的整体成本）产品经理与研发人员的沟通形式也会略有区别。相对于比较小的特性优化，产品经理会直接跟对应的研发人员做沟通，然后确定规划该优化将添加在哪个版本。如果是比较大的特性更新，产品经理会拉通相关的人员，包括但不限于产品经理、研发人员、测试人员、项目经理、产品架构师等等，分多次讨论，每次讨论也可能会侧重不同主题，如技术实现方案、排期等。
《孟子》中有云：离娄之明、公输子之巧，不以规矩，不能成方圆。同样，即使团队的技术水平再高超，但若对需求变更疏于管理控制，那么它很可能会不知不觉的发展到难以收拾的地步。
在 TSF 的研发过程中，难免会遇到需求变更的场景，比如为了与客户业务上线日期同步被迫调整了需求优先级等等。需求变更的提出越早，对整个研发团队的沉没成本越小，对成员的积极性影响也越小。TSF 在需求变更方面虽然没有使用十分详尽的流程规范进行约束，但也是有底线的。首先，产品经理会仔细衡量变更波及的影响范围，然后与研发、测试等相关方预估变更产生的时间、人力成本，最后综合讨论各方面因素，根据成本收益判断是否值得变更，如果当前不变更是否有临时过渡方案等。
研发管理涉及方面众多，例如绩效管理、成本收益管理、团队建设、研发规范等等，本文由于篇幅所限，主要针对 TSF 团队实际开发过程、小团队的协同模式实践、内部管理心得及方法三方面进行介绍。
当产品经理与对应研发人员对某一需求达成方案上的共识后，研发人员便开始进行如下研发过程：概要设计-详细设计-代码编写-单元测试-本地自测-联调测试-提测邮件。
在 TSF 实际研发过程中，每个开发人员基本都具有比较宽的技术面和非常专精的点，所以在高技术素质团队的前提下，研发任务划分、模块责任边界等方面，并没有遵循传统研发流程那种非常严格的界定。每个人都有主要负责的功能模块，但人员方面也会存在一定的流动性。这种方式也体现了团队管理者人性化的团队文化思考，即鼓励找到自己擅长的、感兴趣的事，全方面的、长足的做人才发展培养。
由于 TSF 内部微服务成熟度高、开发人员技术技能较全面，所以一般情况下，单个需求涉及的研发人员不会超过3个，大部分情况下1-2个人就可以完成。同时每个版本的迭代都会“凝聚”多个开发人员的成果，从而形成一股团队的合力，使得每个迭代版本都能带给用户高质量的体验。精简的、高水平的技术团队，能有效减少沟通和管理协调成本，增加产出高水平产品的效率，这种团队管理理念和文化与苹果公司“乔帮主”（Steve Jobs）对创业团队的理念不谋而合——“我尽量保持一个简单的结构并雇佣聪明的人”。
另外，对于传统业务应用开发中经常被诟病效率低下的联调测试环节，TSF 由于内部微服务成熟度高、拆分相对合理，很少在联调测试时会严重耦合其它组件，导致开发人员无效等待或卷入多方进行沟通确认的情况。同时，开发人员会通过在联调环境 mock 外围接口的方式先保证自身组件质量，并且这一过程几乎是开发人员独立完成，较少出现跨组跨部门的资源协调。
最后，研发在完成本次版本的全部内容之后，会编写正式的提测邮件告知产品经理及测试经理，测试人员一般情况下在接收到提测邮件后才会开始测试。然后，开发人员会迅速投入到下一个需求任务的迭代中，通过这种“小步快跑”的方式完成一个个版本的开发任务。
不同的团队有不同的协同模式，TSF 研发团队内部的协同主要包括多地协同、内部角色间协同、兄弟产品间协同。
TSF 团队成员分布在不同的地域，包括北京、上海、深圳、杭州等。那么如何保证多地域研发人员之间能够顺畅的有效沟通呢？首先，团队成员都在本地时，一般会采用面对面的沟通方式，即使是新入职的异地员工，也有到深圳总部与团队成员熟悉一段时间的过渡机制。其次，日常沟通会采用多种方式、多种工具。如基于“腾讯会议”进行远程桌面、实时沟通，解决需要展示代码、文档等信息的场景；“企业微信”提供了正式办公环境中类似准实时的沟通方式和一系列相关工具，解决团队成员日常沟通的问题；“微信”作为目前国内最大的 IM 社交产品，解决非办公时间的紧急沟通或团队与外部人员交流的需求；此外，还包括通过传统的邮件完成审批流程、特殊情况下的电话沟通等。
由于 TSF 的研发团队分布在不同地域这一现实因素，所以团队内部角色间协同基本会遵循“互相信任”的大原则，时时刻刻保持创业团队的空杯心态，以有效提高团队整体运转效率为前提，激发团队内部成员的积极性和价值体现，避免一些不必要的流程、规范和假大空的形式主义。
TSF 作为 Paas 技术平台必须具备资源、组件的管理能力和各类环境的兼容能力，所以经常涉及与其它兄弟产品间的协同，如容器服务 TKE、虚拟机 CVM、Serverless、消息队列 TDMQ、专有云 TCE 等很多产品。团队 leader 及核心骨干在这一过程中起到重要作用，如技术框架性方案沟通、合作机会点挖掘、对外整体解决方案构思、对接思路及流程安排等等，提前避免反复沟通或沟通不清的问题。
代码质量方面，除了研发人员通过本地调试自测、单元测试等方式进行技术做保障，还会在代码提交时选择同组的研发人员互相 review 代码，这样即防止了“只缘身在此山中”所可能产生的错误，同时也是一个互相学习的过程。另外，开发人员在功能联调时，是大部分功能问题集中收敛的一个闸口，此处的成效好坏直接影响着后续的测试成本以及研发节奏。
需求评审阶段会有初评的 PRD（产品需求文档），不过开发人员一般会在需求评审完全结束之后，才会拿出设计完整的技术方案。需求评审期间，研发人员内部也会持续沟通讨论。一般情况下，如果需求内容没有根本性变动，整体技术方案的方向就不会有大的偏差，在需求评审后期，开发人员基本是在不断完善技术方案细节。
代码分支管理方面，目前 TSF 采用持续在一个分支上持续 release 不回合 master 的方式，这种分支管理方式的好处是，可以进行更快速的迭代、更频繁的生产发布、可以根据每个客户不同的版本基线出单独的 hotfix 版本进行解决，缺点是在项目变的越来越大时，回合代码成本比较高、研发资源处于串行结构。TSF 研发团队也在不断思考和优化，试图找到适合自己的分支管理方式。
软件测试是软件发布前最后也是最重要的一道检测屏障，其重要性在于使用测试管理体系进行系统的、不同于开发人员思维方式的检测软件是否如需求文档所述，是否具备了可以交付生产环境的条件。本文主要针对 TSF 的测试流程、用例管理、质量保证三方面进行介绍。
TSF 大致的测试流程分为：冒烟测试、功能测试、集成测试，以及自动化测试、相关兼容性及性能测试等。冒烟测试主要集中在本次需求及产品本身核心的功能上，如果发现冒烟测试不通过会发邮件进行团队周知及打回修改；功能测试主要会针对边界、新特性进行重点测试，之前提到的测试用例的编写也主要是针对本部分进行；系统测试主要检测本次修改是否影响了其它相关模块；自动化测试则针对人力成本较高、功能变动不频繁的场景尽可能的覆盖，如集群、部署组、命名空间等，同时与企业微信进行了消息联动（自动化测试机器人消息）；兼容性测试和性能测试会根据版本的重要性进行成本和方案评估后单独测试。
当PRD及技术方案基本确定后，测试人员已经开始设计测试用例，当研发发出提测邮件之前，测试人员已经基本就绪冒烟测试和核心功能测试。以便在研发完整提测之后，测试人员可以快速的进入测试用例执行环节，发现潜在BUG。
在需求评审、技术方案评审过程中，对应测试人员都需要参与，这便于在测试用例设计初期保证相对完整的用例覆盖度。用例在编写完之后，一般会经过研发人员、产品经理的共同评审，时间点一般会安排在研发正式提测前后，因为研发那时基本完成了功能的开发，时间比较充裕。另外，在测试用例执行过程中，测试人员也会由于遗漏或者需求变更而不断补充测试用例，或者将一些用户体验方面的问题反馈给产品经理。
TSF 的测试人员在功能测试任务分派时是相对固定的，即某个测试人员一般会一直负责某些功能模块的测试和用例编写，因为测试任务不同于开发任务，测试人员需要非常熟悉自身负责模块的基本原理和测试用例，对轻微的测试结果异常需要有高敏感度。
自动化测试方面，由于 TSF 的每个模块的大部分功能都是以接口的形式对外暴露的，所以在自动化测试方面有很大便利性。不过如上文提到，主要会针对某些长期比较稳定的接口做自动化，对于变更比较频繁、经常增加特性的模块，一般不会也不适合做自动化测试，那样会增加很多额外的成本。
在整个研发过程中，也会针对研发过程进行度量数据的收集和分析，比如研发人员的千行 BUG 率、冒烟通过率等等。通过这些研发过程的度量指标，进一步指导整个研发团队能更好的改进协作机制、提升自身代码质量，向效率更高的方式演化。
TSF 持续集成流程：本地代码 push 触发构建任务-发布平台拉取代码仓库的代码到构建机-通过单元测试、Sonar、自动化测试等进行静态检查——>经过编译环境打成物料包——>将物料包保存在制品库中——>拉取物料包到对应环境中完成部署。
本地开发人员使用 GIT 作为代码仓库，通过关联构建平台的钩子，当有代码 push 时自动完成构建任务。在开始构建前需要将代码拉取到构建环境中，通过平台工具进行静态检查，如 Sonar、checkstyle、findbugs 等。在编译时，maven 会自动执行代码中的单元测试代码，之后还可关联自动化测试任务。最后，开始执行代码编译，并将编译后产生的物料包保存在制品库中，同时推送物料包到指定的环境中完成部署。
TSF 的研发环境主要分本地开发环境、联调开发环境、功能测试环境、预发布环境、生产环境。其中生产发布过程采用了灰度发布的方式，先挑选国内的一个小城市（如重庆）进行试点发布，然后逐步过渡到小地域（如上海），最后完成大地域（如北京、广州）及全国的发布。极少数情况下发布出现意外的逻辑问题，开发人员会立即进行修改，由于数据结构相对稳定，重新发布应用基本可以解决绝大多数问题。另外，由于 TSF 的发布可能需要提前准备资源，所以发布时需要走内部的申请、审批流程。
最后，整个 TSF 的 CI/CD 过程中，同样以 TAPD 为中心，关联多种工具的使用，如通过 Gitlab、SVN 进行代码管理、通过蓝盾进行编译构建、通过 Sonar 进行代码检查、通过 nexus 进行包管理、通过 Junit、Jmeter 进行单元测试和自动化测试、通过蓝鲸作为发布平台进行部署。
上述章节主要介绍了 TSF 自身的敏捷开发实践内容，那对于企业而言应如何快速落地敏捷开发呢？这里 TSF 根据已有丰富的企业敏捷开发案例经验，提供三种不同场景的支持方案。
CODING 依托业界领先的敏捷项目管理理念与 DevOps 体系方法论，将优秀的理念与工具融入到产品中，打通了研发过程中的工具链孤岛及协作壁垒。在 CODING 平台中，可以实现需求的快速迭代、产品代码管理、自动化测试、持续集成、构建物管理、应用持续部署等一系列闭环的研发工作流，覆盖敏捷开发全生命周期，助力团队提升研发效能，全面拥抱行业内领先的IT理念与文化。
本文以 TSF 团队敏捷开发落地实践内容出发，简要的介绍了 TSF 产品自身敏捷开发的大致流程。通篇可以看出，敏捷开发落地实践没有最标准的流程，只有更适合的流程。目前 TSF 的研发流程也并不是最完美的，比如如何更好的关联物料包版本、物料包配置版本、SQL 语句版本之间等问题。TSF 团队将虚心接纳各位读者的意见和建议，并仍旧一如既往的保持创业心态持续探索，为客户提供更优质的产品和服务而努力。
[1] CODING：https://cloud.tencent.com/document/product/1115
[2] Navigating the Microservice DeathStar With DeployHub：https://dzone.com/articles/navigating-the-microservice-deathstar-with-deployh
[3] 腾讯重新定义敏捷：https://www.infoq.cn/article/30yc2kezfof8uy6a5hbz
[4] CI/CD是什么？如何理解持续集成、持续交付和持续部署：https://www.redhat.com/zh/topics/devops/what-is-ci-cd
扫描下方二维码关注本公众号，
了解更多微服务、消息队列的相关信息！
解锁超多鹅厂周边！
