当开发任务大到无法估算或不知从何下手时…

适用于任务过大、无法估算、被依赖阻塞或范围不断膨胀时，对史诗/功能进行可执行的任务分解。

适用场景

解决思路

1. 先诊断任务属于哪种状态：TD1 大到无法理解、TD2 没有明确入口、TD3 依赖问题、TD4 没有完成标准、TD5 范围蔓延、TD6 需要先做 spike，再对症下药。
2. TD1（大到无法理解）：套用 INVEST 标准（Independent、Negotiable、Valuable、Estimable、Small、Testable），使用垂直切片（每片可独立部署），并先做 walking skeleton（最小端到端）。
3. TD2（没有明确入口）：前置风险，从不确定性最高的部分开始；用 tracer bullet 做最小概念验证；找到穿过所有层的最薄切片（walking skeleton）。
4. TD3（依赖问题）：定义接口契约，先定义 API 并在实现时用 mock；用 feature flags 独立部署、就绪后再启用；用 branch by abstraction 创建抽象层再替换实现。
5. TD4（没有完成标准）：用 Given/When/Then 定义验收标准；用时间盒强制排优先级；明确列出 out-of-scope 项。
6. TD5（范围蔓延）：冻结范围，新增内容另开任务；定义最小可行版本；交付能解决问题的最小版本。
7. TD6（需要先做 spike）：做时间盒 spike（最多 8 小时），交付物包括可选方案、POC、权衡分析和修正后的估算；采用先 spike 再实现的模式。
8. 用垂直切片拆分功能：例如用户资料管理拆成「查看基本资料（4h）：UI 展示 + GET /profile + 读库」和「编辑姓名（6h）：编辑弹窗 + PATCH /profile/name + 更新库」，每片可独立部署。
9. 对新系统用 walking skeleton：先做最小端到端（Hello World 页面、一个 GET 端点、单张表、基本部署），再逐步填充。
10. 用 tracer bullet 验证架构：最小服务 A（1h，硬编码响应）→ 最小服务 B（1h，简单转换）→ 集成（2h，证明能通信），4 小时到达决策点。
11. 用 Fibonacci 复杂度估算：1=琐碎<1h，2=简单 1-2h，3=标准 2-4h，5=中等 4-8h，8=复杂 1-2 天，13=很复杂 2-3 天，21=太大必须继续拆分。
12. 用三点估算：O=乐观、L=最可能、P=悲观，PERT 估算 = (O + 4L + P) / 6。
13. 遵守认知限制：每个任务概念数不超过 7±2，减少任务切换（上下文切换恢复约 23 分钟），检查文件数控制在 15-20 个以内，任务时长控制在 2-3 天内。
14. 参考时长成功率来定任务粒度：<2h 完成率 95%，2-4h 90%，4-8h 80%，2-3 天 60%，1 周 35%，>2 周 <10%。
15. 避免反模式：不要 big bang delivery（改用垂直切片增量交付）；不要纯技术任务无价值（把「建数据库」并入「用户能查看商品」这类功能任务）；不要无限研究（改为时间盒 spike 并交付成果）；不要追求完美分解（只拆未来 2 周，后续细节随工作浮现）。
16. 开始任务前过一遍检查清单：需求能否全部装进工作记忆？时长是否在 2-3 天内？是否有明确验收标准？依赖是否已识别并尽量打破？能否独立完成？是否交付可验证价值？估算信心是否高？任一为「否」就继续拆分。
17. 可与 github-agile 集成，把拆分后的工作作为 issue 跟踪。

适用边界 · 注意事项

• 任务本身已经足够小且清晰时。
• 正在做具体实现工作时。
• 需要做架构决策时（应改用 system-design）。