V8程序

Appearance

研发流程管理办法 V1.0 ​

管理办法说明及用途 ​

一、名词释义 ​

1.1 角色 ​

  • 用户：协助体验测试产品的内部用户和真实使用系统的用户群体。
  • 客户：与公司合作的外部客户，如 XX。
  • 项目经理：负责规划、组织、推动项目落地的人员。
  • 运营团队：负责产品运营推广、市场营销、用户数据分析和客户服务。
  • 产品团队：负责需求转化、产品需求计划、管理产品需求迭代进程。
  • 技术团队：负责开发、测试、维护公司产品，设计公司技术架构，保证系统可伸缩性、安全性和可靠性，负责公司技术基础设施运维和支持。

1.2 研发过程 ​

  • 项目：经过立项的系统工程，如 XX 等。
  • 需求池：包含具体项目中所有未完成的需求，来源包括客户、用户、团队内部策划等。
  • 发布计划：对需求完成时间进行计划制定，并公示时间。
  • 发布评审：对即将发布的上线计划发起流程审批，各岗位干系人确认各节点工作是否完成并同意上线。
  • 故事：一种简短、明确的需求描述方式，可实现的、自包含的、有价值的用户需求或功能。
  • 迭代：将软件开发过程划分为若干个短小的时间周期，以便更快地交付产品和获取用户反馈。
  • 任务：需要完成的具体工作，包括编写代码、测试、设计、文档撰写等。
  • 缺陷：软件系统中的错误或缺陷，包括代码错误、设计问题、功能缺失、性能问题等。
  • 发布：发布指将已完成开发、测试、审批，并获得发布同意的版本进行上线操作。

二、产品研发过程 ​

2.1）计划内迭代 ​

2.1.1）合作流程 ​

计划内迭代的合作流程主要包括以下 5 个步骤：

  1. 用户向项目经理提出诉求：用户根据自身需求，向项目经理提出具体的诉求，包括功能需求、性能改进、缺陷修复等。
  2. 项目经理将用户诉求拆解至需求池中：项目经理根据用户诉求进行分析，将其拆解为具体的需求，添加至需求池中。
  3. 项目经理组织相关干系人员进行项目发布计划制定：项目经理需按固定时间组织产品和技术团队将需求池内的需求规划到未来发布时间内，并确定版本范围及需求实现程度。
    • a. 项目经理：确保项目至少有两个及以上的版本发布计划，以便产品和技术团队能够制定持续性的部门工作计划。
    • b. 产品团队：结合发布计划，合理安排后续的原型设计、原型评审时间。需在下一个版本发布的前一周完成针对技术团队的需求评审。
    • c. 技术团队：根据产品需求，拆解具体工作任务，并确保按照发布计划的节点准时完成各项工作。
  4. 产品团队确定产品需求输出时间：产品团队根据评审结果，确定各个需求的产品设计、原型制作等输出时间，确保各阶段的工作按时完成。
  5. 技术团队确认需求实现时间：技术团队根据产品团队的输出，评估需求的实现难度和时间，确保按计划进行开发和测试工作。

An image

2.1.2）研发过程 ​

计划内迭代的研发过程包括以下 6 个步骤：

  1. 产品团队组织需求评审：产品团队就需求池中的需求与技术团队和其他相关人员进行评审，确保需求明确、可行，并对需求进行优先级排序。
  2. 技术团队（开发人员）根据需求拆分迭代及任务：技术团队的开发人员根据需求评审结果，将需求拆分为迭代和任务，并分配给相应的开发人员。
  3. 技术团队（测试人员）同步完成测试计划创建和测试用例编写：测试人员根据需求和迭代计划，创建测试计划并编写测试用例，确保产品质量得到有效控制。
  4. 技术团队（开发人员）完成研发任务，更新需求状态，交付技术团队（测试人员）：开发人员在完成研发任务后，需更新需求状态，并将成果交付给测试人员进行测试。
  5. 技术团队（测试人员）开始需求测试，技术团队（开发人员）完成相关问题修复：测试人员对交付的成果进行测试，如发现问题，需将问题反馈给开发人员进行修复。
  6. 技术团队（测试人员）完成测试，更新需求状态，输出测试报告，转 UAT 测试：测试人员在完成测试后，需更新需求状态并输出测试报告。如果测试通过，需求将进入用户验收测试（UAT）阶段。

通过 TAPD 平台实现可视研发过程，确保计划内迭代的需求得到高质量的实现，同时保证团队之间的协作和沟通。

An image

2.1.3）交付过程 ​

计划内迭代的交付过程包括以下 6 个步骤：

  1. 技术团队（测试人员）完成需求测试，更新 UAT 环境：测试人员在完成需求测试后，将更新后的版本部署到 UAT 环境，以便进行用户验收测试。
  2. 产品团队&项目经理完成 UAT 测试：产品团队和项目经理对 UAT 环境中的产品进行验收测试，以确保需求得到满足。
  3. 项目经理创建发布评审：项目经理在 UAT 测试通过后，发起发布评审流程，邀请相关干系人参与评审。
  4. 产品团队、技术团队审批通过，项目经理进行确认签发：发布评审中，产品团队和技术团队需审批通过。审批通过后，项目经理进行确认签发，表示同意产品发布。
  5. 技术团队（运维人员）收到发布评审通过通知，按照规定时间，进行生产环境发布：运维人员收到发布评审通过的通知后，按照约定的时间窗口，将更新后的版本部署到生产环境。
  6. 用户（需求提出人）进行生产环境验收：最终用户（需求提出人）在生产环境中对产品进行验收，确保需求得到满足。

通过 TAPD 平台实现交付过程，确保计划内迭代的需求得到有效实现，并确保相关节点责任人知情审批，保证产品在生产环境中的稳定运行。

