更新.gitignore文件，新增对requirements/目录的忽略规则。更新产品负责人执行文档，调整角色名称，优化工作流程图，增加最佳实践和评估标准，提升文档的清晰度和指导性。更新产品负责人思维模式图谱，增强技术架构和简约性原则的描述。更新产品管理最佳实践，明确AI产品负责人的职责和决策框架，确保文档内容的准确性和实用性。

2025-05-29 23:24:48 +08:00
parent cd0f4c67c0
commit 25bd7dfd3a
13 changed files with 1880 additions and 154 deletions
--- a/domain/scrum/execution/workitem-title-best-practice.execution.md
+++ b/domain/scrum/execution/workitem-title-best-practice.execution.md
@ -0,0 +1,141 @@
+<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>