规划极限编程

　　极限编程（XP）是一种经历过实践考验的轻量级软件开发方法学。制订计划是解决XP难题的关键一环，本书介绍了如何应用XP规划软件项目。本书通过27章的篇幅探讨了怎样为XP项目的软件开发制订计划并跟踪开发过程。第1章至第4章介绍了为什么需要制定项目计划以及计划的目的；第5章概括性论述了XP项目；之后的第6章至第9章介绍了XP项目需循的一些原则；第10章至第16章介绍了发布计划并讨论了发布计划的各项要素；第17章至第19章介绍了迭代计划；第20章至第26章介绍了其他有关XP项目规划的内容，最后一章提供了让XP计划更适合自己情况的策略。本书内容均来自于两位作者担任顾问和讲师的经验以及日益壮大的先期使用XP人员的经验。本书以讲故事的方式讲解枯燥的软件开发过程，实用性与可读性较强，语言轻松活泼，适合于软件开发人员、软件项目管理人员，以及所有想要了解XP的各界人士参考。

　　作者：MartinFowlerMartinFowler是一位独立咨询顾问，他运用对象技术解决企业问题已经超过十年。他的顾问领域包括健康管理、金融贸易，以及法人财务。他的客户包括Chrysler，Citibank，UKNationalHealthService，AndersenConsulting，NetscapeCommunications。此外Fowler也是objects、UML、patterns技术的一位合格讲师，他是《AnalysisPatterns》和《UMLDistilled》的作者。UML精粹：标准对象建模语言简明指南（第3版）（英文影印版）>>更多作品

第 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会作完全相同的事, 只要你熟悉了它的基本过程, 就会使其渐渐变得更加适合你自己的情况.