以终为始，依托度量指标，多种工具全面提升研发效能

1 引言

高效能是企业取得成功的关键要素之一，通过提升团队的效能，可以实现更高质量的工作成果、更快速的产品交付和更好的客户满意度。然而，在追求效能提升的过程中常常面临以下痛点：

• 缺乏明确的效能衡量指标：缺少科学有效的效能衡量指标，难以准确评估团队的工作效果和进展。
• 无法准确衡量团队产能：传统的产能衡量方法难以全面准确地反映团队的工作量和完成情况，需要更具体的指标来细化产能的测量。
• 置信度不足：数据质量和可信度的问题会影响对团队效能的评估，导致决策的不确定性和风险。
• 忽视团队健康度：仅关注工作产出而忽视团队的健康状况，容易造成长期发展和创新能力的损失。

基于以上问题，我们构建了效能三角指标体系，其中包括产能、置信和健康三个关键指标。产能指标是核心指标之一，用于衡量团队在特定时间内完成任务的能力。为了更加准确地衡量产能，我们引入了二级指标，如需求交付周期、代码量等，来侧面辅助产能指标的测量。同时，我们设计了置信和健康指标，从团队操作的合规性和团队的健康状况两个方面出发，提供了更全面的团队效能评估。通过这一指标体系的应用，我们能够更全面、准确地评估团队的效能，并针对问题制定相应的改进措施，提升团队的工作效率和结果质量。

2 效能体系

效能体系，描述的是通过以SOP实践，效能度量以及工具链共同构成的一个高效的研发生态系统，该体系有助于推动创新并实现效能提升。

2.1 CSI

CSI包括需求方和使用方，重点阐述以结果为导向来指导产研过程中合作流程。

2.2 工具链

工具链是研发过程中使用的软件以及创新工具的集合，包括AI编程、平台工具、版本控制系统、自动化测试工具等等。一个强大的工具链可以显著提高研发效能，简化工作流程，减少错误和重复工作。

3 效能平台上的创新建设

3.1 建设统一的协作效能平台

3.1.1 一些重要的概念

3.1.1.1 项目

以业务、产品或系统建立项目组，在项目内管理业务、产品或系统的需求池，并在项目内管理推进整体产研排期及开发流

3.1.1.2 迭代

如果团队是“班车制”推进项目迭代开发，就可以用“迭代”模块来分组管理每次“班车”上线的需求；（即：“迭代”就是“需求”的分批分组管理）

3.1.1.3 需求和任务

“需求”指的就是“功能点/故事点”，从“需求”拆解到每个人身上的“工作”就是“任务”；

3.1.1.4 需求的拆解及排期

“需求”要推进到开发，就需要拆解到每个人身上的“任务”，比如：
前端同学拆解一个“前端开发任务”，
服务端同学拆解一个“服务端开发任务”，
测试同学拆解一个“测试任务”，
任务拆解完成后，各端同学就可以进行各自任务的“工时评估”和“排期”并更新到系统，然后根据各端“任务”的排期情况，就能得出这个“需求”的整体排期情况；

3.1.1.5 需求的推进

“需求”拆解任务并排期完成后，就可以按期进入开发，此时需求负责人或开发负责人需要将需求状态变更为“开发中”；
开发完成后，开发同学将自己的开发任务更新状态为“已完成”，并将“需求”状态更新为“待测试”，这样测试同学就会收到通知消息，并开始测试；
测试完成后，测试同学将自己的测试任务更新状态为“已完成”，并将“需求”状态更新为“待产品验收”，这样产品同学就可以收到通知，并开始产品验收；
产品验收完成后，再将“需求”状态更新为“待上线”，这样开发同学和测试同学都会收到通知，然后开发同学就可以按计划进行上线操作；
开发上线发布完成后，开发同学再将“需求”设置为“已上线”，这时候测试同学和产品同学都可以收到上线通知消息；然后产品和测试同学就可以进行线上回归和验收；
本次迭代所有需求都上线完成后，需求管理同学（产品/项目管理或研发负责人）就可以对当前迭代进行“完成迭代”操作。

3.1.2 高效便捷的需求规划和派发

产品、技术负责人根据需求优先级，将项目需求池中的需求规划至对应迭代，在迭代计划会议上与团队共同进行需求评审。对当前迭代要完成的需求进行产品方案评审后，研发、测试人员利用任务将需求进行拆分，方便后续处理和跟踪。

3.1.3 把控迭代进度，及时识别风险

迭代过程中，团队成员围绕迭代要完成的需求完成自己拆解的任务，并通过项目计划管理任务状态；在每周对齐会议中，可以借助项目计划可视化的方式对齐迭代进度，与风险，排除问题。

4 提效工具

4.1 IDE插件AutoCode

