150 lines
5.5 KiB
Plaintext
150 lines
5.5 KiB
Plaintext
---
|
||
description:
|
||
globs:以下是为软件开发人员设计的**5S个人工作规范体系**，结合5S管理原则（整理、整顿、清扫、清洁、素养）与技术实践需求，采用模块化分层结构，包含可执行条款与评估标准：
|
||
|
||
---
|
||
|
||
### **软件开发人员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
|
||
---
|