两种形式的产研流程
瀑布流
瀑布流模型是一种线性、顺序的软件开发方法，特别适合那些需求明确、变更较少的项目。整个流程可以理解为多个阶段的串联，每个阶段完成后才能进入下一个阶段。各个步骤如下：
流程框架
需求分析
需求分析阶段的目标就是明确项目的全部需求。包括用户需求、技术要求和业务目标。
产物是需求文档PRD。
系统设计
系统设计又分为概要设计（High-Level Design）和详细设计（Low-Level Design）。概要设计关注架构和整体技术方案，而详细设计则需要定义各个模块的功能、接口、数据结构等。
产物是技术方案设计文档。
开发
在开发阶段，开发人员需要严格按照设计文档进行编码，确保各模块的功能都能正确实现。
产物是代码。
测试
测试阶段包括单元测试、集成测试和系统测试，目的是确保软件质量。测试要尽可能覆盖各种场景，尤其是边界情况，提前发现问题。
产物是测试分析文档和测试用例。
部署上线
一切测试通过之后，才会将产品部署到生产环境中。
维护和支持
一旦产品上线，接下来还要进行持续的维护和优化。特别是用户反馈、bug 修复、新功能迭代等，这就需要产研团队的持续跟进。
优缺点
优点：流程清晰、文档详细、各阶段有明确的交付物，适合需求稳定、预期明确的项目
缺点：因为每个阶段是线性的，一旦需求变更或设计有问题，后续返工的成本会很高，效率也低。
敏捷开发
一种迭代式、增量式的软件开发方法。要点就是灵活应对需求变更，快速交付可用的产品。
核心理念
- 拥抱变化：和瀑布流不同，敏捷开发欢迎需求的变化，即使是在项目的后期。
- 持续交付：通过短周期的迭代，每次都能交付一个可用的、经过测试的产品功能。这样就能及时获取用户反馈，快速调整方向。
- 跨职能团队：敏捷团队通常是小而精的，每个人都是多面手（产、研、测一条龙），这样沟通效率高
流程框架
敏捷开发本身并没有固定的流程，而是有很多实施框架，比如Scrum、Kanban、XP (Extreme Programming)。本文重点最常见的 Scrum。
Scrum角色
- 产品负责人 (Product Owner)：决定产品的优先级和需求。就相当于需求的“老板”，但绝不是拍脑袋瞎指挥，而是基于用户和业务的实际需求。
- Scrum Master：确保团队按敏捷的方式运作，负责扫清障碍。这人就像是团队的保姆，帮你们团队排除一切干扰。
- 开发团队：跨职能的小团队，负责具体的开发、测试和交付。
Scrum流程
- 需求池 (Backlog)：所有待办事项和功能需求都会记录在这里。产品负责人会不断优先级排序，确保最有价值的事情优先开发。
- Sprint计划会议：每次迭代（Sprint）开始前，团队会开个会讨论接下来1-4周要完成的任务。这可不是走过场，你得认真想清楚哪些是可交付的功能。
- 每日站会 (Daily Stand-Up)：每天的短会（一般不超过15分钟），各自汇报一下昨天干了啥、今天要干啥，有啥困难需要帮助解决。
- Sprint回顾 (Review)：每次迭代结束后，团队会展示完成的功能并收集用户和利益相关者的反馈。
- Retro会议 (Retrospective)：团队内部的复盘会议，找找这次Sprint里做得好的和需要改进的地方。
优缺点
优点
- 灵活应对需求变化，迭代快，用户反馈及时。
- 缩短交付周期，让产品更早进入市场。
- 强调团队协作，减少沟通障碍。
缺点
- 不适合需求不明确或没有产品负责人把控优先级的情况。
- 如果团队成员的自我管理能力不够，可能会陷入“忙忙碌碌却没啥产出”的困境。
公司IT的产研流程
宏观上是瀑布流流程，微观看存在很多敏捷元素[参考]。
特征分析
瀑布流特性
- 线性推进
按照明确的阶段划分，包括需求提交、产品设计、需求评审、开发阶段、测试阶段、上线阶段等。每个阶段基本是完成一个环节后才能进入下一个环节，呈现出典型的线性流动。
- 文档驱动
每个环节都有明确的文档产物，强调了文档和设计的完备性，高度依赖文档来规范流程。
敏捷元素
- 晨会机制（信息透明和可视化）
- 月排机制
- CI/CD机制
- 测试左移、开发右移[
- ]
当前存在的问题
描述
目前，我观察到一个很大的问题，是**需求变更处理能力弱，过程中的需求变动无法连续管理。**
根源分析
下面是从文档的角度，说明这个问题的产生根源。
| 说明 | 备注 | 文档链接 | |
|---|---|---|---|
| 1 | 产品文档规范里，有明确的修改日志记录。 |  |
https://gumingnc.yuque.com/voph0x/mepwp5/zi7love8yxx8u4gh |
| 2 | 设计文档里没有 | https://gumingnc.yuque.com/voph0x/mepwp5/rvltpg | |
| 3 | 测试分析里没有 | https://gumingnc.yuque.com/voph0x/lw8vdr/um66x7cql17yehvg |
可以发现，不同环节的产物文档模板的不对称性，导致了过程中的变更被丢失，在设计文档里丢失的。
理想情况下，产研流程的prd、设计文档、代码改动、用例是一一对应的，每个需求点在产研流程中都是可被追溯的，可以从前往后追溯，也可以从后往前回溯。
现在，过程中变动的功能点无法追溯。
可行方案：需求追踪矩阵
需求追踪矩阵就是用来追踪需求从起点到终点的一张表格，确保每一个需求都能贯穿整个项目生命周期——从需求分析、设计、开发、测试到最终上线。这张表会把需求、代码改动、测试用例都联系起来，确保没有遗漏，所有需求都被正确实现并经过验证。
| 需求ID | 需求描述 | 相关模块 | 设计文档 | 测试用例 ID | 测试状态 | 优先级 | 备注 | |
|---|---|---|---|---|---|---|---|---|
| RQ-001 用户登录功能 | 用户管理 | 登录设计文档 | xxx | TC-101 | 通过 | 高 | N/A | |
| RQ-002 用户注册功能 | 用户管理 | 注册设计文档 | xxx | TC-102 | 未通过 | 中 | 需优化 |
- 创建需求追踪矩阵
一开始就要根据PRD（产品需求文档）创建需求列表，每个需求分配一个唯一的需求 ID（如 RQ-001）。
- 关联设计文档和代码
对于每个需求，列出其相关的设计文档和代码模块。这样当需求发生变动时，你能快速定位到受影响的模块。
- 关联测试用例
为每个需求分配相应的测试用例（TC-101、TC-102等），确保所有需求都有测试覆盖。测试完成后，更新测试状态（通过、未通过）。
- 定期更新和维护
需求变更、新增功能时，务必及时更新矩阵，确保所有信息保持同步。
文档精细度模型
在产研流程中，从需求功能点到代码模块改动，再到测试用例，是一个从高层次到低层次逐步具体化的过程。每个阶段产生的文档产物都有其特定的精细度要求和功能定位。
精细度层次模型
- 需求文档 (PRD)： 高层次，描述业务需求和用户视角。
- 方案设计文档： 中等粒度，提供模块划分和技术方向。
- 代码或配置改动： 偏细粒度，转化为具体实现。
- 测试用例： 最细粒度，验证功能实现的正确性。
PRD
精细度：高层次，偏抽象
- 明确需求的目标和范围，定义用户希望达成的核心价值。
- 以业务语言为主（高级语言、UML、流程图等），不涉及具体的技术实现细节。
方案设计文档
精细度：中等，技术实现的方向性说明
方案设计文档是对需求功能点的技术解读和实现规划，明确技术实现路径和系统架构设计，是开发团队的执行指南。
代码or配置改动
精细度：中等偏细，代码层面实现
将方案设计中的功能模块进一步细化为具体的代码实现或配置改动。
测试用例
精细度：最细粒度，验证具体实现
测试用例是对功能模块的验证，包括正向、逆向和边界测试，确保代码改动符合需求文档的要求。
本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。