在大语言模型推出后，市场上衍生出了大量的AI编程IDE插件，在调研了Github Copilot、Codearts、Comate、CodeGeeX等市场主流IDE编程插件后，结合之家实际业务场景，云平台上线了之家专属IDE编程插件AutoCode，支持VSCode、JetBrains IDEs、Android Studio，将有效帮助大家解决开发过程中遇到的问题，显著提升开发效率。
AutoCode功能清单：

• Code问问- 在IDE窗口中与大语言模型针对代码相关问题进行问答
• 代码自动生成-根据自然语言描述的功能自动生成代码
• 代码重构--对所选代码进行重构
• 代码优化-对所选代进行优化
• 代码解释-解释所选代码，帮助更快更好的理解
• 代码翻译-对当前代码进行语义级翻译，支持多种编程语言互译
• 添加注释-给代码自动添加行级注释
• 快速插入-大模型的输出直接点击快速插入到代码框对应的光标处

4.2 需求澄清助手

在对大型模型在测试领域的应用，尤其是测试用例生成方向的实践探索中，我们通过对约70个实际业务需求的实践进行了评估和分析。我们重点关注了用例生成方向的应用效果、多提词模式的调优以及多维因素的效果差异。通过基于实际数据的研究，我们对生成用例中存在的问题以及这些实践的共性特点进行了分析，同时提出了一些可优化的建议。

• 问题归纳分析

  • 效果随机/深度不够/无实例化

    • 提词限制过少--》丰富的提词可以提高用例效果下限
    • 需求歧义
    • 需要业务背景上下文
    • 对用例质量未做要求

  • 用例输出冗余/覆盖不够

    • 需求粒度vs要求用例数不平衡
    • 多逻辑间有交叉，需求中未显示说明
  • 用例思路与习惯不符

  • 用例错误

    • 需求歧义
    • 多逻辑有交叉

  • 用例格式

    • 对用例格式未严格要求

• 优化方向：

  • 提词优化

    • LLM多步提词，增加用例设计方法及示例等， 完善背景知识库。

  • 需求质量提升
    功能测试用例的目的在于打通产品设计和研发阶段，做好需求澄清，减少需求损耗和需求预期偏移，并通过测试左移前置发现和解决质量问题，减少后续暴露缺陷所带来的成本激增。所以提升GPT生成用例的效果，应从需求产出、需求澄清、用例生成，3个阶段配合实现，通过在前置阶段应用GPT，使得输入到用例生成阶段的需求物料质量得到提升，配合完成功能用例在整个研发过程中目的。
    通过以上现阶段的分析，我们基于大模型结合需求澄清和功能用例生成的场景，拆解了如下步骤：
    
    并通过集成测试行业知识库业务背景、多轮会话的引入，等手段，经实测通过AI需求链路优化过的需求歧义明显降低，用例生产的可用性及深度基本可以达到商业产品的效果。对需求澄清、测试用例生成带来效率提升。
    

    4.3 产研AI合伙人

    问题与挑战
    生成式AI由于上下文信息不足、无法理解或捕捉到复杂的语言结构和逻辑、知识缺失等原因，可能会导致生成式AI在生成过程中出现偏差或错误，生成的结果与预期可能存在一定的差异。为了减少这种差异，在实践过程中需要解决几个核心问题：
    意图精确输出：明确告知模型所需关注的特定方面或要求，以便减少模型输出的偏差和不稳定性。
    复杂问题处理：由于模型对话长度有限制，为了克服这种限制，我们将较复杂的任务分解成多个子任务，充分利用模型的能力来处理各个子任务，提高了任务处理的质量和效率。同时拆解的任务可以实现并行处理，从而优化了资源分配和任务执行计划。
    领域知识补充：通过补充产品文档内容和领域专业知识，AI可以更好地理解复杂的业务规则和业务需求，从而提高生成内容的准确度。
    系统及MVP构建
    通过以产品文档为核心、测试用例为基础，并结合AI的辅助，我们能够更快速地完成需求的理解和测试用例的生成等研发工作，确保开发过程中的一致性和准确性。这样可以大大提高研发过程的效率和质量，进一步推动产品的成功交付。在二手车技术部，已经基本完成AI伴随初版MVP构建。
    
    产品知识查询：通过产品知识整合并向量化存储，结合LLM帮助用户回答有关产品的问题。
    需求质量评估：根据已有的需求文档，分析评估其质量，并给出反馈和改进建议。
    需求内容完善：基于现有需求文档，生成式AI可以生成补充信息，完善和细化需求内容。
    测试用例生成：根据给定的需求文档和规范，自动生成一系列测试用例，覆盖各种可能情况，提高测试效率和用例覆盖度。
    测试脚本生成：自动根据测试用例和测试框架要求，生成相应的测试脚本，减少手动编写测试脚本的工作量。
    单测代码生成：根据需求和规范，自动生成针对单个模块或函数的测试代码，验证其正确性和稳定性。
    开发代码生成：基于需求规范和设计要求，生成式AI可以自动生成部分开发代码，加快开发速度，减少重复工作。
    需求文档管理：提供需求文档的存储、搜索和版本控制功能，方便用户管理和跟踪需求变更。
    测试用例管理：提供测试用例的归档、分类和检索功能，帮助用户组织和管理测试用例，提高测试效率。
    Prompt库管理：提供一个Prompt库，方便用户在需要时快速找到并选择合适的Prompt，以引导生成式AI生成期望的输出结果。
    测试用例智能生成实践
    通过需求文档生成测试用例用AI得到预期优质的结果，Prompt 不断的调优至关重要，整个过程根据Prompt设置会经历几轮甚至几十轮对话，以下是主要流程
    
    测试用例生成流程
    领域知识库： 为了让AI能够更准确地解决问题，需要将一些AI不具备的知识提供给它，保障生成用例的准确性和完整度提供数据支持。知识库所涉及的主要内容包括公司业务和技术领域的知识：

    • 业务名词：为了更精准召回业务知识信息，我们针对不同业务线提取业务名词解释形成知识库，这些名词解释库包含了业务专有名词和行业术语的解释，帮助AI更好地理解和处理相关问题。
    • 业务领域：为了解决不同业务类型文档中涉及的业务领域多样性问题，针对每个业务线创建了独立的知识库，如C1、C2、数科、大客、车小妹等。这些知识库提供了特定业务领域的相关知识。通过构建业务领域知识库来弥补AI缺失的信息。
    • 技术领域：针对不同的专业知识制定了一些标准规范，包括生成用例边界值的设定和性能测试用例的标准，这些规范和知识输出旨在提高AI生成的方式和方法，促进结果准确性提升。

