<execution domain="project-management">
  
  # Task设计核心理念
  
  ## 🛠️ Task = 解决问题的实现
  
  ```markdown
  Task的本质：解决具体技术实现问题
  核心思考：如何具体实现这个功能？
  
  问题导向框架：
  📋 提问题层: Epic → Feature → Story (需求定义)
  🛠️ 解决问题层: Task (技术实现) ← 我们在这里
  ✅ 验证层: TestCase (质量保证)
  🎯 价值确认层: Milestone (交付确认)
  ```
  
  **Task的职责边界**：
  - ✅ 解决具体技术实现问题
  - ✅ 定义技术方案和开发步骤
  - ✅ 分配技术资源和时间规划
  - ✅ **必须关联到对应Story**（明确解决哪个用户问题）
  - ❌ 不重新定义用户需求
  - ❌ 不改变Story的验收标准
  
  <process>
    # Task拆解流程
    
    ```mermaid
    flowchart TD
      A[Story分析] --> B[确定拆解策略]
      B --> C[识别Task边界]
      C --> D[分配责任人]
      D --> E[评估依赖关系]
      E --> F[时间估算]
      F --> G{质量检查}
      G -->|通过| H[Task就绪]
      G -->|不通过| I[重新拆解]
      I --> C
      
      B --> B1[技能领域拆解]
      B --> B2[开发阶段拆解]
      B --> B3[垂直切片拆解]
      B --> B4[依赖关系拆解]
    ```
    
    ## Task协作模式
    
    ```mermaid
    mindmap
      root((Task协作))
        前后端协作
          API优先模式
          Mock数据并行
          接口联调集成
        测试驱动协作
          TDD红绿重构
          持续集成验证
          自动化部署
        跨技能协作
          专业分工模式
          功能团队模式
          全栈协调模式
        进度跟踪
          每日站会更新
          看板状态管理
          燃尽图监控
    ```
  </process>
  
  <guideline>
    ### Task拆解策略
    
    #### 1. 技能领域拆解法
    
    ```markdown
    Story → 按技能分工：
    - 前端Tasks: UI组件、交互逻辑、状态管理
    - 后端Tasks: API接口、业务逻辑、数据处理
    - 测试Tasks: 单元测试、集成测试、E2E测试
    - DevOps Tasks: 部署配置、监控告警、文档更新
    ```
    
    #### 2. 依赖关系分析
    
    | 依赖类型 | 处理策略 | 解耦方法 |
    |----------|---------|---------|
    | 顺序依赖 | 确定关键路径 | 识别最小可行产品 |
    | 并行依赖 | 接口Mock解耦 | Contract Testing |
    | 阻塞依赖 | 重新调整边界 | Feature Flag控制 |
    | 技术依赖 | 垂直切片策略 | 端到端最小功能 |
    
    #### 3. Task大小控制
    
    ```mermaid
    flowchart LR
      A[Task识别] --> B{工作量评估}
      B -->|< 1h| C[合并Task]
      B -->|1-16h| D[标准Task]
      B -->|> 16h| E[拆分Task]
      
      C --> F[重新组合边界]
      D --> G[Task就绪]
      E --> H[进一步细分]
      
      F --> B
      H --> B
    ```
    
    #### 4. Task-Story关联最佳实践
    
    ```mermaid
    flowchart TD
      A[Story分析] --> B[识别实现需求]
      B --> C{Task类型判断}
      C -->|开发Task| D[必须关联Story]
      C -->|独立Task| E[可不关联Story]
      
      D --> F[设置story_id字段]
      F --> G[验收标准对齐]
      G --> H[进度状态同步]
      
      E --> I[技术债务]
      E --> J[环境维护] 
      E --> K[工具优化]
    ```
    
    **关联策略选择**:
    
    | Task类型 | 是否关联Story | 关联方式 | 备注 |
    |----------|--------------|---------|------|
    | 功能开发 | ✅ 必须关联 | story_id字段 | 直接支撑用户故事 |
    | Bug修复 | ✅ 建议关联 | 关联相关Story | 如果修复已有功能 |
    | 测试编写 | ✅ 必须关联 | story_id字段 | 验证Story验收标准 |
    | 重构优化 | ✅ 建议关联 | 关联受影响Story | 如果影响现有功能 |
    | 技术债务 | ❌ 可不关联 | 独立Task | 技术改进类工作 |
    | 环境配置 | ❌ 可不关联 | 独立Task | 基础设施工作 |
    | 文档更新 | ⚠️ 视情况而定 | 关联相关Story | 如果是功能文档 |
    
    **关联质量检查点**:
    
    ```markdown
    ✅ Task验收标准支撑Story验收标准
    ✅ Task完成后Story进度得到更新  
    ✅ Task优先级与Story优先级一致
    ✅ Task负责人了解Story背景和目标
    ✅ 项目管理工具中关联关系正确显示
    ```
    
    ### Task标准模板
    
    ```markdown
    ## T-{StoryID}-{序号}: {任务标题}
    
    **基本信息**:
    - 关联Story: [Story ID] - {Story标题}
    - 任务类型: [开发/测试/设计/部署]
    - 负责人: [具体团队成员]
    - 预估工时: [1-16小时]
    - 优先级: [P0-P3]
    
    **验收标准**:
    - [ ] 功能完整实现
    - [ ] 代码质量达标
    - [ ] 测试覆盖充分
    - [ ] 文档更新完成
    
    **依赖关系**:
    - 前置Task: [必须先完成的任务]
    - 阻塞Task: [被此任务阻塞的任务]
    - 相关资源: [设计稿、API文档等]
    
    **风险评估**:
    - 技术风险: [新技术、复杂度]
    - 时间风险: [依赖等待、资源冲突]
    - 质量风险: [测试覆盖、代码审查]
    ```
    
    ### 跟踪与管理
    
    #### 看板状态流转
    
    ```mermaid
    stateDiagram-v2
      [*] --> 待办
      待办 --> 进行中: 开始工作
      进行中 --> 代码审查: 开发完成
      代码审查 --> 测试中: 审查通过
      代码审查 --> 进行中: 需要修改
      测试中 --> 已完成: 测试通过
      测试中 --> 进行中: 发现问题
      已完成 --> [*]
    ```
    
    #### 每日站会汇报格式
    
    ```markdown
    **昨天完成**:
    - Task T-001: 树形组件基础结构 ✅
    
    **今天计划**:
    - Task T-002: 实现点击导航功能
    
    **遇到阻塞**:
    - 等待API接口联调
    
    **需要帮助**:
    - UX交互细节确认
    ```
    
    ### 估算方法
    
    #### 历史数据参考标准
    
    | Task类型 | 简单(2-4h) | 标准(4-8h) | 复杂(8-16h) |
    |----------|------------|------------|-------------|
    | 前端组件 | 简单UI组件 | 复杂交互组件 | 大型页面开发 |
    | 后端API | 简单CRUD | 复杂业务逻辑 | 系统集成 |
    | 数据库 | 表结构调整 | 查询优化 | 数据迁移 |
    | 测试 | 单元测试 | 集成测试 | E2E自动化 |
    
    #### 三点估算法
    
    ```
    估算时间 = (最乐观 + 4×最可能 + 最悲观) / 6
    
    示例: API开发任务
    - 最乐观: 4小时
    - 最可能: 8小时  
    - 最悲观: 16小时
    - 估算结果: 8.7小时
    ```
  </guideline>
  
  <rule>
    1. **Task大小强制要求**
       - 单个Task工作量1-16小时
       - 超过16小时必须拆分
       - 少于1小时考虑合并
       - 可在1-2天内完成
    
    2. **Task定义强制要求**
       - 必须有明确负责人
       - 必须有具体验收标准
       - 必须有清晰任务描述
       - 必须评估技术风险
       - **必须关联到对应Story**（除非是独立维护任务）
    
    3. **Task-Story关联强制要求**
       - 每个开发Task必须关联到具体Story
       - 在项目管理工具中正确设置story_id字段
       - Task验收标准必须支撑Story验收标准
       - Task完成状态必须反映Story进度
       - 独立Task（如环境维护、技术债务）可例外
    
    4. **依赖管理强制要求**
       - 识别所有前置依赖
       - 标明阻塞影响关系
       - 提供解耦替代方案
       - 建立风险预警机制
    
    5. **进度跟踪强制要求**
       - 每日更新Task状态
       - 及时反馈阻塞问题
       - 记录实际工时偏差
       - 定期回顾改进估算
  </rule>
  
  <constraint>
    1. **团队技能约束**
       - 专业技能分工限制
       - 学习曲线时间成本
       - 人员可用时间限制
       - 关键人员依赖风险
    
    2. **技术环境约束**
       - 开发环境资源限制
       - 第三方服务依赖
       - 网络和硬件限制
       - 工具和平台限制
    
    3. **时间盒约束**
       - Sprint时间限制
       - 里程碑交付要求
       - 发布窗口限制
       - 客户期望时间
    
    4. **质量约束**
       - 代码覆盖率要求
       - 性能指标要求
       - 安全合规要求
       - 用户体验标准
  </constraint>
  
  <criteria>
    | 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
    |---------|---------|---------|-----------|
    | 拆解粒度 | 1-16h工作量精准控制 | 基本符合大小要求 | 过大过小影响执行 |
    | 任务定义 | 描述清晰标准具体 | 基本明确可执行 | 定义模糊难理解 |
    | Story关联性 | 所有Task正确关联Story | 大部分Task已关联 | 关联缺失或错误 |
    | 依赖管理 | 依赖识别完整有预案 | 主要依赖已识别 | 依赖遗漏频繁阻塞 |
    | 责任分工 | 责任明确负载均衡 | 基本分工合理 | 分工不明或负载失衡 |
    | 估算准确性 | 估算偏差<20% | 估算偏差<50% | 估算偏差>50% |
    | 跟踪及时性 | 实时状态更新 | 每日更新状态 | 状态更新滞后 |
    | 协作效率 | 协作顺畅无等待 | 基本协作顺利 | 频繁等待阻塞 |
    | 交付质量 | 一次性通过验收 | 少量修改后通过 | 多次返工修改 |
  </criteria>
</execution>