9.3 KiB
9.3 KiB
Task设计核心理念
🛠️ Task = 解决问题的实现
Task的本质：解决具体技术实现问题
核心思考：如何具体实现这个功能？
问题导向框架：
📋 提问题层: Epic → Feature → Story (需求定义)
🛠️ 解决问题层: Task (技术实现) ← 我们在这里
✅ 验证层: TestCase (质量保证)
🎯 价值确认层: Milestone (交付确认)
Task的职责边界：
- ✅ 解决具体技术实现问题
- ✅ 定义技术方案和开发步骤
- ✅ 分配技术资源和时间规划
- ✅ 必须关联到对应Story（明确解决哪个用户问题）
- ❌ 不重新定义用户需求
- ❌ 不改变Story的验收标准
```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红绿重构
持续集成验证
自动化部署
跨技能协作
专业分工模式
功能团队模式
全栈协调模式
进度跟踪
每日站会更新
看板状态管理
燃尽图监控
```
#### 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小时
```
2. **Task定义强制要求**
- 必须有明确负责人
- 必须有具体验收标准
- 必须有清晰任务描述
- 必须评估技术风险
- **必须关联到对应Story**（除非是独立维护任务）
3. **Task-Story关联强制要求**
- 每个开发Task必须关联到具体Story
- 在项目管理工具中正确设置story_id字段
- Task验收标准必须支撑Story验收标准
- Task完成状态必须反映Story进度
- 独立Task（如环境维护、技术债务）可例外
4. **依赖管理强制要求**
- 识别所有前置依赖
- 标明阻塞影响关系
- 提供解耦替代方案
- 建立风险预警机制
5. **进度跟踪强制要求**
- 每日更新Task状态
- 及时反馈阻塞问题
- 记录实际工时偏差
- 定期回顾改进估算
2. **技术环境约束**
- 开发环境资源限制
- 第三方服务依赖
- 网络和硬件限制
- 工具和平台限制
3. **时间盒约束**
- Sprint时间限制
- 里程碑交付要求
- 发布窗口限制
- 客户期望时间
4. **质量约束**
- 代码覆盖率要求
- 性能指标要求
- 安全合规要求
- 用户体验标准