141 lines
5.0 KiB
Markdown
141 lines
5.0 KiB
Markdown
<execution domain="product-management">
|
||
<process>
|
||
# 工作项标题命名流程
|
||
|
||
```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: 实现..."
|
||
技术视角
|
||
具体实现
|
||
```
|
||
</process>
|
||
|
||
<guideline>
|
||
### 层级编号规则
|
||
|
||
- **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**: 使用"重构+模块名+原因"格式
|
||
</guideline>
|
||
|
||
<rule>
|
||
1. **编号连续性强制**
|
||
- 同层级编号必须连续，不允许跳号
|
||
- 删除工作项时编号不重用，保持历史追溯
|
||
- 新增工作项使用下一个可用编号
|
||
|
||
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粒度一致
|
||
- 标题与工作项实际内容保持一致
|
||
</rule>
|
||
|
||
<constraint>
|
||
1. **工具平台限制**
|
||
- 不同项目管理工具对标题长度有限制
|
||
- 某些平台不支持特殊字符或表情符号
|
||
- 编号格式需兼容排序和筛选功能
|
||
|
||
2. **团队认知限制**
|
||
- 新成员对编号体系的学习成本
|
||
- 跨团队协作时的理解一致性
|
||
- 国际化团队的语言统一性
|
||
|
||
3. **历史遗留约束**
|
||
- 已有项目的编号体系兼容性
|
||
- 迁移过程中的重复编号处理
|
||
- 历史数据的追溯完整性
|
||
</constraint>
|
||
|
||
<criteria>
|
||
| 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
|
||
|---------|---------|---------|-----------|
|
||
| 编号规范性 | 完全符合X.Y.Z.N格式，无跳号 | 基本符合格式，偶有不规范 | 编号混乱或格式错误 |
|
||
| 语义清晰度 | 标题一目了然，无歧义 | 标题基本清楚，少量模糊 | 标题含糊或表达不准确 |
|
||
| 层级一致性 | 同层级粒度和表达方式统一 | 基本一致，个别项例外 | 层级混乱或不一致 |
|
||
| 用户视角 | Story严格按用户故事格式 | Story基本符合用户视角 | Story缺少用户视角 |
|
||
| 可搜索性 | 关键词明确，便于搜索筛选 | 关键词基本明确 | 关键词缺失或不明确 |
|
||
| 长度适当性 | 符合长度限制且信息充分 | 长度可控，信息基本充分 | 过长或过短影响理解 |
|
||
</criteria>
|
||
</execution> |