.cursor/rules/5sguize.mdc

---
alwaysApply: true
---
### **软件开发人员5S个人工作规范体系**  
**版本：** 1.0  
**生效日期：** 2025年8月16日  

---

#### **1. 文档管理规范（Seiri - 整理）**  
**目标：** 消除冗余文档，确保必要信息结构化存储。  
**1.1 文档创建触发条件**  
- ✅ 必须创建文档的场景：  
  - 项目启动（输出《项目计划书》）  
  - 需求变更（更新《需求规格说明书》）  
  - 技术方案评审（输出《技术设计文档》）  
  - 事故复盘（输出《故障分析报告》）  
**1.2 文档核心要素**  
- 所有文档必须包含：  
  ```markdown
  - 目标 | 版本号 | 责任人 | 最后更新日期  
  - 变更记录（含修改人、修改内容）  
  - 关联资源链接（代码库/JIRA编号）  
  ```  
**1.3 版本控制机制**  
- 使用Git管理文档（Markdown格式），禁止本地存档  
- 文档更新必须：  
  - 更新版本号（语义化版本 `v<主>.<次>.<补丁>`）  
  - 提交变更日志（>50字说明）  
**✅ 检查点：**  
- 月度文档审计（抽查20%文档，检查要素完整性与版本合规性）  
- **评估标准：** 文档缺失率 ≤ 5%，版本记录完整率100%  

---

#### **2. 开发流程规范（Seiton - 整顿）**  
**目标：** 标准化流程，减少上下文切换成本。  
**2.1 标准开发步骤**  
```mermaid
graph LR
A[需求分析] --> B[技术设计]
B --> C[编码]
C --> D[单元测试]
D --> E[Code Review]
E --> F[集成测试]
```  
**2.2 代码提交规范**  
- 单次提交代码量 ≤ 300行  
- 提交信息格式：  
  ```git
  feat|fix|docs|refactor(<模块>): <描述> [JIRA-ID]
  # 示例：fix(auth):修复登录token过期逻辑 [PROJ-123]
  ```  
**2.3 质量控制标准**  
- 单元测试覆盖率 ≥ 80%（语言无关）  
- Code Review必须：  
  - 2人以上参与  
  - 使用工具（GitLab MR/SonarQube）  
  - 24小时内完成  
**✅ 检查点：**  
- CI流水线拦截未达标代码（测试覆盖率/静态扫描）  
- **评估标准：** MR平均周转时间 ≤ 4小时，缺陷泄漏率 ≤ 2%  

---

#### **3. 问题解决规范（Seiso - 清扫）**  
**目标：** 快速定位并根治问题。  
**3.1 问题分级标准**  
| 级别 | 响应时限 | 影响范围示例 |  
|-------|-----------|----------------|  
| P0    | ≤15分钟  | 线上核心功能瘫痪 |  
| P1    | ≤2小时   | 主要功能降级   |  
| P2    | ≤8小时   | 次要功能异常   |  
| P3    | ≤24小时  | 优化建议       |  
**3.2 问题处理流程**  
1. **记录**：JIRA创建Issue（附日志/截图/复现步骤）  
2. **分析**：根因定位（使用5Why法）  
3. **解决**：提交Hotfix（遵循2.2规范）  
4. **验证**：回归测试 + 文档更新  
**3.3 追踪要求**  
- 所有问题关联知识库条目（Confluence）  
- P0级问题必须输出《故障报告》  
**✅ 检查点：**  
- 问题平均解决时长（MTTR）统计  
- **评估标准：** P0解决时效达标率100%，知识库覆盖率 ≥ 90%  

---

#### **4. 执行约束规范（Seiketsu - 清洁）**  
**目标：** 建立可持续的高效工作节奏。  
**4.1 工作纪律**  
- 每日站会 ≤ 15分钟（聚焦阻塞点）  
- 专注时段（10:00-12:00/14:00-16:00）禁用IM通知  
**4.2 时间管理**  
- 任务拆解为 ≤2h 的原子任务  
- 使用番茄工作法（25分钟专注+5分钟休息）  
**4.3 沟通协作**  
- 紧急问题：Slack @责任人 + 电话  
- 技术讨论：提前预约会议（需提供议题文档）  
**✅ 检查点：**  
- 周计划完成率（实际完成/计划任务数）  
- **评估标准：** 计划完成率 ≥ 85%，会议超时率 ≤ 10%  

---

#### **5. 环境和输出规范（Shitsuke - 素养）**  
**目标：** 保障交付物质量与知识传承。  
**5.1 工作环境标准**  
- 本地开发环境：  
  - 使用Docker容器化（版本锁定）  
  - IDE插件统一（Prettier/ESLint）  
- 项目目录结构：  
  ```bash
  /src      # 源代码
  /tests    # 测试用例
  /docs     # 项目文档
  README.md # 项目入口
  ```  
**5.2 交付物质量标准**  
| 交付物       | 质量要求                     |  
|--------------|------------------------------|  
| 代码         | 通过SonarQube质量门禁        |  
| 部署包       | 包含版本签名（GPG）          |  
| 用户文档     | 提供搜索功能 + 截图示例      |  
**5.3 知识沉淀要求**  
- 技术方案评审后48小时内归档  
- 每月输出1篇技术总结（含踩坑记录）  
**✅ 检查点：**  
- 交付物验收通过率（QA测试报告）  
- **评估标准：** 一次交付合格率 ≥ 95%，知识文档产出量 ≥ 1篇/人/月  

---

### **执行保障机制**  
1. **个人看板**：使用Trello管理每日任务（To Do/Doing/Done）  
2. **月度自评**：依据检查点填写《5S执行评分表》（满分100分，≥80分达标）  
3. **持续改进**：季度复盘会（优化低分项规范）  

> **附件模板：**  
> - [5S执行评分表.xlsx](链接)  
> - [文档变更记录模板.md](链接)  
> - [JIRA问题分类标签表.csv](链接)  

本规范通过**工具强制（CI/CD门禁）** + **文化引导（知识共享）** 双轨落地，确保开发者从"被动遵守"到"主动优化"的进阶。
alwaysApply: false
---