敏捷软件开发（原书第2版） (2009 年度畅销榜NO.42399 )

本书提示了敏捷软件开发的真正内涵。全书以“软件是创造和沟通的合作博弈”为中心向读者展示一个看待软件开发的崭新视角。全书共13章，包括创造和沟通的合作博弈、个人、团队的沟通与合作、方法集、敏捷与自适应、以及Crystal方法集等内容。
本书适合软件开发人员、管理人员、架构师等技术人员参考。

译者序
第2版前言
第2版前言
第0章 不可知和不可说
0.1 和解析体验相关的问题
0.1.1 解析模式的冲突
0.1.2 检测解析模式
0.1.3 思考不准确的思想
0.2 沟通的不可能性
0.2.1 内部重新组织
0.2.2 触及共享体验
0.2.3 管理不完美的沟通
0.3 聆听的三个层次
0.3.1 三个层次和方法集
0.3.2 三个层次与本书
0.3.3 守-破-离
0.4 那么，明天我做什么
第0A章 不可知和不可说：演进
0A.1 沟通和共享的体验
0A.2 守-破-离
第1章 创造和沟通的合作博弈
1.1 软件和诗歌
1.2 软件与博弈
1.2.1 博弈的类型
1.2.2 软件与攀岩
1.2.3 创造和沟通的博弈
1.2.4 软件与工程化
1.2.5 软件与模型构建
1.3 再论合作博弈
1.3.1 程序员成为沟通专家
1.3.2 更快地博弈
1.3.3 标识物和道具
1.3.4 减少回报
1.3.5 对于首要目标的充分度
1.3.6 对于积淀的充分度
1.3.7 博弈中的博弈
1.3.8 开放源码开发
1.4 这对我意味着什么
第1A章 创造和沟通的合作博弈：演进
1A.1 沼泽游戏
1A.2 合作中的竞争
1A.3 其他领域的合作博弈
1A.4 软件工程的重建
1A.4.1 这一词汇从哪里来
1A.4.2 我们从哪里走错了
1A.4.3 重建软件工程 Craft
1A.4.4 技艺
1A.4.5 合作博弈
1A.4.6 精益制造
1A.4.7 重建后的软件工程
1A.4.8 其他工程化中的协作
第2章 个人
2.1 人是古怪的
2.1.1 寻找特征函数
2.1.2 古怪性格的元素
2.1.3 不可避免的多样性
2.1.4 技术的作用
2.1.5 相互冲突的共同点
2.2 克服失败模式
2.2.1 犯错误
2.2.2 宁可失败也要选择保守
2.2.3 创新而不研究
2.2.4 不能始终如一的习惯动物
2.2.5 使用纪律和容忍来应对
2.3 以一些更好的方式工作
2.3.1 具体化
2.3.2 实物
2.3.3 在某些东西的基础上进行修改
2.3.4 观察和聆听
2.3.5 支持专注和沟通
2.3.6 工作分配要与个性相匹配
2.3.7 天赋
2.3.8 奖励要能保留乐趣
2.3.9 组合奖励
2.3.10 反馈
2.4 利用成功模式
2.4.1 善于四处寻找
2.4.2 人们学习
2.4.3 可塑性
2.4.4 贡献和采取主动
2.4.5 组合成功模式
2.4.6 英雄也是普通人
2.5 明天我该做什么
第3章 团队的沟通与合作
3.1 信息的对流
3.1.1 延迟和机会损失成本
3.1.2 尔格-秒
3.1.3 渗透式沟通
3.1.4 穿堂风
3.1.5 信息辐射源
3.1.6 热空气理论的应用
3.2 跨越沟通的鸿沟
3.2.1 沟通的形态
3.2.2 去掉某些形态所产生的影响
3.2.3 利用各种形态
3.2.4 粘度与跨越空间的鸿沟
3.3 团队就是集体
3.3.1 友善和冲突
3.3.2 工作时间的公民意识
3.3.3 敌意的XP与友善的XP
3.3.4 使用胜利来建立“团队”
3.3.5 团队文化与亚文化
3.4 团队就是生态系统
3.5 我明天该做什么
第3A章 团队：演进
3A.1 一个修订后的办公室布局样本
第4章 方法集
4.1 一个交付软件的生态系统
4.2 方法集中的概念
4.2.1 结构术语
4.2.2 范围
4.2.3 概念术语
4.2.4 发布一个方法集
4.3 方法集的设计原则
4.3.1 常见设计错误
4.3.2 在方法集上成功的项目
4.3.3 与作者的相关性
4.3.4 七条原则
4.4 细看XP
4.4.1 XP简介
4.4.2 剖析XP
4.4.3 调整XP
4.5 到底为什么使用方法集
4.5.1 方法集解决什么问题
4.5.2 如何评估一个方法集
4.6 明天我应该做什么？
第4A章 方法集：演进
4A.1 方法集与策略
4A.2 组织级的方法集
4A.3 过程就是循环
4A.4 更简单地描述方法集
第5章 敏捷与自适应
5.1 轻但足够
5.2 敏捷
5.2.1 最佳击球点
5.2.2 虚拟团队的麻烦
5.3 变得自适应
5.3.1 不胜其烦地进行反思
5.3.2 方法集成长技术
5.3.3 反思研讨会技术
5.4 明天我该做什么
第5A章 敏捷与自适应：演进
5A.1 对于寓意的误解
5A.1.1 “迭代必须简短”
5A.1.2 “敏捷团队必须驻扎在一起”
5A.1.3 “敏捷团队不需要计划”
5A.1.4 “架构已死；重构是你全部所 需要的” 5A.1.5 “我们不需要什么什么经理！” 5A.1.6 “敏捷开发在纪律上要求很低” 5A.1.7 “敏捷只适合最优秀的开发人员” 5A.1.8 “敏捷中既老又新的、失败的、 没有尝试过的“
5A.2 敏捷方法集的演进
5A.2.1 XP第二版
5A.2.2 Scrum
5A.2.3 实用主义和无名的
5A.2.4 可预测、计划驱动和其他中心 调整 5A.2.5 约束理论
5A.2.6 精益开发
5A.3 新的方法集话题
5A.3.1 敏捷项目管理
5A.3.2 测试
5A.3.3 用户体验设计
5A.3.4 规划管控、burn图和系统工程
5A.3.5 用例和用户故事
5A.4 经久不绝的问题
5A.4.1 最佳击球点和下降
5A.4.2 固定价格、固定范围的合同
5A.4.3 敏捷、CMMI和ISO9001
5A.4.4 何时停止建模（重复）
5A.4.5 高科技/高接触的工具箱
5A.4.6 敏捷的中心
5A.4.7 你有多敏捷
5A.4.8 引入敏捷
5A.5 软件开发之外的敏捷
5A.5.1 项目组合管理
5A.5.2 客户关系
5A.5.3 合同
5A.5.4 将变更引入组织
5A.5.5 程序员读哈佛商业周刊
5A.5.6 建造房屋
5A.5.7 机场建设
5A.5.8 图书出版
5A.5.9 会议组织和敏捷模型的限制
第6章 Crystal方法集
6.1 对Crystal家族塑形 Core Crystal Elements
6.1.1 核心Crystal元素
6.2 Crystal Clear
6.2.1 Crystal Clear的简要描述
6.2.2 Crystal Clear的反思
6.3 Crystal Orange
6.3.1 Crystal Orange的简要描述
6.3.2 Crystal Orange的反思
6.4 Crystal Orange Web
6.4.1 Crystal Orange Web的简要描述
6.4.2 Crystal Orange Web的反思
6.5 明天我该做什么
第6.1章 Crystal方法集：演进
6A.1 Crystal基因代码
6A.1.1 合作博弈的理念
6A.1.2 方法集的重点
6A.1.3 方法集设计原则
6A.1.4 高度成功的项目的7个特性
6A.1.5 技术与选择
6A.1.6 样本方法集设计
6A.2 Crystal Clear
6A.3 把Crystal Clear扩展到Yellow
附录A 敏捷软件开发宣言
附录Aa 敏捷软件开发宣言和相互依赖 声明 附录B Naur、Ehn、宫本武藏
附录Ba Naur、Ehn、宫本武藏：演进
附录C 后记 参考文献

