木风未来 - 标准业务

1. 引言

1.1. 文档目的

本文档旨在定义和规范“木风未来”产品/项目的标准化软件开发流程（Standard Development Process, SDP）。为项目经理、开发、测试、运维等角色提供统一的行动指南和规范，确保软件开发活动有序、高效、高质量地进行。

1.2. 目标读者

项目经理 (PM)
产品经理 (PdM)
UI/UX设计师
前端、后端、移动端开发工程师
测试工程师 (QA)
运维工程师 (Ops)
新入职员工

1.3. 原则与理念

敏捷迭代：采用敏捷开发模式，快速交付，持续反馈。
质量内建：将质量保证活动融入开发全过程，而非事后检查。
自动化优先：自动化一切可自动化的环节（构建、测试、部署）。
协作透明：信息对团队内成员透明，鼓励跨角色协作。

2. 角色与职责

角色	主要职责
产品经理	定义需求（PRD）、管理需求优先级、验收功能
项目经理	管理项目进度、协调资源、消除团队障碍、风险管理
技术负责人	技术选型、架构设计、代码评审、关键技术难题攻关
开发工程师	功能开发、单元测试、技术文档编写、缺陷修复
测试工程师	编写测试用例、执行测试、提交缺陷报告、质量度量
UI/UX设计师	界面设计、交互设计、提供设计资源和规范
运维工程师	环境搭建、CI/CD维护、系统监控、发布与部署

3. 核心开发流程 (Phases)

3.1. 需求与分析阶段 (Requirement & Analysis)

需求提出：产品经理撰写产品需求文档 (PRD) 并录入需求管理工具（如Jira/禅道）。
需求评审：召开需求评审会，开发、测试、设计团队参与，评估技术可行性、工作量、潜在风险。
需求定稿：根据评审反馈修订PRD，各方确认后进入设计阶段。

3.2. 设计与规划阶段 (Design & Planning)

UI/UX设计：设计师输出高保真原型和交互说明，开发团队参与设计评审。
技术设计：
- 技术方案设计：技术负责人或核心开发人员输出技术设计文档 (TDD)，包括API设计、数据库Schema、架构图等。
- 技术评审：组织技术评审会，确保方案合理性、可扩展性和无重大风险。
任务分解与排期：
- 将需求拆分为具体的开发任务（Task）。
- 开发团队进行工作量评估（人/日），输出迭代排期计划。

3.3. 开发与构建阶段 (Development & Build)

环境准备：基于Docker或Kubernetes的标准化开发环境。
编码规范：遵循统一的编码规范（如Java/JS等语言规范）、Git分支管理策略（如下文）。
每日构建：代码提交触发持续集成 (CI)，自动完成编译、静态代码检查（SonarQube）、单元测试。
代码评审：所有代码必须通过Pull Request (PR) 合并，至少需要一名同事评审 (Code Review) 通过。
单元测试：开发者需编写并通过单元测试，保证测试覆盖率。

3.4. 测试与验收阶段 (Test & Validation)

测试用例编写：QA根据PRD和设计稿编写测试用例，并组织用例评审。
功能测试：开发提测后，QA在测试环境执行测试用例，提交Bug。
自动化测试：回归测试用例由自动化测试脚本覆盖，并入CI流水线。
其他测试：根据需要进行性能、安全、兼容性测试。
产品验收：QA测试通过后，产品经理在预发布环境 (Staging) 进行最终验收测试（UAT）。

3.5. 发布与部署阶段 (Release & Deployment)

发布准备：更新版本号、编写发布说明 (Release Notes)、合并发布分支。
自动化部署：通过持续部署 (CD) 工具（如Jenkins, GitLab CI）一键部署至生产环境。
发布策略：默认采用蓝绿发布或金丝雀发布，以降低发布风险。
发布后验证：运维和开发人员监控系统日志、业务指标和监控大盘（如Grafana），确保发布成功。

3.6. 运维与监控阶段 (Ops & Monitor)

线上监控：对应用性能（APM）、服务器资源、业务核心指标进行7x24小时监控。
事件响应：收到告警后，按预案快速响应和处理。
复盘与改进：对线上事故进行复盘，生成故障报告，并持续改进流程和系统。

4. 支撑体系与规范 (Supporting Systems & Standards)

4.1. 工具链 (Toolchain)

项目管理：Jira
文档协作：Confluence / 飞书文档
代码托管：GitLab
CI/CD：GitLab CI / Jenkins
构建与依赖：Maven / Npm
镜像仓库：Harbor
部署与编排：Kubernetes / Docker
监控：Prometheus + Grafana
日志：ELK
通信：钉钉 / 飞书

4.2. 代码管理规范 (Git Flow)

我们采用 GitLab Flow 为主的分支模型：

main分支：保护分支，对应生产环境，代码始终是可发布状态。
pre-production分支：保护分支，对应预发布环境。
develop分支：保护分支，集成最新开发成果，对应测试环境。
功能分支：从develop拉取，命名规范为 feature/[jira-id]-[short-desc] (e.g., feature/PROJ-123-add-login)。
修复分支：从main拉取，命名规范为 hotfix/[jira-id]-[short-desc]。

4.3. 版本号规范 (Semantic Versioning)

采用语义化版本控制：主版本号.次版本号.修订号 (MAJOR.MINOR.PATCH)

PATCH：向后兼容的 bug 修复，递增修订号。
MINOR：向后兼容的新功能，递增次版本号，修订号归零。
MAJOR：不向后兼容的变更，递增主版本号，次版本号和修订号归零。

5. 附录

5.1. 常用文档模板链接

《产品需求文档 (PRD) 模板》
《技术设计文档 (TDD) 模板》
《测试用例模板》
《发布说明 (Release Notes) 模板》

5.2. 变更记录

版本	日期	作者	修订说明
v1.0	2025-09-20	[宏伟]	初版创建