Files
PromptX/domain/scrum/execution/task-best-practice.execution.md

234 lines
6.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<execution domain="project-management">
<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
```
### Task标准模板
```markdown
## T-{StoryID}-{序号}: {任务标题}
**基本信息**:
- 任务类型: [开发/测试/设计/部署]
- 负责人: [具体团队成员]
- 预估工时: [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定义强制要求**
- 必须有明确负责人
- 必须有具体验收标准
- 必须有清晰任务描述
- 必须评估技术风险
3. **依赖管理强制要求**
- 识别所有前置依赖
- 标明阻塞影响关系
- 提供解耦替代方案
- 建立风险预警机制
4. **进度跟踪强制要求**
- 每日更新Task状态
- 及时反馈阻塞问题
- 记录实际工时偏差
- 定期回顾改进估算
</rule>
<constraint>
1. **团队技能约束**
- 专业技能分工限制
- 学习曲线时间成本
- 人员可用时间限制
- 关键人员依赖风险
2. **技术环境约束**
- 开发环境资源限制
- 第三方服务依赖
- 网络和硬件限制
- 工具和平台限制
3. **时间盒约束**
- Sprint时间限制
- 里程碑交付要求
- 发布窗口限制
- 客户期望时间
4. **质量约束**
- 代码覆盖率要求
- 性能指标要求
- 安全合规要求
- 用户体验标准
</constraint>
<criteria>
| 评价维度 | 优秀标准 | 合格标准 | 不合格标准 |
|---------|---------|---------|-----------|
| 拆解粒度 | 1-16h工作量精准控制 | 基本符合大小要求 | 过大过小影响执行 |
| 任务定义 | 描述清晰标准具体 | 基本明确可执行 | 定义模糊难理解 |
| 依赖管理 | 依赖识别完整有预案 | 主要依赖已识别 | 依赖遗漏频繁阻塞 |
| 责任分工 | 责任明确负载均衡 | 基本分工合理 | 分工不明或负载失衡 |
| 估算准确性 | 估算偏差<20% | 估算偏差<50% | 估算偏差>50% |
| 跟踪及时性 | 实时状态更新 | 每日更新状态 | 状态更新滞后 |
| 协作效率 | 协作顺畅无等待 | 基本协作顺利 | 频繁等待阻塞 |
| 交付质量 | 一次性通过验收 | 少量修改后通过 | 多次返工修改 |
</criteria>
</execution>