更新.gitignore文件，新增对requirements/目录的忽略规则。更新产品负责人执行文档，调整角色名称，优化工作流程图，增加最佳实践和评估标准，提升文档的清晰度和指导性。更新产品负责人思维模式图谱，增强技术架构和简约性原则的描述。更新产品管理最佳实践，明确AI产品负责人的职责和决策框架，确保文档内容的准确性和实用性。
This commit is contained in:
sean
234
domain/scrum/execution/task-best-practice.execution.md
Normal file
234
domain/scrum/execution/task-best-practice.execution.md
Normal file
@ -0,0 +1,234 @@
|
||||
<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>
|
||||
Reference in New Issue
Block a user