用途
Task Decomposition 是一个任务拆解诊断技能,目标是把令人不知所措的开发任务转化为可管理的单元。它强调尊重认知极限、建立清晰边界、支持并行工作。资料称,经过恰当拆解的任务可获得 3 倍更高的完成率和 60% 更少的缺陷。
其核心理念是:目标不是产生更多任务,而是产生正确的任务——小到可以完全理解,大到足以交付价值,独立到足以避免阻塞。
何时使用
资料列出以下适用场景:
- 任务大到难以估算
- 不确定从哪里开始
- 被依赖关系阻塞
- 任务不断变大(范围蔓延)
- 需要拆分一个史诗(epic)或特性
以下情况不应使用:
- 任务已经足够小且清晰
- 正在做实现工作
- 需要做架构决策(应使用 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 标准(Independent 独立、Negotiable 可协商、Valuable 有价值、Estimable 可估算、Small 小、Testable 可测试);使用垂直切片(每个切片可独立部署);应用行走骨架(先做最小端到端)。
TD2:没有清晰入口 症状:存在多个有效起点、陷入瘫痪、一切似乎都相互关联。 干预:前置风险,从不确定性最高的项开始;使用曳光弹(最小概念验证);找到行走骨架,即贯穿所有层的最薄切片。
TD3:依赖问题 症状:“被 X 阻塞”、菱形依赖、协调开销大。 干预:接口契约,先定义 API,实现时用 mock;功能开关,独立部署、就绪后启用;通过抽象分支,创建一层再替换实现。
TD4:没有清晰的完成标准 症状:永远处于“快完成了”、无法验证是否完成。 干预:定义验收标准(Given/When/Then);用时间盒强制排优先级;明确列出范围之外的事项。
TD5:范围蔓延 症状:任务不断增长、“既然都到这儿了”式的追加。 干预:冻结范围,追加内容另开新任务;定义最小可行版本;交付能解决问题的最小版本。
TD6:需要先做技术验证(Spike) 症状:估算方差超过 4 倍、涉及新技术、存在多种方案。 干预:时间盒验证(最多 8 小时);交付物包括选项、概念验证、权衡与修订后的估算;采用先验证再实现的模式。
拆解模式
垂直切片(特性首选) 以“用户资料管理”为例:
- 切片 1:查看基本资料(4 小时)——UI 资料展示、API GET /profile、DB 读取资料
- 切片 2:编辑资料名称(6 小时)——UI 编辑对话框、API PATCH /profile/name、DB 更新资料
每个切片都可独立部署。
行走骨架(用于新系统) 先做最小端到端:1. Hello World 页面;2. 一个 GET 端点;3. 单张表;4. 基本部署。然后再逐步充实。
曳光弹(验证架构)
- 步骤 1:最小服务 A(1 小时)——硬编码响应
- 步骤 2:最小服务 B(1 小时)——简单转换
- 步骤 3:集成(2 小时)——证明二者可通信
总计 4 小时到达决策点。
估算技术
复杂度规模(斐波那契)
- 1:琐碎,小于 1 小时
- 2:简单,1-2 小时
- 3:标准,2-4 小时
- 5:中等,4-8 小时
- 8:复杂,1-2 天
- 13:非常复杂,2-3 天
- 21:过大,必须拆解
三点估算 O = 乐观(一切完美)、L = 可能(正常情况)、P = 悲观(出现重大问题)。 PERT 估算:(O + 4L + P) / 6
反模式
- 大爆炸式交付:在没有任何交付前构建完整系统。修正:垂直切片、增量价值。
- 没有价值的技术任务:“搭建数据库”“创建服务层”。修正:并入特性任务,如“用户可查看商品(含数据库)”。
- 无限研究:无边界调查。修正:带交付物的时间盒验证。
- 完美拆解:开始前过度分析。修正:只拆解未来两周,后续细节会自然浮现。
拆解检查清单
开始任何任务前:
- 能否在工作记忆中保持全部需求?
- 时长是否在 2-3 天以内?
- 是否存在清晰的验收标准?
- 依赖是否已识别并尽可能打破?
- 能否独立完成?
- 是否交付可验证的价值?
- 估算信心是否高?
任何一项为“否”,就需要进一步拆解。
相关技能
- github-agile:把拆解后的工作作为 issue 跟踪
- system-design:理解架构边界
- requirements-analysis:澄清不清晰的需求
- code-review:实现后评审
限制
资料未提供该技能的具体安装方式、支持平台、收费模式或价格信息,这些内容暂未提供。