<execution domain="product-management">
  <process>
    # Feature设计流程
    
    ```mermaid
    flowchart TD
      A[Epic功能分解] --> B[识别UI模块边界]
      B --> C[定义Feature范围]
      C --> D[设计技术边界]
      D --> E[制定验收标准]
      E --> F[Story拆解规划]
      F --> G{大小验证}
      G -->|合适| H[Feature就绪]
      G -->|过大/过小| I[重新调整]
      I --> C
      
      B1[界面区域分析] --> B
      B2[用户任务流程] --> B
      B3[技术组件映射] --> B
    ```
    
    ## Feature识别方法
    
    ```mermaid
    mindmap
      root((Feature识别))
        UI驱动
          界面区域划分
          交互流程完整性
          组件边界清晰
        价值驱动
          用户任务完整性
          功能价值独立性
          业务流程节点
        技术驱动
          架构模块对应
          服务边界清晰
          数据模型对齐
    ```
  </process>
  
  <guideline>
    ### Feature定义建议
    
    - **功能完整性**: Feature应代表完整的功能模块，用户能独立完成任务
    - **技术边界清晰**: 对应独立技术组件，便于并行开发
    - **用户可感知**: 有明确的UI界面或交互体验
    - **中等粒度**: 1-3个迭代完成，包含3-8个Story
    
    ### 大小控制指南
    
    | Feature类型 | 建议大小 | 完成时间 | Story数量 | 复杂度 |
    |------------|---------|---------|-----------|-------|
    | 简单Feature | 10-20 SP | 1迭代 | 2-4个Story | 低 |
    | 标准Feature | 20-40 SP | 1-2迭代 | 4-6个Story | 中 |
    | 复杂Feature | 40-60 SP | 2-3迭代 | 6-8个Story | 高 |
    
    ### 边界定义建议
    
    - **包含明确**: 列出具体的功能点和特性
    - **不包含明确**: 防止范围蔓延，明确排除内容
    - **依赖识别**: 技术依赖、数据依赖、业务依赖
    - **接口定义**: 与其他Feature的接口和数据流
    
    ### Story拆解策略
    
    ```mermaid
    flowchart LR
      A[Feature] --> B[核心功能Story]
      A --> C[交互操作Story]
      A --> D[数据管理Story]
      A --> E[异常处理Story]
      
      B --> B1[主要用例]
      C --> C1[用户操作]
      D --> D1[CRUD操作]
      E --> E1[错误处理]
    ```
  </guideline>
  
  <rule>
    1. **四个核心原则必须遵循**
       - 功能完整性: Feature代表完整功能模块
       - 技术边界清晰: 对应独立技术组件
       - 用户感知: 有明确的用户交互界面
       - 大小适中: 不超过3个迭代，60 SP上限
    
    2. **强制包含要素**
       - 功能边界必须明确定义（包含/不包含）
       - 验收标准必须具体可测
       - Story拆解必须覆盖核心功能
       - 技术依赖必须识别和记录
    
    3. **三层关系规则**
       - Epic → Feature: 价值主题到功能模块的分解
       - Feature → Story: 功能模块到用户任务的拆解
       - 层级间粒度跨度合理，避免过度拆分或粗糙
    
    4. **拆分触发条件**
       - 超过60 SP必须拆分
       - 跨越3个以上技术模块需要拆分
       - 包含不相关功能点需要重新组织
  </rule>
  
  <constraint>
    1. **技术架构约束**
       - Feature边界受现有架构模块限制
       - 微服务边界影响Feature划分
       - 数据模型设计影响功能范围
    
    2. **团队能力约束**
       - 并行开发Feature数量有限
       - 团队技能影响Feature复杂度
       - 跨团队Feature需要额外协调成本
    
    3. **用户体验约束**
       - UI一致性要求影响Feature边界
       - 用户流程完整性不可打断
       - 渐进式发布对Feature颗粒度的要求
    
    4. **项目约束**
       - 迭代时间盒限制Feature大小
       - 测试资源影响Feature验收
       - 发布节奏影响Feature优先级
  </constraint>
  
  <criteria>
    | 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
    |---------|---------|---------|-----------|
    | 功能完整性 | 用户能独立完成完整任务 | 基本功能完整，少量依赖 | 功能不完整或过度依赖 |
    | 边界清晰度 | 技术和功能边界都明确 | 边界基本清晰 | 边界模糊或重叠 |
    | 大小合理性 | 符合20-60SP范围，Story数量适中 | 大小基本合理 | 过大过小或拆分不当 |
    | 用户价值 | 独立交付价值，用户可感知 | 有一定价值 | 价值不明确或用户无感知 |
    | 技术可行性 | 技术实现边界清晰可行 | 基本可行 | 技术难度过高或边界不清 |
    | Story拆解质量 | Story覆盖全面，粒度一致 | 拆解基本合理 | 拆解不完整或粒度不一致 |
    | 验收标准 | 标准具体可测，覆盖全面 | 标准基本明确 | 标准模糊或不可测 |
  </criteria>
</execution>