task-decomposition

任务拆解诊断

将令人望而生畏的开发任务拆解为可管理的单元，尊重认知限制、划定清晰边界，并支持并行工作。经过合理拆解的任务，完成率可提高 3 倍，缺陷数量可减少 60%。

何时使用此技能

在以下情况下使用此技能：

• 任务大到难以估算
• 不确定从何处开始
• 受依赖项阻塞
• 任务范围不断扩大（范围蔓延）
• 需要拆解大型任务或功能

在以下情况下不要使用此技能：

• 任务已经很小且清晰
• 正在进行实现工作
• 需要做出架构决策（使用 system-design）

核心原则

目标不是增加任务数量，而是拆解出合适的任务。 任务要小到可以完全理解，大到可以交付价值，并且足够独立，避免互相阻塞。

快速参考：认知限制

限制	阈值	影响
工作记忆	7±2 项	每项任务最多涉及的概念数
上下文切换恢复时间	23 分钟	尽量减少任务切换
检查的文件数	最多 15-20 个	限定任务范围
完成率开始下降前的天数	2-3 天	将任务控制在此时长以内

任务时长与成功率

时长	完成率
< 2 小时	95%
2-4 小时	90%
4-8 小时（1 天）	80%
2-3 天	60%
1 周	35%
> 2 周	<10%

诊断状态

TD1：大到难以理解

症状： 估算结果相差悬殊、无法记住所有需求、需要跟踪的概念超过 7 个

应对措施：

• 应用 INVEST 标准：独立、可协商、有价值、可估算、小型、可测试
• 采用纵向切片（每个切片都可以独立部署）
• 采用行走骨架（先构建最小端到端版本）

TD2：没有明确的切入点

症状： 有多个合理的起点、无从下手、感觉所有内容都相互关联

应对措施：

• 优先处理风险：从不确定性最高的事项开始
• 示踪弹：构建最小化概念验证
• 找到行走骨架：贯穿所有层的最薄切片

TD3：依赖问题

症状： “被 X 阻塞”、菱形依赖、协调开销

应对措施：

• 接口契约：定义 API，实现时使用模拟对象
• 功能标志：独立部署，准备就绪后再启用
• 通过抽象分支：创建一层抽象，再替换实现

TD4：没有明确的完成标准

症状： 永远处于“快完成了”的状态、无法验证是否完成

应对措施：

• 定义验收标准（Given/When/Then）
• 设定时间限制以推动优先级排序
• 明确列出不在范围内的事项

TD5：范围蔓延

症状： 任务不断扩大、不断出现“既然我们在这里，不如……”之类的追加内容

应对措施：

• 冻结范围，为追加内容新建任务
• 定义最小可行版本
• 发布能够解决问题的最小版本

TD6：需要先进行探索

症状： 估算差异 > 4 倍、涉及新技术、存在多种方案

应对措施：

• 设置时间限制的探索（最多 8 小时）
• 交付物：方案、POC、权衡分析、修订后的估算
• 采用先探索再实现的模式

拆解模式

纵向切片（功能的首选方式）

Feature: User Profile Management

Slice 1: View basic profile (4h)
  - UI: Profile display
  - API: GET /profile
  - DB: Read profile

Slice 2: Edit profile name (6h)
  - UI: Edit dialog
  - API: PATCH /profile/name
  - DB: Update profile

Each slice is independently deployable

行走骨架（适用于新系统）

Minimal end-to-end first:
1. Hello World page
2. One GET endpoint
3. Single table
4. Basic deploy

Then flesh out incrementally

示踪弹（用于验证架构）

Step 1: Minimal Service A (1h) - Hardcoded response
Step 2: Minimal Service B (1h) - Simple transformation
Step 3: Integrate (2h) - Prove they communicate

Total: 4 hours to decision point

估算技巧

复杂度评估（斐波那契数列）

点数	含义
1	微不足道，< 1 小时
2	简单，1-2 小时
3	标准，2-4 小时
5	中等，4-8 小时
8	复杂，1-2 天
13	非常复杂，2-3 天
21	太大，必须拆解

三点估算

O = Optimistic (everything perfect)
L = Likely (normal case)
P = Pessimistic (major issues)

PERT estimate: (O + 4L + P) / 6

反模式

一次性大爆炸式交付

在交付任何内容之前，先构建完整系统。 修正方法： 采用纵向切片，逐步交付价值。

没有价值的技术任务

“搭建数据库”、“创建服务层”。 修正方法： 将其纳入功能任务：“用户可以查看产品（包含数据库）。”

无限期研究

没有明确期限的调查。 修正方法： 设置时间限制，并明确交付物的探索。

完美分解

开始前过度分析。 **解决方法：**分解未来 2 周的工作。后续工作的细节会逐渐显现。

分解检查清单

开始任何任务前：

• 能否在工作记忆中容纳所有要求？
• 持续时间是否少于 2–3 天？
• 是否有明确的验收标准？
• 是否已识别依赖项，并尽可能打破依赖？
• 能否独立完成？
• 是否能交付可验证的价值？
• 估算的把握是否很高？

如果任何一项回答为“否” → 需要进一步分解。

相关技能

• github-agile - 将分解后的工作跟踪为议题
• system-design - 理解架构边界
• requirements-analysis - 澄清不明确的需求
• code-review - 实现后进行审查