第 5 章
核心技能：全栈项目实战
掌握从需求到交付的完整流程，理解Spec驱动开发的方法论，学会WBS分解和DoD定义，具备企业级项目管理和质量控制能力。
需求澄清方法论
需求澄清是项目成功的基础。通过系统化的方法，确保理解真实需求，避免返工和误解。
Reverse Interview技巧
Reverse Interview是一种主动提问的技巧，通过问"为什么"来挖掘真实需求：
问"为什么"而不是"是什么"
错误问法："你需要什么功能？"
正确问法："你为什么需要这个功能？解决了什么问题？"
通过问"为什么"，了解需求背后的真实动机和业务目标。
问"什么时候"和"谁"
- • 使用场景："什么时候会使用这个功能？使用频率如何？"
- • 目标用户："谁会使用这个功能？他们的技术水平如何？"
- • 使用环境："在什么环境下使用？有什么限制？"
问"如果...会怎样"
- • 边界情况："如果没有这个功能会怎样？"
- • 异常处理："如果数据异常会怎样？"
- • 扩展性："如果需求变化会怎样？"
用户故事编写
用户故事是需求的最小单元，包含角色、目标、价值三个要素：
用户故事模板：
作为 [角色]，
我希望 [目标]，
以便 [价值/原因]。
我希望 [目标]，
以便 [价值/原因]。
好的用户故事特征
- • 独立性：可以独立开发和测试
- • 可协商：可以讨论和调整
- • 有价值：对用户有实际价值
- • 可估算：可以估算开发时间
- • 小：可以在一个迭代中完成
- • 可测试：有明确的验收标准
验收标准
每个用户故事都应该有明确的验收标准，使用Given-When-Then格式：
Given: 用户已登录
When: 用户点击"创建任务"按钮
Then: 显示任务创建表单
And: 用户可以输入任务标题和描述
And: 用户可以保存任务
When: 用户点击"创建任务"按钮
Then: 显示任务创建表单
And: 用户可以输入任务标题和描述
And: 用户可以保存任务
需求优先级排序
MoSCoW方法
- • Must have：必须有，项目成功的关键功能
- • Should have：应该有，重要但不是关键
- • Could have：可以有，如果时间允许就做
- • Won't have：这次不做，可能以后做
价值-复杂度矩阵
根据功能的价值和复杂度，优先开发高价值、低复杂度的功能。
实战案例：电商平台需求澄清
初始需求
"我们需要一个购物车功能"
Reverse Interview过程
- Q: "为什么需要购物车？" A: "用户需要能够同时选择多个商品"
- Q: "什么时候使用？" A: "浏览商品时，看到喜欢的就加入购物车"
- Q: "谁会使用？" A: "所有注册用户"
- Q: "如果用户未登录会怎样？" A: "可以加入购物车，但结账时需要登录"
澄清后的需求
- • 用户可以添加商品到购物车（登录/未登录）
- • 用户可以查看购物车中的商品
- • 用户可以修改商品数量
- • 用户可以删除商品
- • 未登录用户的购物车保存在本地存储
- • 登录后合并本地购物车和服务器购物车
Spec驱动开发
Spec驱动开发将需求转化为可执行的规范，AI可以直接根据Spec生成代码，提高开发效率和代码质量。
PRD编写
PRD结构
- • 产品概述：产品定位、目标用户、核心价值
- • 功能需求：详细的功能描述和用户故事
- • 非功能需求：性能、可用性、安全性、可扩展性
- • 用户界面：界面设计和交互流程
- • 数据模型：数据结构和关系
- • 验收标准：功能验收、性能验收、安全验收
PRD编写原则
- • 清晰明确：使用清晰的语言，避免歧义
- • 可执行：AI可以直接根据PRD生成代码
- • 可测试：每个需求都有明确的验收标准
- • 可追溯：需求可以追溯到业务目标
API Spec（OpenAPI规范）
OpenAPI规范的优势
- • 标准化：行业标准，工具支持完善
- • 可执行：AI可以直接根据OpenAPI生成代码
- • 可测试：可以自动生成API测试用例
- • 可文档化：自动生成API文档
API Spec示例
openapi: 3.0.0
info:
title: Task Management API
version: 1.0.0
paths:
/api/tasks:
get:
summary: 获取任务列表
parameters:
- name: status
in: query
schema:
type: string
enum: [pending, in-progress, completed]
responses:
'200':
description: 成功
content:
application/json:
schema:
type: object
properties:
tasks:
type: array
items:
$ref: '#/components/schemas/Task'
post:
summary: 创建任务
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/CreateTaskRequest'
responses:
'201':
description: 创建成功
components:
schemas:
Task:
type: object
properties:
id:
type: string
title:
type: string
status:
type: string
enum: [pending, in-progress, completed]UI Spec
UI Spec内容
- • 页面布局：页面结构、组件位置
- • 组件设计：组件类型、样式、交互
- • 交互流程：用户操作流程、状态变化
- • 响应式设计：不同屏幕尺寸的适配
UI Spec编写技巧
- • 使用Figma或类似工具设计界面
- • 详细描述每个组件的状态和交互
- • 使用AI工具（如v0）根据描述生成代码
- • 提供设计规范和组件库
实战案例：从PRD到代码的完整流程
Step 1: 编写PRD
明确产品目标、功能需求、非功能需求
Step 2: 编写API Spec
使用OpenAPI规范定义API接口，AI可以根据Spec生成API代码
Step 3: 编写UI Spec
详细描述界面设计，使用v0等工具生成UI代码
Step 4: 使用Cursor生成代码
将PRD、API Spec、UI Spec提供给Cursor Agent，生成完整代码
Step 5: 测试和优化
根据Spec编写测试用例，验证功能是否符合Spec要求
WBS分解
WBS（Work Breakdown Structure）将大任务分解为可执行的小任务，明确任务之间的依赖关系，便于项目管理和进度跟踪。
任务拆分原则
粒度控制
- • 2-4小时原则：每个任务应该在2-4小时内完成
- • 可测试性：每个任务都有明确的验收标准
- • 独立性：任务之间尽量减少依赖
- • 可估算：可以准确估算完成时间
依赖关系
- • 识别依赖：明确任务之间的依赖关系
- • 关键路径：识别项目的关键路径，优先完成
- • 并行任务：识别可以并行执行的任务
- • 依赖管理：使用工具（如GitHub Projects）管理依赖
时间估算
三点估算法
估算公式：(乐观时间 + 4×最可能时间 + 悲观时间) / 6
示例：乐观2小时，最可能4小时，悲观8小时 → 估算 = (2 + 4×4 + 8) / 6 = 4.3小时
类比估算
参考类似任务的完成时间，结合当前任务的复杂度进行调整。
AI辅助估算
使用AI工具分析任务复杂度，结合历史数据估算时间。
资源分配
人员分配
- • 根据技能和经验分配任务
- • 考虑人员的工作负载
- • 确保关键任务有备份人员
工具分配
- • 确保有足够的开发工具和资源
- • 考虑工具的许可证和成本
- • 准备备用方案
时间分配
- • 考虑项目的截止日期
- • 预留缓冲时间应对风险
- • 平衡并行任务和串行任务
实战案例：WBS分解示例
1. 项目准备（4小时）
1.1 环境搭建（2小时）
1.2 项目初始化（2小时）
2. 数据库设计（6小时）
2.1 数据模型设计（3小时）
2.2 数据库表创建（2小时）
2.3 数据迁移脚本（1小时）
3. 后端API开发（16小时）
3.1 用户认证API（4小时，依赖2.1）
3.2 任务CRUD API（8小时，依赖2.1）
3.3 数据统计API（4小时，依赖2.1）
4. 前端UI开发（12小时）
4.1 登录页面（2小时）
4.2 任务列表页面（4小时，依赖3.2）
4.3 任务详情页面（3小时，依赖3.2）
4.4 数据统计页面（3小时，依赖3.3）
5. 测试与部署（8小时）
5.1 单元测试（4小时）
5.2 集成测试（2小时）
5.3 部署（2小时）
关键路径：1 → 2.1 → 3.2 → 4.2 → 5（总时长约34小时）
DoD定义
DoD（Definition of Done）定义了任务完成的标准，确保交付质量，避免"看起来完成但实际未完成"的情况。
质量标准
代码质量
- • 通过ESLint检查，无严重警告
- • 代码符合团队规范
- • 代码已通过代码审查
- • 无已知bug
测试覆盖
- • 单元测试覆盖率>80%
- • 关键功能有集成测试
- • 所有测试通过
- • 测试代码质量达标
文档完整
- • API文档完整
- • 代码注释充分
- • 用户手册更新
- • 变更日志更新
性能指标
- • 页面加载时间<2秒
- • API响应时间<500ms
- • 数据库查询优化
- • 无内存泄漏
验收标准
功能验收
- • 所有功能按Spec实现
- • 用户故事验收标准满足
- • 边界情况处理正确
- • 错误处理完善
性能验收
- • 性能指标达到要求
- • 负载测试通过
- • 压力测试通过
- • 性能监控正常
安全验收
- • 通过安全扫描
- • 无高危漏洞
- • 数据加密正确
- • 权限控制正确
实战案例：DoD检查清单
代码已提交到Git，通过CI/CD检查
代码已通过ESLint检查，无严重警告
单元测试覆盖率>80%，所有测试通过
代码已通过代码审查，审查意见已处理
功能已测试，符合验收标准
性能测试通过，指标达标
安全扫描通过，无高危漏洞
文档已更新，API文档和用户手册完整
已部署到测试环境，UAT通过
产品经理验收通过，可以发布
学习成果
完成本章后，你将：
- 1掌握需求澄清的方法论（Reverse Interview、用户故事、优先级排序），能够挖掘真实需求
- 2理解Spec驱动开发的工程实践，能够编写清晰的PRD、API Spec和UI Spec
- 3掌握WBS分解的方法，能够合理拆分任务、估算时间、分配资源
- 4理解DoD的质量标准，能够定义验收标准，确保交付质量
- 5具备企业级项目管理和质量控制能力，能够确保项目成功交付