作为《敏捷软件开发宣言》和《相互依赖声明》的合著者，Alistair Cockburn的这本书揭示了敏捷的真正内涵。 “软件是创造和沟通的合作博弈”，这一隐喻向我们展示了一个看待软件开发的崭新视角，它告诉我们：软件开发的首要目标是交付有用、可工作的软件，次要目标是为下一轮博弈做好准备。因为“编程就是构建理论”，而“理论”中的大部分意会知识不能或很难用文档来传达，而要靠沟通来传达，所以提高信息沟通的效率就提高软件开发效率的最有效的方式。 人不是生产线上的智能机器，人的特点是：人在沟通、学习和解决问题方面都不同于智能机器。以管理生产设备的方式管理人，显然不能最大程度地发挥人的潜能。 软件开发团队是一个交付软件的生态系统。团队的成功依赖于合作、沟通和协调。方法集就是你的团队同意遵循的那些协约。不同的协约适合不同类型的项目，没有放之四海皆适用的方法集，设计方法集时要“针对情形而制定策略”。 敏捷意味着有效率并且灵活机动。敏捷的过程既轻量又充足，轻量使它机动灵活，充足使它能够继续进行博弈。要不厌其烦地进行反思，才能使方法集自适应。 本书在论述敏捷软件开发的同时，还详细讲解了如何在团队内跨越沟通鸿沟交流信息，如何建设团队；以及方法集设计的常见错误和设计原则，敏捷的最佳击球点，在运行中构建和优化方法集，反思研讨会等内容。本书还详细讲解了XP和Crystal家族等敏捷方法集。 在书中，作者不仅把敏捷的思想推广到软件开发之外的领域，而且还深入地分析了对于敏捷的常见误解，全面回顾了各种敏捷方法集和理论的最新发展，并介绍了组织级敏捷方法集的设计，以及“最佳击球点和下降”、“敏捷与CMMI和ISO9001”等由来已久的问题。 本书的内容深厚宽广，论述每个问题时都提供了生动的例子或案例。本书的附录也不应被读者忽略，其中的《敏捷宣言》、《相互依赖声明》，还有宫本武藏的《五轮书》片段，都能很好地帮助读者理解敏捷、理解本书的内容。 感谢机械工业出版社华章公司的编辑一直以来对我们的翻译工作的支持和鼓励。能够翻译这样一本荣获Jolt大奖的书籍，是译者的荣幸。翻译本书的过程同时也是一个学习和提高的过程。 参加本书翻译的还有尚计升、史红伟、祝国志、张峰峰、张文军、张艳军、王小财和周宝华张勇、杜兴平、刘志飞、沈海峰、谢扣林、乔义峰、刘查强、王义强、刘国际、杨传辉、王建华、汪明军、朱兆涛、毛付安。由于时间仓促，译者水平有限，翻译的错误和不妥之处在所难免，欢迎广大读者批评指正。 译者于北京 2007年10月

