《敏捷估计与规划》一书为对敏捷项目进行估计与规划提供了权威实际的指导方针。在本书中，敏捷联盟的共同创始人Mike Cohn讨论了敏捷估计与规划的思想，并使用现实的例子与案例分析向您详细地展示了如何完成工作。本书清晰地阐述了有关的概念，并引导读者逐步认识到下列一些问题的答案：我们要构建什么？它的规模有多大？需要在什么时候完成？到那个时候我们到底能完成多少？您首先会认识到优秀的计划由哪些东西组成，接着会了解到如何才能使计划成为敏捷的。
《敏捷估计与规划》支持所有敏捷的、半敏捷的或迭代的开发过程，包括Scrum、极限编程、功能驱动的开发、Crystal开发、自适应软件开发、DSDM、统一过程以及许多其他开发方式。它将是每个开发经理、开发小组领导和开发小组成员不可或缺的宝贵资源。此书也获得了亚马逊网站“五星级”赞誉！

第Ⅰ部分 问题与目标
第1章 规划的目的
第2章 规划失败的原因
第3章 敏捷方法
第Ⅱ部分 规 模 估 计
第4章 使用故事点估计规模
第5章 使用理想日进行估计
第6章 估计方法
第7章 重估
第8章 在故事点和理想日之间进行选择
第Ⅲ部分 为价值作规划
第9章 确定主题的优先级
第10章 确定经济优先级
第11章 确定合意性优先级
第12章 分割用户故事
第IV部分 进 度 安 排
第13章 发布规划基础
第14章 迭代规划
第15章 选择迭代长度
第16章 估计速度

本书名差点被定为《估计与规划敏捷项目》。不过，最终确定的是《敏捷估计与规划》。两者的差异似乎微不足道，但实际上并非如此。现在的书名明确了估计和规划过程本身就应该是敏捷的。不采用敏捷估计和规划，就不可能有敏捷开发项目。.
本书的大部分是关于规划的，我把它看作是用来回答“我们要建立什么以及何时建立？”这一问题。但是，要回答关于规划的问题，我们还必须解决关于估计(“它有多大规模？”)和进度安排(“什么时候能完成？”和“到那时我能得到多少？”)的问题。
本书由7个部分共23章组成。每一章的结尾都有对重点的小结和一组讨论题。由于估计和规划应该是整个小组的工作，因此我希望对本书的阅读方式是小组成员每周聚在一起讨论一下看过的内容以及每章结尾的讨论题。由于敏捷软件开发在全世界都受到欢迎，所以我尽可能避免让本书显得过分以美国为中心。为了达到这一目的，我使用了一种通用的货币单位，将金额写作500“币”，而不是500美元或者500欧元。
本书的第I部分说明了规划为什么重要、我们常会遇到的问题，以及敏捷方法的目标。第1章是本书的起始，说明了规划的目的、一个优秀的计划由哪些部分组成，以及什么会使规划成为敏捷规划。第2章中说明了为什么传统估计和规划方法是导致难以令人满意结果的最重要原因。最后，第3章首先简要地重述了敏捷的含义，然后概括说明了本书其他部分在不同层次上所采取的敏捷估计和规划的方法。
本书的第II部分介绍了估计的一个主要原则，即对规模和时间长度的估计应该相互独立。第4和第5章介绍了两个适于对要开发的功能规模进行估计的计算单位：故事点和理想日。第6章说明了采用故事点和理想日进行估计的技巧，并包括了对规划扑克的介绍。第7章说明何时以及如何进行重估。第8章则提供了有关如何在故事点和理想日间进行选择的建议。..
第III部分“为价值进行规划”提供的建议告诉项目小组如何确认他们正在构建尽可能好的产品。第9章介绍了在为功能确定优先级时需要综合考虑的一些因素。第10章展示了对功能或功能集的经济回报进行建模的一种方法，以及如何对经济回报进行比较以便开发小组首先处理最具价值的特性。第11章主要讲述有关如何评估产品用户对各个功能的需求程度并确定其优先级的建议。第12章对本部分进行总结，给出一些建议，帮助将大的功能分解成更小的、更易管理的功能。
在第IV部分中，我们将重点转移到了有关安排项目时间进度的方面。第13章首先讨论对一个相对简单的、单开发小组的项目进行编排时所涉及的步骤。接下来，第14章讨论如何规划一个迭代周期。第15章和第16章讨论如何选择合适的迭代周期长度以及如何估计开发小组的初始进度率。第17章详述如何安排一个具有很高不确定性的，或是在时间进度上很可能出错的项目的进度表。第18章是这一部分的结尾，说明了对由多个小组共同开发的项目进行估计和规划所必需的其他步骤。
一旦建立了计划，就必须和整个公司的其他部门进行交流，并根据计划进度对开发小组的进度进行监督。这是第V部分的3章的主要内容。第19章主要关注对发布计划进行监督，而第20章关注对迭代计划进行监督。这一部分的最后一章，第21章主要解决如何就计划及其进度进行沟通。
第22章是第VI部分唯一的一章。这一章与第2章说明的为什么传统方法会失败相对照，讨论了为什么敏捷估计和规划方法会有效。
第VII部分是全书的最后一部分，也只有一章。第23章是一个扩展的案例分析，在一个假想的背景中重述了本书的重点。...