An image

2.2）非计划性迭代 ​

非计划性迭代主要针对紧急情况，例如系统缺陷（bug）或产品设计缺陷导致的严重操作问题。此类迭代需要立即解决并发布上线。

在非计划性迭代中，应遵循以下操作路径和流程：

  1. 项目经理对情况进行确认，确定启动非计划性迭代响应：项目经理在接到紧急问题后需对情况进行分析和评估，确认是否需要立即启动非计划性迭代响应。
  2. 参照 TAPD 非计划性迭代操作流程：在 TAPD 平台上执行非计划性迭代的操作流程，包括创建紧急任务、开发、测试、发布等步骤。
  3. 完整记录非计划性迭代产生的原因：当遇到需要立即解决的问题时，项目经理需详细记录问题产生的原因，以便日后分析。
  4. 项目经理组织项目干系人进行复盘分析：在问题得到解决后，项目经理组织相关干系人对问题进行复盘分析，找出问题产生的原因。
  5. 形成结论和改进措施：通过复盘分析，形成关于问题产生原因的结论，并制定相应的改进措施，以防止类似问题的再次发生。

通过以上操作路径和流程，确保非计划性迭代能够快速响应问题，及时修复并发布上线。同时，对问题进行复盘分析，从中吸取经验教训，提高产品质量和团队协作效率。

三、产品研发流程图 ​

An image

四、基于 TAPD 的操作 ​

4.1 需求（backlog）（职责：项目经理/产品团队） ​

产品需求： 项目经理与产品团队成员根据收集的用户/客户需求所属的功能模块，录入对应模块的需求池中。在录入需求时，需清晰描述需求内容。

技术需求： 项目研发过程中可能需要进行的技术架构升级、性能优化等技术债务由项目经理与技术团队成员根据需求所属的功能模块，录入对应模块的需求 池中。

4.2 发布计划（职责：项目经理） ​

发布时间点： 周二 或 周四：晚上 19：00。

项目经理需按固定时间组织产品和技术团队将需求池内的需求规划到未来发布时间内，并确定版本范围及需求实现程度。以下为各团队的职责：

  1. 项目经理： 确保项目至少有两个及以上的版本发布计划，以便产品和技术团队能够制定持续性的部门工作计划。
  2. 产品团队： 结合发布计划，合理安排后续的原型设计、原型评审时间。需在下一个版本发布的前一周完成针对技术团队的需求评审。
  3. 技术团队： 根据产品需求，拆解具体工作任务，并确保按照发布计划的节点准时完成各项工作。

通过明确各团队的职责及发布计划，项目经理可以确保项目按计划进行，提高团队协作效率，最终实现高质量的项目交付。同时，设定固定的发布节点有助于提高 团队的工作效率和项目管理的可预测性。

若正在进行中的需求发生变更，项目经理应及时组织产品团队、技术团队进行变更影响范围评估：

  • a）若评估结果不影响当前发布计划进度，则接受该需求变更。
  • b）若该需求变更经评估后影响到当前发布计划时间，则在实现程度和将该需求移动到下个发布计划之间进行平衡取舍。

4.3 创建迭代（职责：技术团队） ​

迭代由开发人员构建。一个发布计划可以创建多个迭代。进入对应迭代详情，将本次开发的需求规划到当前迭代中。关联对应的需求即可将需求关联到对应的迭代。根据 需求拆解 task。

将 story 规划到对应迭代中。左边为已在当前迭代规划中，右边为尚未规划到迭代中，点击规划到迭代，即可关联到当前迭代。

4.4 测试计划（职责：技术团队） ​

测试人员根据开发提测时间和开发结束时间，评估本次版本发布的测试计划。测试计划应体现：测试类型/测试的起止时间/测试负责人/所属迭代/当前测试计划状态（开启 or 关闭）。测试计划中关联对应的 story 和 case。

4.5 测试用例管理（职责：技术团队） ​

角色： 测试人员

  1. 按系统功能模块创建用例目录。
  2. 根据需求点编写测试用例。
  3. 上传用例。

4.6 开发阶段及提测（职责：技术团队） ​

角色： 开发人员

  1. 对应功能处于开发过程中，将状态打为 “实现中”。
  2. 对应的功能开发完成，且冒烟自测通过后，将状态调整为 “已实现”；处理人为对应的测试人员，点击【流转】，完成功能提测。

4.7 缺陷管理（职责：技术团队） ​

测试人员在创建缺陷的过程：

  1. 描述清楚用例的标题。
  2. 描述清楚测试环境，复现步骤，以及附上截图。
  3. 缺陷应关联对应的需求，版本，模块，优先级，bug 的严重级别，当前处理人，测试人员。

4.8 测试阶段（职责：技术团队） ​

接手提测功能后，根据对应模块执行测试用例。如仍处于测试中的模块标记为：“测试中”。对应的 story 完成测试，缺陷清 0，将状态调整为：“测试通过”。

4.9 正常版本发布（职责：项目经理/技术团队/产品团队） ​

角色： 运维人员

  1. 根据发布计划按正常流程发布版本。
  2. 创建发布评审。
  3. 选择发布流程--正常发布流程。
  4. 选择对应的发布确认人。
  5. 评审人确认。
  6. 提交评审。

4.10 紧急发布（职责：项目经理/技术团队/产品团队） ​

用于紧急修复线上问题。如有生产问题紧急发布，开发人员修复完毕后，提交给测试人员，在测试环境验收

通过后，由运维同事发布上线，需走紧急发布评审。

  1. 创建发布评审。
  2. 选择发布流程--紧急发布流程。
  3. 选择对应的发布确认人。
  4. 评审人确认。
  5. 提交评审。