《规划极限编程》- Planning Extreme Programming - Kent Beck & Martin Fowler
基本信息
- 作者：Kent Beck（极限编程创始人之一）、Martin Fowler（著名软件工程师、作家）
- 出版社：Addison Wesley（2000年）
- 页数：104页
- 来源：/田浩然上传的资料/电子书/架构设计/
核心观点
极限编程（XP）的核心哲学是：规划不是一次性事件，而是贯穿项目生命周期、持续重新评估和纠偏的过程。本书聚焦XP中”规划”这一关键环节，提供了一套灵活且实用的项目管理方法，特别适合小团队面对模糊或快速变化的需求。
关键概念
1. 四个关键变量
- 成本（Cost）：预算限制
- 质量（Quality）：系统可靠性
- 时间（Time）：交付期限
- 范围（Scope）：功能范围
四个变量中只能固定三个，第四个会随变化而调整。质量是最难衡量的变量，所以通常成为牺牲品。
2. 用户故事（User Story）
- 需求的简洁描述，如：“作为[角色]，我想要[功能]，以便[价值]”
- 好的故事原则：独立、可协商、有价值、可估算、小粒度、可测试
- 故事必须可追溯（traceability）
3. 估算与迭代
- 理想时间（Ideal Time）：不含中断的纯工作时间
- 昨天的天气（Yesterday’s Weather）：用上一轮完成的实际工作量来估算下一轮
- 每轮迭代结束后重新评估，而非依赖初期预测
4. 发布规划（Release Planning）
- 根据业务价值和技术风险对故事排序
- 决定每轮迭代放多少故事
- 客户与开发团队共同参与规划会议
5. 迭代规划（Iteration Planning）
- 明确任务、分配责任
- 程序员自行认领任务并估算
- 每日站会跟踪进度
重要数据/结论
规划的核心原则
“规划不是为了预测未来，而是为了获得足够信息做出决策。“
应对恐惧
- 未承认的恐惧是所有软件项目失败的根本原因
- 明确客户和程序员的权利清单
- 鼓励透明沟通，消除信息不对称
可见图表的重要性
推荐使用的可视化图表：
- 验收测试定义与通过率
- 生产代码量 vs 测试代码量
- 集成次数
- Bug密度
- 故事进度
- 系统性能
“当图表完成使命后，就丢弃它。图表是强大工具，但太多会削弱目的。“
红牌警告（危险信号）
- 估算缺失
- 客户无法做决定
- Bug报告激增
- 未端到端测试
- 每日构建失败
- 客户未完成故事
实践建议
关于契约
- 外包合同：避免固定范围的合同，改用固定时间和成本的协商范围模式
- 内部开发：找到单一客户代表，或给每个客户分配预算进行内部协商
- 盒装软件：由产品经理作为单一声音，整合多方需求
团队变化应对
- 新成员加入：给1-2轮适应期，不预测 velocity 下降
- 成员离开：按20%比例下调下一轮预估
- 团队分裂扩展：先以一半团队产出试运行，再用昨天的天气校正
应对Bug的策略
- 非关键Bug：计入卡片，客户决定优先级
- 关键Bug：从当前计划中移除相应故事，显式权衡功能 vs 修复
- 生产支持团队：轮流担任，避免长期承担
可行动点
- 用”昨天的天气”替代精确估算——信任历史数据而非预测
- 建立可视化看板——让团队和客户都能看到真实进度
- 让客户参与迭代规划——确保业务价值优先
- 定期复盘——每轮迭代结束讨论流程改进
- 发现红牌立即减速——慢下来恢复控制，再加速
与其他知识关联
- 参见 敏捷开发最佳实践 — 与XP方法论高度契合
- 参见 ThoughtWorks文集-敏捷开发最佳实践精选 — 同一机构背景的实践总结
- 参见 Scrum敏捷软件开发 — 互补的敏捷框架
- 参见 设计模式精解 — 开发层面的配合实践
笔记要点
核心洞见：规划的本质不是预测，而是获得信息、减少不确定性、建立反馈循环。XP的规划方法强调透明、协作、持续调整，而非一次性完美计划。
适用场景：需求不明确、变化频繁的小型团队（<20人）。不适合强监管、大团队、需求固化的项目。
局限性：对客户参与度要求极高；对文档和合规性要求高的行业（如医疗、航空）需谨慎适配。