第 1章 为什么需要有计划？ 1
我们希望始终在做最重要的事情, 能很好地和其他人合作, 并且能快速地对意外事件作出反应.
第 2 章 担心 7
软件开发是有风险的, 有关人员非常担心什么可能会出错. 为了有效地进行开发, 我们必须承认这一事实（这些担心）.
第 3 章 控制软件开发 11
我们用开车来比喻开发软件. 开车不是简单地把车对准一个方向, 然后保持方向不变, 开车需要时不时地做些小调整.
第 4 章 平衡职权 13
我们的计划过程取决于能否明确地把业务人员和软件开发人员的作用区分开来. 这样确保由业务人员做出所有的业务决策, 由软件开发人员做出所有的技术决策.
第 5 章 概 述 19
XP过程不尽相同, 有的版本需要几个月的时间, 有的需要分为若干个为期两周的迭代, 有的需要分为若干个为期几天的任务. 计划能根据开发工作的实际情况, 把各个故事（功能集合）分配到不同的版本和迭代中.
第 6 章 任务太多 23
当你超负荷工作时, 不要想没有足够的时间, 而要想要做的事情太多. 你无法给自己更多时间, 但是你可以让自己少做一些, 至少目前如此.
第 7 章 四个变量 25
我们使用四个变量来帮助我们考虑如何控制一个项目：成本. 质量. 时间和范围. 它们互相联系, 但是以奇特的方式彼此影响.
第 8 章 昨天的天气 33
作为计划的基础, 假定你这周要做的工作同上周一样多.
第 9 章 划定项目的范围 37
若要快速知道项目的大小, 请对计划过程进行大致的分解.
第 10 章 发布计划 43
在发布计划过程中, 客户选择几个月的故事, 并且通常集中于公开发布的那部分.
第 11 章 编写故事 49
在XP项目中故事是功能的单位, 我们通过交付经过测试并集成的用于实现故事的代码来说明进度. 故事对于客户和开发人员应该是可以理解的. 可测试的. 对客户有价值的. 并且应足够小以便程序员可以在一次迭代中生成半打故事.
第 12 章 估 算 61
将故事估算建立在已完成的相似故事的基础之上, 该故事与可比故事花费的时间相同.
第 13 章 对故事进行排序 67
首先执行的最重要的故事是那些包含最高商业价值的故事, 注意在对故事进行排序时应以技术依赖关系为依据. 通常情况下, 依赖关系的重要性低于价值的重要性.
第 14 章 发布计划事件 75
各种事情的发生使得团队不得不制订一个小型的发布计划. 客户添加和更改故事的优先级, 开发人员对故事进行评估, 而团队则应注意要做的事情太多还是太少.
第 15 章 第一个计划 79
第一个计划是发布计划中最困难, 精确度最低的部分. 不过好在这样的计划只需制订一次.
第 16 章 发布计划变化 85
对发布计划做一些局部的变化就是较短发行周期. 较长发行周期和较短故事.
第 17 章 迭代计划 89
每次迭代都是通过将迭代的故事分解为任务来计划的. 任务是这样调度的：让程序员申请自己想要的任务, 再让他们评估自己的任务, 如有必要, 再重新衡量.
第 18 章 迭代计划会议 93
在迭代开始时, 团队创建迭代计划. 这个计划将迭代分解为几个数天的开发任务, 每个任务都有专门的程序员来负责.
第 19 章 跟踪迭代 103
跟踪者一周检查两次迭代的进度情况, 看看事情进行得如何.
第 20 章 站立会议 115
每天都开一个短会, 让每个人都知道哪些事情正在进行, 哪些还没有进行.
第 21章 可视图 117
任何人都可以通过查看关于团队工作内容的一些图表来了解项目所处的状态.
第 22 章 处理错误 123
将错误修复安排在故事中, 因此客户可在修复错误和添加更多功能之间进行选择.
第 23章 团队的变化 127
团队的改变将如何影响你的计划呢？
第 24 章 工 具 131
坚持使用简单工具, 如铅笔. 纸和白板. 对成功而言, 沟通比奇才更重要.
第 25 章 商业合同 133
如果你准备用XP来计划并执行一个项目, 就要对传统的商业合同稍加调整.
第 26章 危险信号 139
这里有一些我们不只一次见到并希望解决的危险情况.
第 27 章 你自己的过程 143
不要期望任意两个XP会作完全相同的事, 只要你熟悉了它的基本过程, 就会使其渐渐变得更加适合你自己的情况.
鄂公网安备 42010302001612号 