<execution domain="product-management">
  <process>
    # Story设计流程
    
    ```mermaid
    flowchart TD
      A[Feature功能拆解] --> B[识别用户角色]
      B --> C[编写Story格式]
      C --> D[INVEST原则验证]
      D --> E[编写验收标准]
      E --> F[Story估算]
      F --> G{质量检查}
      G -->|通过| H[Story就绪]
      G -->|不通过| I[重新编写]
      I --> C
      
      B1[主要用户角色] --> B
      B2[次要用户角色] --> B
      B3[系统角色] --> B
    ```
    
    ## Story编写模式
    
    ```mermaid
    mindmap
      root((Story结构))
        3C模式
          Card(卡片)
            简洁故事描述
            标准格式
          Conversation(对话)
            团队讨论
            需求澄清
          Confirmation(确认)
            验收标准
            完成定义
        INVEST原则
          Independent(独立)
          Negotiable(可协商)
          Valuable(有价值)
          Estimable(可估算)
          Small(小粒度)
          Testable(可测试)
    ```
  </process>
  
  <guideline>
    ### Story标准格式
    
    ```
    作为 [用户角色]
    我想要 [完成什么功能]
    以便于 [获得什么价值/达成什么目标]
    ```
    
    - **用户角色**: 具体明确，避免"用户"这样的泛化表达
    - **功能描述**: 从用户视角描述，避免技术实现细节
    - **价值目标**: 明确用户为什么需要这个功能
    
    ### 验收标准编写(GWT格式)
    
    ```
    给定 [前置条件/初始状态]
    当 [用户执行的操作]
    那么 [预期的结果/系统反应]
    ```
    
    - **覆盖主要场景**: 正常流程、异常流程、边界条件
    - **具体可测**: 避免主观词汇，使用具体标准
    - **完整性**: 功能验收、质量验收、非功能性要求
    
    ### Story大小控制
    
    | Story类型 | 建议大小 | 开发时间 | Story Points |
    |----------|---------|---------|-------------|
    | 简单Story | 1-2 SP | 0.5-1天 | 1-2点 |
    | 标准Story | 3-5 SP | 1-3天 | 3-5点 |
    | 复杂Story | 8 SP | 3-5天 | 8点(需拆分) |
    
    ### Story到Task拆解策略
    
    ```mermaid
    flowchart LR
      A[Story] --> B[前端Tasks]
      A --> C[后端Tasks]
      A --> D[测试Tasks]
      A --> E[其他Tasks]
      
      B --> B1[UI组件]
      B --> B2[交互逻辑]
      C --> C1[API接口]
      C --> C2[业务逻辑]
      D --> D1[单元测试]
      D --> D2[集成测试]
      E --> E1[文档更新]
      E --> E2[部署配置]
    ```
  </guideline>
  
  <rule>
    1. **INVEST原则强制遵循**
       - Independent: Story间依赖最小化，可调整开发顺序
       - Negotiable: 保持描述灵活性，通过对话细化需求
       - Valuable: 每个Story都有明确用户价值
       - Estimable: 需求清晰，技术方案明确，可准确估算
       - Small: 1-2周内完成，单人可独立开发
       - Testable: 有具体验收标准，可验证完成状态
    
    2. **Story格式强制要求**
       - 必须使用"作为...我想要...以便于..."标准格式
       - 用户角色必须具体明确，不能使用"用户"泛称
       - 功能描述从用户视角，避免技术实现术语
       - 价值目标必须明确表达用户获得的价值
    
    3. **验收标准强制要求**
       - 必须使用Given-When-Then格式
       - 至少包含3个场景：正常、异常、边界
       - 标准必须具体可测，避免主观判断
       - 必须包含功能、质量、性能标准
    
    4. **拆分触发条件**
       - 超过8 Story Points必须拆分
       - 开发时间超过1周必须拆分
       - 涉及多个用户角色需要拆分
       - 包含技术风险或不确定性需要拆分
  </rule>
  
  <constraint>
    1. **团队技能约束**
       - Story复杂度受团队技能水平限制
       - 新技术学习成本影响估算准确性
       - 跨技能Story需要多人协作
    
    2. **技术债务约束**
       - 现有代码质量影响新功能开发
       - 技术架构限制功能实现方式
       - 测试覆盖率影响Story验收
    
    3. **业务约束**
       - 业务规则复杂度影响Story大小
       - 合规要求增加开发复杂度
       - 用户体验一致性要求约束实现
    
    4. **项目约束**
       - 迭代时间盒限制Story数量
       - 测试资源限制验收能力
       - 发布窗口影响Story优先级
  </constraint>
  
  <criteria>
    | 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
    |---------|---------|---------|-----------|
    | INVEST符合度 | 完全符合6个INVEST原则 | 基本符合，个别项可改进 | 不符合多个INVEST原则 |
    | 格式规范性 | 严格按照标准格式，角色价值明确 | 基本符合格式要求 | 格式不规范或要素缺失 |
    | 验收标准质量 | GWT格式完整，场景覆盖全面 | 基本明确可测 | 标准模糊或不可测试 |
    | 用户价值 | 价值明确且用户强烈需要 | 有一定价值 | 价值不明确或技术导向 |
    | 估算准确性 | 估算准确，风险可控 | 估算基本合理 | 估算偏差大或风险高 |
    | 独立性 | 完全独立可单独开发交付 | 基本独立，少量依赖 | 严重依赖其他Story |
    | 可测试性 | 验收标准具体可重复执行 | 基本可测试 | 难以验证或标准主观 |
    | 大小合理性 | 1-2周完成，复杂度适中 | 大小基本合理 | 过大过小影响交付 |
  </criteria>
</execution>