5.0 KiB
5.0 KiB
# 工作项标题命名流程
```mermaid
flowchart TD
A[确定工作项层级] --> B[选择命名模式]
B --> C[应用命名规则]
C --> D[检查命名质量]
D --> E{质量检查}
E -->|通过| F[标题确认]
E -->|不通过| G[优化调整]
G --> C
A --> A1[Epic层级]
A --> A2[Feature层级]
A --> A3[Story层级]
A --> A4[Task层级]
```
## 分层命名体系
```mermaid
mindmap
root((工作项命名))
Epic命名
"Epic X: 主题名称"
功能域描述
价值主题表达
Feature命名
"Feature X.Y: 功能模块"
能力描述
模块边界
Story命名
"Story X.Y.Z: 用户能够..."
用户视角
具体行为
Task命名
"Task X.Y.Z.N: 实现..."
技术视角
具体实现
```
- **Epic层级**: `Epic X: 主题名称`
- X为数字序号（1,2,3...）
- 主题名称简洁概括核心价值域
- 示例：`Epic 1: 核心工作区`、`Epic 2: 文件系统`
- **Feature层级**: `Feature X.Y: 功能模块名`
- X为所属Epic编号，Y为Feature序号
- 功能模块名描述具体能力边界
- 示例：`Feature 1.1: 全局结构`、`Feature 1.2: 内容预览区`
- **Story层级**: `Story X.Y.Z: 角色+能够+动作+对象`
- X.Y为所属Feature编号，Z为Story序号
- 严格按照用户故事格式："XXX能够..."
- 示例：`Story 1.1.1: 教师能够查看和管理试题结构`
- **Task层级**: `Task X.Y.Z.N: 实现/开发/设计+具体内容`
- X.Y.Z为所属Story编号，N为Task序号
- 技术实现视角，动词+具体任务
- 示例：`Task 1.1.1.1: 实现试题结构树组件`
### 命名语言规范
- **动词选择精准**：避免模糊动词，使用具体行为词
- ✅ 查看、编辑、创建、删除、导出
- ❌ 处理、操作、管理（过于宽泛）
- **对象描述具体**：明确操作对象和范围
- ✅ 试题结构、用户权限、数据报表
- ❌ 内容、信息、数据（过于抽象）
- **角色明确标识**：Story必须明确用户角色
- ✅ 教师能够、学生能够、管理员能够
- ❌ 用户能够（角色不明确）
### 特殊情况处理
- **跨Feature Story**: 使用主Feature编号，标注依赖
- **技术性Story**: 标注"系统能够"而非用户角色
- **Bug修复Task**: 使用"修复+具体问题"格式
- **重构Task**: 使用"重构+模块名+原因"格式
2. **命名格式强制**
- Epic/Feature/Story/Task前缀必须使用
- 编号格式严格按照X.Y.Z.N模式
- Story必须包含"能够"关键词
- Task必须包含动作动词
3. **长度限制规则**
- Epic标题不超过20个字符
- Feature标题不超过30个字符
- Story标题不超过50个字符
- Task标题不超过40个字符
4. **语义一致性规则**
- 同Epic下Feature语义边界清晰不重叠
- 同Feature下Story粒度一致
- 标题与工作项实际内容保持一致
2. **团队认知限制**
- 新成员对编号体系的学习成本
- 跨团队协作时的理解一致性
- 国际化团队的语言统一性
3. **历史遗留约束**
- 已有项目的编号体系兼容性
- 迁移过程中的重复编号处理
- 历史数据的追溯完整性