2001年，软件开发的敏捷模型给世界带来了一场风暴。一年中，全世界出现了很多关于敏捷的著作和会议。在5年中，它影响了每一件事，从项目管理和公司经理们如何编写与客户的合同，到军事采购的过程，甚至到大学的课程。 是该看一下都发生了什么变化的时候了，看一下我们能从敏捷模型和（更具普遍意义的）合作博弈中学到什么。 在2001年2月写《敏捷软件开发的宣言》的时候，我已经深入到了编写一本关于“软件开发就是合作博弈”和“剪裁方法集以适合不同的项目”的书之中。这一宣言只不过是对我和其他人已经在做的事情的附和。 敏捷模型给世界带来了风暴。数以百计的开发人员在网上的签名板上签名（最初的非正式的敏捷联盟，不要与后来成立的敏捷联盟公司相混淆，后者负责管理在美国的召开的敏捷大会），以表示他们与敏捷宣言的价值观和原则一致。 在最初的关于“这是什么意思？”的问题之后，人们会问： •“它什么地方适合所有开发的各种情形？” •“我们如何将这些思想与其他思想混合在一起？” •“我们如何将这些思想扩展到其他领域？” 在第2版中，新增的文字就是来解决这些问题的。 合作博弈模型在与敏捷模型一起成长。最初构建它是为了解释软件开发，但它引起了商业人士的共鸣，他们肯定地发现：大多数商业也是一个创造和沟通的合作博弈（并且是一个竞争博弈）。 你可以想象的到，在过去的这5年里，有些事情的出现使我感到惊讶。我着重说四点： •工程化也是一个创造和沟通的合作博弈。经过一番重新表达之后，我们现在可以将软件工程定位为工程化领域中严格意义上的一员。 在第2版中，我只字未改地保留了我最初写下的那些反对“将软件开发看作是工程”的思想的相当激烈的话。之所以这样做的原因是：对于大多数仍然错误地看待工程学的人来说，这些话仍然适用，它能把人们从相应的管理软件开发的错误方式中拉出来。在第2版的文字中，我把研究方向转回到“什么是工程化”的问题上。 在第二次世界大战之后，对于应用物理学的学科上的嫉妒造成了工程研究领域的一厢情愿的想法，对于工程学的流行的理解脱离了轨道。在重新研究了工程学实践之后，我们注意到：它本身就是一个创造和沟通的合作博弈。由此，我们可以创建一个更新版的软件工程的概念，它在实践上和教育学上都有意义。 •在最近五年中，用户体验设计这一专业领域已经产生了强有力的扩展。过去，它被宣言的作者们忽略了，现在，它应该受到大家认真的关注。 所有这些早期的方法集都完全跳过了这一问题，可能是因为没有一个敏捷宣言的作者在这个领域有很强的专长。这个领域一直是并且还将继续是一个充满争议的领域，几乎没有可靠的结论。我将在这一节中讨论这些结论和争论的观点。 •我已经学会了如何将项目管理策略与方法集区分开。 我们往往会把项目管理的策略当作是公司的过程或方法集的一部分，这是错误的。把那些应当是根据具体情况而制定的策略编写成一个固定的政策，这往往会迫使管理者们制定出没有效率的策略决策，并极大地增加组织的成本。因此，学会区分这两者非常重要。 •更加令人惊讶的是：自从写作本书的第1版以来，围绕着本书（“敏捷软件开发”）的所有开发都发生了。 这意味着有很多需要讲述的话题，还有很多关于敏捷软件开发的含义和实践的误解需要澄清。 因此，关于敏捷软件开发的演进一章（第5A章“敏捷与自适应：演进”）比其他演进章要长很多。这是自然的，也是合适的。我希望那些已经掌握一定敏捷开发知识的读者能够在这一章中发现一些新的信息闪光点，而那些被其中一些问题所困惑的敏捷开发的新手能够得到一些清楚而深刻的认识。 阅读此书 阅读第2版的方式与第1版一样。 那些对“博弈规则”（包括但不限于软件开发）感兴趣的人，他们将发现前4章（包括引言）是他们的主菜。 那些想要迅速为自己的团队获得软件开发的敏捷模型和方法集构建的人，他们可能想直接跳到本书的第2部分，（或者附录A的敏捷宣言，然后从那里再）进入方法集的章节。 有些人读本书的目的是阅读Crystal方法集家族的基础知识。他们应当从第6章开始，我已经用改进过的这一方法集家族的描述对这章进行了更新。然后，他们可以返过头来再阅读关于沟通和合作博弈的部分，这是Crystal方法集家族的根本。 那些已经阅读了本书第1版的人，他们可能会想读每个“演进”章节。这些新的章节在页边上印有灰色的印签，很容易找到。我已经把本书的其他部分中的修改限制为仅仅是纠正错误，因此你不必为了寻找新的观点而重读每一页。 无论你如何阅读本书，我都建议你先读一下附录B，那里包含了宫本武藏（17世纪的武士）、Peter Naur和Pelle Ehn的几篇关键文章。 经过这5年，我变得更加坚定地感谢他们的这些文章了。现在，在敏捷培训的第一个小时中，我会讲述宫本武藏，使用Naur的理论作为描述软件开发的一个核心元素，定期重温Ehn的文章以帮助我使自己的观点变得更加成熟。我猜你也会从它们身上发现类似的价值。

无封面