任务处理： 对于用例生成这种复杂的任务由于AI的特性，生成用例的完整度和准确性较差。针对问题，我们将用例生成过程进行任务拆分：
首先在处理不同业务需求时，第一步是确定文档的类型，以便获取相关角色和场景信息。通过确定文档类型，我们可以获得特定业务领域的专有名词解释知识库序列。这样，我们能够更准确地帮助AI理解业务问题，并提高生成用例的可用性。
在用例生成的过程中，我们需要考虑多个角度的问题。除了已有文档中覆盖的知识点外，我们还需要提供多个知识库给AI，以提高用例生成的完整性和可用性。为了实现这一目标，我们将用例生成过程拆解成三个任务：功能用例、边界用例和性能用例。功能用例可能涉及到一些隐含的业务知识。为了辅助生成功能用例，我们会获取业务基础知识库，并结合预设的Prompt来生成新的功能测试评估prompt，调用LLM进行评估，并输出结果。
边界用例和性能用例的处理方式类似，但是所需的技术领域知识不同。边界用例需要优先获取边界值用例的技术知识库，而性能用例则需要优先获取性能技术知识库作为基础知识。通过这样的任务拆分和综合利用不同的知识库，我们可以更精确定义生成用例标准，提高其完整性和可用性。
汇总结果： 经过复杂任务的拆分处理，我们将各个子任务的用例结果存储在内存中。然后，对各个任务的结果进行整合、归类和排重的处理。最终，我们将用例结果进行结构化存储。
依靠领域知识库结合任务拆解，我们将大文档分割成小文档，并针对不同的文档类型和用例类型进行多维度的业务知识和技术知识填充。通过这种方式，最大限度地提升了用例生成的准确性和完整度。

4.4 质效流水线

流水线，即产品发布流程的名词化。根据业务定义的顺序关系，流水线的执行可以定义为依次执行相应的加工或质量校验行为。目前，软件交付全生命周期随着业务的发展不断完善。敏捷概念的提出和应用，大幅提升了软件开发的效率和版本更新的速度，但是它的效果仅限于研发环节，产品发布流程陆续出现新的瓶颈。

之家流水线发展历程与规划
CT（Continuous Test）即持续测试，紧密结合持续集成（CI）的流程，通过自动化测试快速、准确地执行测试用例，及时发现代码质量问题，提升测试效率和软件质量，使得 QA 人员能够将精力集中于优化自动化测试用例和场景。
在此基础上，流水线不再明显区分测试流水线与研发流水线，而是将各种类型的测试融入主线流水线的各个环节。这样一来，研发人员无需等待 QA 的反馈，可以及时从自动化测试中获取问题信息并进行调整。为了迅速丰富和完善自动化测试类别，平台利用公司内部众多测试平台的资源，整合了其测试功能。迄今为止，已接入的测试类别包括单元测试、静态代码扫描、接口测试、PC/M前端拨测、APP H5性能测试、压力测试以及覆盖率测试等。
基于这些丰富的测试类别，平台将各项测试嵌入流水线的不同环节，自动地并实时地检测每个环节的质量情况。例如，在代码提交阶段进行单元测试和代码扫描，在测试部署阶段进行接口测试、性能测试和覆盖率测试等。通过即时反馈测试结果，并根据质量检查标准设定门禁，我们可以有效地控制流水线的进程，严格把控服务质量。