把需求拆成可执行任务
你将学会什么
Section titled “你将学会什么”- 说出「按用户路径拆」和「按技术模块拆」的区别
- 用四个问题生成一份任务清单
- 让拆出的任务天然形成可演示的版本
有了最小目标之后，下一步是把需求拆成任务。学生项目里最实用的拆解方式是按用户路径拆。你可以先列出用户会经历的步骤：
- 打开项目后第一眼看到什么
- 需要完成什么操作才能拿到核心结果
- 出现错误时用户会看到什么
- 项目结束后用户能带走什么
以「课程笔记分享站」为例，按用户路径拆出来是这样的：
1. 用户打开页面，看到简介与笔记列表2. 用户搜索或筛选笔记，看到结果3. 用户打开一篇笔记，看到正文与作者信息4. 用户输入为空或网络失败时，看到错误提示5. 用户关闭后再次打开，还能看到最近浏览记录按这个顺序拆出来的任务，通常更容易形成可演示的版本——每完成一步，就多了一段能讲给同学听、能截图放进作品集的进展。而按技术模块拆（数据库、路由、组件……）很容易拆出一堆「看不见进度」的任务。
为什么按用户路径拆？
Section titled “为什么按用户路径拆？”按用户路径拆的好处会在演示时再次体现：讲述顺序与任务顺序一一对应。演示时先讲「打开项目后看到什么」，再沿着用户的操作一步步往下走，听众的注意力会跟着路径移动。按技术模块拆出来的任务则相反，演示时你得在功能之间来回切换，讲述也会显得零散。
每条任务怎么才算合格？
Section titled “每条任务怎么才算合格？”每条任务都可以用一句话说清三件事：为谁做、做什么、对方因此得到什么。以「用户打开一篇笔记，看到正文与作者信息」为例：为访问者做，做的是展示笔记详情，访问者因此拿到正文与作者信息。哪一件说不清楚，这条任务很可能不在当前需求范围内。这种「为谁、做什么、得到什么」的写法与用户故事的核心思想一致，课程项目不需要完整格式，保留三要素即可。
任务粒度怎么检查？
Section titled “任务粒度怎么检查？”拆好后还要检查粒度。一条任务做完后没有任何可见变化，说明拆得还不够细；一条任务里包含多个可以独立演示的步骤，说明拆得太粗。合适的粒度是每完成一条，你都能指着项目说出新的进展。这种先有整体、再逐层细化的过程，与工作分解结构的思想一致，适合在动手练的任务清单上边拆边检查。
先自己回答，再看答案：
- 为什么按用户路径拆比按技术模块拆更实用？
- 四个拆解问题分别覆盖了用户经历的哪些环节？
- 拆出来的任务为什么要按顺序排优先级？
参考答案
- 用户路径天然对应可演示、可讲述的进展，技术模块拆容易产出「看不见进度」的任务。
- 进入、使用、出错、离开四个环节，覆盖用户与项目的完整接触过程。
- 优先级决定先做什么，能保证尽快出现一个可演示的最小版本。
- 拆需求按用户路径：进入、使用、出错、离开
- 每完成一条任务，就多一段可演示、可讲述的进展
- 任务排好优先级，尽快拼出最小演示版
- 什么是用户故事（Scrum.org）——介绍按「为谁、做什么、得到什么」组织需求的方法
- 工作分解结构（Work breakdown structure）——介绍把项目逐层拆成可交付单元的做法