序1
在首次阅读一本书或者手稿的时候，我总会问自己同一个问题：“作者为这一主题的发展现状增添了哪些内容？”对Mike的这本书，答案有两个方面：他的书增加了我们关于“如何”进行估计和规划的知识，它还增加了我们关于“为什么”特定的实践很重要的知识。
敏捷规划是具有欺骗性的。在某个层面上，它相当容易—— 建立一些故事卡片，确定它们的优先级，把它们分配进不同的发布迭代周期，然后添加其他的细节来获得下一轮的迭代计划。您花几个小时就可以让一个小组学会规划的基本内容，然后他们再花几个小时就可以(对一个小项目)提出一个可被接受的计划。Mike的书可以在很大程度上帮助小组从制订可被接受的计划转变成制订优秀的计划。在这里，我的用词是非常谨慎的—— 我并没有说完美的计划，因为正如Mike在本书中指出的，在一个(足够)优秀的计划和一个完美的计划之间的差异可能抵不上为之所须付出的精力。.
关于Mike的这本书，我早期的想法和敏捷规划本身的概念有关。我常常因为缺乏对敏捷规划的理解而感到困惑或者是悲哀。我们常听到一些批评，例如“敏捷项目开发小组不做计划”，或者是“敏捷开发小组不会对日期和功能做出承诺”。甚至Balancing Agility and Discipline: A Guide for the Perplexed(Addison-Wesley出版社2004年出版)一书的作者Barry Boehm和Richard Turner在他们的书中讨论“计划驱动对敏捷方法”时也弄错了。实际上，Boehm和Turner的观点是对的，但是措词不当。他们使用计划驱动来表示“更看重对预测的平衡而不是对预测的调整适应”，而敏捷方法意味着相反的做法。他们的问题在于“计划驱动”对“敏捷”这一比对传递了完全错误的信息—— 敏捷开发小组不做规划。这一理解实际上是完全错误的。Mike这本书传递了正确的信息—— 规划对任何敏捷开发项目都是不可缺少的组成部分。 本书中有大量的关于规划为什么如此重要以及如何有效进行规划的看法。
首先，敏捷开发小组会进行大量的规划活动，但这些活动被更为均衡地分布于项目的整个开发过程。其次，敏捷开发小组会直接面对不确定性这一被许多非敏捷开发小组所忽视的关键因素。规划重要吗？—— 当然重要。随着知识的获取和不确定性的降低调整计划重要吗？—— 当然重要。我看到过太多的公司，一开始做出许多不切实际的早期承诺然后又无法实现它们，被看作是可被接受的；而那些试图做出更为现实承诺(充分理解不确定性的影响)的人，则被看作“不能适应需要”，或“缺乏团队精神”。在这些公司中，似乎无法交付是可被接受的，而不能承诺(即使是对不切实际的目标)则是不可接受的。就像Mike巧妙指出的那样，敏捷开发方法强调实际交付价值而不是做出一些非凡的但是无法实现的计划和承诺。敏捷开发人员通常会说，我们会给您一个基于当前所了解的内容做出的计划；我们会随着开发过程中获得的新信息对项目和计划做出调整；我们希望您能够理解您所要求的两个目标—— 获得适应变化的应用环境的灵活性，与绝对地遵守原始计划—— 是相互矛盾的。《敏捷估计与规划》这本书对以上的每个论断都进行了说明。
让我们回到对不确定性进行管理这一关键问题上。Mike完成了一项伟大的工作，分析了敏捷开发过程如何同时减少目标不确定性(我们到底要构建什么)和方法不确定性(我们如何构建它)。许多传统的规划人员没有理解一个关键概念—— 不确定性是不能被“规划”的。计划是基于我们在某个特定时间点上所知道的东西做出的，而不确定性则是对我们所不知道的事情—— 对目标或者方法—— 的另一种表述。对大部分不确定性(缺乏知识)而言，获取知识、减少不确定性的唯一办法是通过执行—— 做一些事情、构建一些东西或是模拟一些东西—— 然后获得反馈。许多项目管理方法是“规划、规划、规划－执行”。而敏捷开发方法是“规划－执行－调整”、“规划－执行－调整”。一个项目的不确定性越高，敏捷开发方法对取得成功就越是至关重要。
我喜欢用Mike书中的第4章和第5章来说明有关“如何做”和“为什么做”的问题。这两章详细阐述了如何估计故事点和理想日，并对两者的优缺点分别进行了解释。虽然这两种方法我都和客户一起使用过，但Mike的话让我对估计故事点的优点认识得更为清晰。我认识到故事点是朝向简单性的进化的一部分。软件开发公司长期以来都在寻求“这个软件规模有多大”这一问题的答案。建筑师可以根据平方尺度对建筑工程做出合理的估计。不同建筑师做出的估计可能有所差异，但规模的大小是固定的(虽然收尾工作、材料特性和其他一些因素可能影响到估计结果)，保持不变。软件开发人员一直希望也能找到一个这样的度量方法。
在软件开发中，我们最初使用代码行(line-of-code)来度量产品的规模(这一方法当前仍在一定程度上被使用)。对大部分日常规划来说，有一些原因导致代码行的用途有限，其中之一就是由于对其进行估计时所须进行的先期工作太多。接下来就是功能点(function point)方法(以及一些类似的思路)。虽然功能点消除了代码行方法的一些问题，但是其计算仍然需要相当数量的先期工作(您需要对输入、输出和文件等进行估计)。功能点方法的复杂性不可避免地影响了对它的广泛应用。我的看法是随着计算方法复杂程度的上升—— 只要观察一下国际功能点用户组(International Function Point User Group，IFPUG)网站就可以了解到它有多复杂—— 普通人对它的使用就会减少。
然而，对软件项目规模进行估计的需求却从未消失。这两种曾经被采用的度量方法存在两个问题—— 它们的计算过于复杂，而且都是基于瀑布式的开发方法。我们仍然需要一种规模度量方法，我们需要一种易于计算，而且不必完成所有需求分析和设计阶段就可以实现的度量方法。
故事点方法与代码行或功能点方法的两个关键不同之处在于它更容易计算而且可以更早计算。为什么更容易计算？因为它是基于相对规模而不是绝对规模。为什么可以更早计算？因为它是基于相对规模而不是绝对规模。就像Mike指出的那样，进行故事点估计只需要大家坐在一起讨论用户故事(获取共同知识)，推测相对的故事规模。与对绝对规模进行估计相比，对相对规模进行估计要快得多。此外，经过几次规模估计和交付的迭代后，一个小组的估计准确性会显著提高。Mike对故事点和理想日估计方法的“如何”和“为什么”的说明提供了对这一主题敏锐而深刻的理解。
第9章和第11章是体现Mike对这一问题理解的透彻性的另一表现。这两章是关于确定用户故事的优先级的。Mike不满足于只告诉我们首先处理具有最高价值的用户故事，事实上他钻研了价值的各个关键因素：经济收益、代价、创新/知识，以及风险。他对价值的这些方面进行了仔细的定义(甚至包括了一个关于净现值(Net Present Value)、内部回报率(Internal Rate of Return)和其他金融分析工具的初级读本)，然后提供了使用这些价值因素对决策进行衡量的不同方案，每个方案分别具有不同的简单性。
刚接触敏捷开发的人往往认为如果遵循了特定方法学的12个、19个或8个实践方法，那么就是在采用敏捷开发、极限开发、Crystal Clear开发，或者是别的什么开发方法。但实际上，只有在充分了解这些实践方法并能根据您所处的特定环境调整它们的时候，才是真正采用敏捷开发、极限开发或者别的开发方法。不断地学习和调整是敏捷开发的核心。Mike在本书中做得最好的就是为我们提供了许多看法和经验，来帮助我们的敏捷估计和规划的实践达到这一更高的层次。Mike深入地告诉我们“如何做”—— 例如那些有关故事点和理想日估计的材料。Mike深入地告诉我们“为什么做”—— 例如那些关于故事点和理想日估计的优缺点。虽然他通常给我们一些个人的建议(他更倾向于故事点)，他也为我们提供了足够的信息，让我们可以自信地对各种实践方法进行裁剪以适应特定的环境需要。
所以，最后，Mike对此方面技术发展所做出的显著贡献在于—— 他帮助我们在一个新的知识和经验深度上对估计和规划进行思考(如何做)，然后帮助我们决策如何利用这些新的知识来调整实践方式以适应新的、独特的或者仅仅是特定的环境(为什么做)。在我通常会推荐给客户的6本书中，有2本是Mike写的。对于那些希望了解敏捷项目管理在此方面发展现状的人，本书是我推荐给他们列的“必读”书目。
Jim Highsmith
Cutter Consortium公司敏捷业务主管..
2005年8月于Arizona Flagstaff

序2
“除了一些小型项目以外，敏捷开发在Yahoo！公司根本就行不通，原因是那样的话开发小组就不会做任何计划，小组成员也无法对自己的工作进行估计。需要有人告诉他们应该做些什么。”
这是人们的原话，从我在Yahoo！公司开始指导采用敏捷开发方法以来就反复听到这样的话。那些不理解敏捷开发概念的人认为敏捷开发不过是消灭掉所有的文档和规划，让开发小组到处乱逛的许可。事实与真相的距离不会比这种看法更远(译者注：即这种看法并非事实真相)。