敏捷软件开发 (2008 年度畅销榜NO.1008 )

本书是国际知名软件开发专家Alistair Cockburn通过采访项目开发组和总结自己二十多年的开发和管理经验，撰写的一本介绍软件开发新思想——Agile软件开发方法学的专著。
本书共6章，在第1章之前的引言部分，作者阐述了人要正确地认识事物和准确交流是非常困难的这一观点。第1章作者通过一个假想的诗歌创作的例子，指出软件开发中常见的问题，并试图揭示软件开发的特点。第2章探讨了在软件开发过程中占据决定性作用的人的因素。第3章论述了团队的交流与合作，说明哪些因素影响交流的效果，有哪些好的交流方式等等。第4章详细列出了方法论的要素、设计原则、词汇术语等内容。第5章作者从多个角度论证了一套方法应该是动态的、自适应的。第6章阐述了作者自己的水晶系列方法论。附录A给出了敏捷软件开发宣言，其主要内容是是四个核心价值和十二个指导原则。
本书提供了一个新的角度来看待软件开发活动，以及一个新的思路来设计开发方法。书中提供的材料大部分来自作者丰富的实践经验，对软件开发实践有很高的参考价值，本书适合软件开发人员、项目管理人员、软件工程研究人员，以及所有想要了解敏捷开发思想的各界人士参考。

第0章 引言——不可知和无法交流　1
0.1 解析经验的问题　3
0.1.1 不同的解析模式（Parsing Pattern）　3
0.1.2 检测解析模式　6
0.1.3 要考虑那些还没有成形的想法　7
0.2 充分交流的不可能性　8
0.2.1 内部重构　10
0.2.2 深入共享经验　11
0.2.3 管理不完美的交流　12
0.3 听众的三个层次　14
0.3.1 方法论和三个层次的读者　15
0.3.2 本书和三个层次的读者　17
0.3.3 SHU-HA-RI　17
0.4 那么, 明天我该做什么　19

第1章 创造与交流的协作游戏　21
1.1 软件和诗歌　23
1.2 软件和游戏　25
1.2.1 游戏的种类　25
1.2.2 软件和攀岩　26
1.2.3 一个创造与交流的游戏　28
1.2.4 软件和工程　29
1.2.5 软件和建模　30
1.3 再论协作游戏　32
1.3.1 程序员如同交流专家　32
1.3.2 加快游戏速度　33
1.3.3 标记（Marker）和道具（Prop）　33
1.3.4 回报减少　34
1.3.5 主要目标所需的充分度（sufficiency）　34
1.3.6 沉淀的充分度　36
1.3.7 游戏中的游戏　38
1.3.8 开放源码开发　38
1.4 这对我意味着什么　39

第2章 人　41
2.1 人是难以预料的　43
2.1.1 探寻人的性格特征　43
2.1.2 不可预测的元素　44
2.1.3 不可避免的多样性　46
2.1.4 技术的作用　47
2.1.5 矛盾的普遍性　47
2.2 克服缺点　48
2.2.1 会犯错误　49
2.2.2 墨守成规. 缺乏冒险精神　50
2.2.3 只想创新, 不愿调查已有方案　51
2.2.4 积习难改和变化无常　52
2.2.5 用纪律（discipline）和宽容（tolerance）来应对　53
2.3 用更好的方法工作　55
2.3.1 具体（concrete）　55
2.3.2 实物（tangible）　57
2.3.3 可供修改的例子　58
2.3.4 看和听　59
2.3.5 支持集中和交流　60
2.3.6 工作安排与个性相匹配　60
2.3.7 天赋（talent）　61
2.3.8 保持乐趣的奖励　62
2.3.9 综合性奖励　66
2.3.10 反馈（feedback）　66
2.4 利用优点　67
2.4.1 善于寻找　68
2.4.2 人能够学习　69
2.4.3 可塑性（malleable）　70
2.4.4 贡献和采取主动　70
2.4.5 结合优点　71
2.4.6 英雄也是普通的人　72
2.5 明天我该做什么　73

第3章 团队交流. 合作　75
3.1 信息对流　77
3.1.1 拖延和丧失机会的代价（lost-opportunity costs）　77
3.1.2 Erg-seconds（尔格/秒）　79
3.1.3 渗透交流　82
3.1.4 垃圾信息（Draft）　84
3.1.5 信息辐射源　85
3.1.6 应用热空气理论　90
3.2 跨越交流沟壑　93
3.2.1 交流形式　93
3.2.2 缺少交流形式的后果　96
3.2.3 利用形式　97
3.2.4 固化信息和跨越空白　99
3.3 团队是个集体　102
3.3.1 友好和冲突　104
3.3.2 工作时间内的公民感　105
3.3.3 敌对的XP和友好的XP　106
3.3.4 通过成功来组建团队　107
3.3.5 团队文化和亚文化　108
3.4 团队就像生态系统　112
3.5 明天我该做什么　114

第4章 方法论　115
4.1 创造软件的生态系统　117
4.2 方法论中的概念　117
4.2.1 结构术语　118
4.2.2 范围　123
4.2.3 概念术语　125
4.2.4 发布方法论　137
4.3 方法论设计原则　143
4.3.1 常见的设计错误　143
4.3.2 方法论运用成功的项目　148
4.3.3 作者的偏好　149
4.3.4 七条原则　151
4.4 近距离观察XP　169
4.4.1 XP简介　169
4.4.2 剖析XP　171
4.4.3 调整XP　172
4.5 到底为什么需要方法论　173
4.5.1 方法论的目的　174
4.5.2 如何评估一套方法论　175
4.6 明天我该做什么　176

第5章 敏捷和自适应　179
5.1 轻但够用　181
5.1.1 刚刚够用　182
5.1.2 对文档的建议　183
5.2 敏捷　184
5.2.1 最佳条件（Sweet spots）　184
5.2.2 虚拟团队（virtual teams）问题　187
5.3 变为自适应　190
5.3.1 花时间进行反思　190
5.3.2 一项方法论改进技术　191
5.3.3 反思研讨会技术　200
5.4 我明天该做什么　202

第6章 水晶系列方法论　205
6.1 形成水晶家族　207
6.1.1 核心的水晶元素　209
6.2 透明水晶　210
6.2.1 关于透明水晶的简要描述　210
6.2.2 透明水晶的反思　212
6.3 橙色水晶　212
6.3.1 关于橙色水晶的简要描述　213
6.3.2 橙色水晶的反思　215
6.4 橙色水晶网（Crystal Orange Web）　215
6.4.1 对橙色水晶网的简要描述　216
6.4.2 橙色水晶网的反思　219
6.5 明天我该做什么　220

附录A 敏捷软件开发宣言　221

附录B Naur, Ehn, Musashi　233

参考文献　265

索引　279

软件开发是一种艺术.工艺.科学.工程还是其他什么东西？这有什么意义吗？ 是的, 这当然有意义, 而且对你非常重要.该问题的答案更接近哪一个将影响到你的活动和活动的结果. 关键的是：你希望你的软件能尽快地完成, 尽可能地没有缺陷.除此之外, 你更希望找到一种方法来考察你的团队是如何工作的. 目的 现在是应该更进一步探究软件开发内涵的时候了. 问题是, 当我们观察项目时, 我们的注意力往往局限在那些我们已经知道应该注意的事物上.我们一般是根据我们以往的经验来对事物进行区分.分离和检验的, 当我们不能进行关键的区分时, 我们往往会忽略了一些眼前的事物. 我们用词汇来指代记忆中的特征(distinctions), 并使用这些词汇来反映我们的经验.如果缺乏词汇来指代相应的特征, 我们就很难将所想的反映到对话中, 最终导致无法制定出应对未来的策略. 换句话说, 要想进一步探究软件开发的内涵, 就必须重新考虑用来解析经验的特征概念, 以及用来指代这些特征概念的词汇. 当然, 对于任何一本书来说这都是个很高的要求.这意味着本书的前几章会非常抽象, 但我别无选择. 最近的一次人们为软件开发构建词汇表是在20世纪60年代末期.当时他们使用软件工程(software engineering)一词, 作为对未来的期望和指导方向. 更重要的是, 在“编程应该工程化”的论断建立的同时, Gorald Weinberg写了《The Psychology of Computer Programming》一书.在那本书中, 软件开发与工程领域看起来截然不同, 它提出以人为本(human-centric)和以沟通为中心(communication-centric)的观点.在这两者中, Weinberg的观察与30年来人们所报告的成功项目相吻合, 而软件工程仍然是一个理想化的术语. 在这本书中, 我将 * 为所谈到的软件开发建立特征概念和词汇表. * 使用这些词汇来检查和抓住软件开发的重要方面, 这些方面常常被忽视. * 把这些方法论(methodologies)的思想原理作为 “行为准则”. * 把追求具有普遍性的行为准则与“每个项目都是独一无二的”的思想结合起来, 推演出一套有效的和“自我演进(self-evolving)”的准则. 我希望读完这本书以后, 你将能够使用新的专业词汇来审视你的项目, 注意那些你以前没有注意到的东西, 并将观察结果表述出来.掌握了这些, 你将能够 * 讨论极限编程（Extreme Programming）, 能力成熟度模型(Capability Maturity Model), 个人软件过程（Personal Software Process）, 或其它你喜欢的过程. * 判定一个过程在什么时候是适用的, 什么时候是不适用的. * 理解那些有不同观点.不同能力和不同经验的人们. 读者 每个读者有不同的经验.阅读习惯和角色.那么如何来阅读和使用这本书, 让它为你带来最大收获呢？下面分别根据经验.阅读习惯和角色来介绍应如何阅读这本书. 根据经验 这本书主要针对的是有丰富经验的读者.书中没有可遵循的软件开发过程.方法, 实际上, 本书的核心思想是“任何技术都有局限性”.因此, 不可能找出一种最好最正确的软件开发方法.希望本书能帮助你明白这个道理, 并给你一些建设性的思想, 来帮你应对真实世界中的各种情况. 如果你是一个中等水平的开发人员, 对软件开发项目有一定经验, 如果你正在为你所学习的规则寻找适用范围, 你将发现以下主题最有用处： * 哪种方法论适合于哪种类型的项目. * 建立方法论种类的索引, 以便为一个项目选择相适合的方法论. * 敏捷方法论的原理. 作为一个中等水平的开发人员, 你要认识到在应用这些思想时必须加上自己的判断. 如果你是一个高级开发人员, 那么你已经对这些建议的适用性有了一定的认识.你也许正在寻找能表达这些认识的词汇, 你将在以下主题中找到答案： * 管理不充分的沟通. * 不断改进方法论. * 敏捷软件开发宣言. 甚至对于高级软件开发人员来说也有一些话题是新的——描述方法论的词汇, 以及实时调整方法论的技术. 根据阅读习惯 相对于后几章, 前几章比较抽象. 如果你喜欢抽象的内容, 可以从头开始阅读.随着这些抽象话题的展开, 看看书中那些不可能解决的问题最终是如何被重新解决的. 如果你需要尽快掌握具体的方法, 你可以跳过前几章, 直接从第四章“方法论”开始.然后再回过头来阅读“协作游戏”和“信息对流”部分, 从中获得新词汇表的关键部分.最后再阅读引言和关于个人和团体的章节. 根据角色 对于出资进行软件开发的人来说, 可以从本书了解不同组织.行为.资金结构对他们从开发团队所能获得的收益的影响.相对于直接参与项目的人, 项目出资人可不必关注方法论构建的细节, 但他们仍需理解使用某种方法论会带来的后果. 团队负责人和项目经理应关注座位.组队.个体差异是如何影响项目输出的.他们也应了解哪种干预会导致更好或更坏的后果, 他们必须理解方法论的构建和影响, 以及如何改进他们的方法论, 使其尽可能得轻, 但仍然够用. 过程和方法论设计者可以检查和评论我所选择的术语, 以及方法论设计的原则.随之引发的讨论将对该领域很有意义. 软件开发者将会在自己的职业生涯中自然而然地理解这些内容.一般来说, 在从一个新手成长为领导者的过程中, 人们将不得不注意到项目中哪些方法能正常工作, 哪些不能正常工作.他们也必须了解如何调整他们的实际环境, 以使工作更有效率.“我们的方法论”实际意味着“我们所遵循的惯例(conventions)”, 因此, 理解方法论构建的要素也是开发人员的职责. 本书的组织 本书在开篇提出两个几乎无法解决的问题, 然后在书的结尾得出答案： * 如果无法进行交流, 项目管理者应如何去做？ * 如果说每一个人, 每一个项目都是不同的, 那么我们如何创建适合于不断变化的项目的规则？ 出于这种考虑, 我采用了类似于推理小说的写作风格来编写此书.我以最普遍的.哲学式的讨论开始：“什么是交流？”和“什么是软件开发？” 讨论不断深入, 但仍然是抽象的话题, 例如“什么是人的特性？”“什么影响团队内思想的发展？” 接着, 进入比较具体的范畴, “方法论的原则和要素是什么？”如果你对较为具体的内容感兴趣, 不如从这儿开始阅读. 最后讨论了最具体的问题, 一个轻量级的.够用的.能自我改进的方法论是什么样的？小组如何及时创建一个定制的.敏捷的.对项目有效的方法论？ 附录中包括一些相关材料, 附录A是《敏捷软件开发宣言》, 由17位非常有经验的软件开发人员和方法论学家签署. 附录B摘录了三篇文章, 它们没有像应有的那样被广为人知, 我收录它们是因为它们的核心内容与本书的主题相符. 本书思想的来源 本书的思想来自25年的开发经验和10年的项目调查结果. 1991年, IBM顾问组请我为他们设计第一个面向对象的方法论.我看了一些“方法论”方面的书, 却没有从中获得任何帮助.我的老板, Kathy Ulisse和我决定听取项目团队的汇报, 从而更好地理解他们到底是如何工作的.这真让人大开眼界, 他们所使用的词汇几乎和书中的完全不同. 访谈一直在继续, 而且依然很有价值.我访问那些成功而又有趣的项目, 以找出他们所遇到的.所学到的和所建议的.在访谈以前我问的最重要的问题是：“你会再次使用这样的方法吗？”有时人们会用我的词汇表以外的词语来描述他们的经历, 这些词语揭示出新的领域, 而我缺乏描述这些领域的特征和词汇. 正是因为词汇和特征直接关系到项目过程和项目结果的描述, 所以我才要写这本书.在诊断和干预方面它们比以前我用过的任何工具都更有价值. 本书的思想来自于许多开发团队.八个方法论设计和我所参与的许多成功项目. 敏捷Agility 我不是唯一运用这些思想观点的人： * 80年代末期, Kent Beck和Ward Cunningham在他们的工作中运用一种独特的理念, 后来在90 年代末期这一理念被称为极限编程. * Jim Highsmith在90年代中期研究复杂适应性系统的语言和商业用途, 并在他的书《Adaptive Software Development》中描述了这种软件开发语言的应用. * Ken Schwaber和Jeff Sutherland大约在同一时间构建了Scrum[J1]开发方法.同一时期有许多项目负责人都试图阐述类似的观点. 2001年2月, 我们中的一些人聚在一起讨论各自的观点, 发现有许多相同之处.我们选择“敏捷”这个词来描述我们的意图, 并写下《敏捷软件开发宣言》（参见附录A） 现在我们仍然在不断总结大家都赞同的原则, 并发现了许多同行, 如果他们了解这次会议而且有时间, 我想他们会去参加会议. 敏捷软件开发的核心是在项目管理中运用“轻但够用light-but-sufficient”的原则, 以及以人为本和以沟通为中心的原则. 敏捷意指灵活性, 现在这一点更为重要.在WEB上部署软件会越来越加剧软件行业的竞争.想要在行业中站住脚, 不仅要完成软件.减少缺陷, 还要持续追踪用户的需求和市场的变化.业务的发展越来越取决于软件开发的成功, 而要想成功地开发软件就必须了解软件开发的游戏规则. 我认为Goldman（1997）对业务中的“敏捷”做了最好的描述. “敏捷是动态的.适应于具体情况的.迎合变化的.自我完善的.敏捷不仅在于提高效率.降低成本.做好准备从而能安全度过可怕的金融风暴.还关系到在竞技场上获得成功, 关系到从激烈的竞争中赢得利益.赢得市场份额.赢得客户”. 敏捷软件开发丛书 人们开始关心软件开发中的敏捷也就是最近十年的事.我和Jim Highsmith发现了我们之间的很多共同点, 我们走到一起致力于出版一套敏捷软件开发丛书.相对轻而且有效, 以及重视人的力量的软件开发技术是这套丛书的基线. 我们这套丛书基于下面两条核心思想： * 不同的项目需要不同的过程或方法论, * 注重技巧.交流.团体, 比注重过程更能让项目有效率和敏捷. 这套丛书有三条主线： * 展示能提高个体工作效率的技术.无论是用户界面设计者, 需求收集者, 项目策划者.设计人员还是测试人员, 谁都想知道世界上做同样工作做得最好的人是怎么做的.《Writing Effective Use Cases》(Cockburn 2001c)和《GUIs with Glue》是两本谈论个体技术的书. * 展示能提高一组人的效率的技术.包括团队建设.项目回顾.制定策略等诸如此类的技术.《Improving Software Organizations》(Mathiassen 2002)和《Surviving Object-Oriented Projects》(Cockburn 1998)就是两本谈论团队技术的书籍. * 展示一些特定的.成功的敏捷方法论的例子.无论谁想选择一个基本的方法论来裁减它.使用它, 都希望找到的是一个已经在类似环境下成功运用的例子.修改一个已有的方法论比创建一个新的要容易一些, 而且比一个为不同情况设计的方法论更有效.Crystal Clear是一本介绍具体方法论的书[J2].我们希望能尽快出版介绍其他方法论的书. 两本关于敏捷软件开发的书： * 本书用我所喜爱的词汇来描述敏捷软件开发的思想——把软件开发当作一个协作游戏, 把方法论当作协调的惯例, 以及方法论的流派. * 第二本是Highsmith即将出版的一本书, 《Agile Software Development Ecosystems》.这本书从三个方面进行了进一步的论述：软件开发中产生的问题, 那些签署敏捷软件开发宣言的开发者们的共同观点, 以及共同的敏捷实践.Highsmith的上一本书, 《Adaptive Software Development》用他所喜爱的词汇表达了他对软件开发的看法——软件开发是复杂的适应性系统. 你能够从WEB上找到更多关于水晶.适应性以及其它类型的敏捷方法论.相关的网址和文章在书后的参考文献中, 以下是一些主要网址： * www.CrystalMethodologies.org * www.AdaptiveSD.com * www.AgileAlliance.org * 我的主页：members.aol.com/acockburn 特别感谢 感谢Ralph Hodgson 能有如此一流的图书馆, 收藏了那么多的未被人注意的.有趣的书籍.他的书籍管理也是一流的, 我总能找到我正好需要的那些不出名的书：Vinoed的 《Sketches of Thought 》以及 Wenger 和Lave的《Situated Learning》, 还有其它的书.你从参考书目部分看到的那些有趣的和不大出名的书大都来自Ralph的图书馆. 感谢Luke Hohmann 让我认识了Karl Weick.Elliot Soloway和 Jim Highsmith, 他们让我明白了"突现行为"是规则的特征, 而不仅仅是“运气”的问题.他们都花了或多或少的时间来整理话题的次序.核对引用的准确性, 并几乎为每一页都做了注释. 感谢Jason Yip , 当我试图说明信息的传播方式时, 他巧妙地将其形容成气体扩散.他写到：“Kim正在传递信息.信息是绿色的气体.Kim正在散发着绿色的气体...”多么贴切的句子, 不是吗？ 感谢Bo Leuf 想出了这么精彩的词汇——argh-minutes (相对于 erg-seconds), 来度量交流谈话失败的程度.我更要感谢他反复推敲我的一些论断.例如, 他写信给一些以色列人来验证我的论点, “在交谈中礼貌更多地被认为是侮辱而不是赞扬”.这引发了一场让人兴奋的e-mail对话, 其中一封e-mail（来自以色列）说道：“作者在这里有明显的错误, ...我们在几天不见以后总是会问候和握手...我认为作者把对工作中错误的不宽容误解为缺乏礼貌.”另一人写到：“出于你的热情, 无论你说什么都无可厚非.我认为, 以色列人要求你有自己的看法并坚持你的观点.当然他们也有自己的观点（至少有一个人如此）”.我最终使用了Benny Sadeh选择的词汇——“坦诚”. 感谢Martin Fowler 为方法论的讨论提出了“可见性”的概念, 此外他写了一些有建设性的评语, 并温和地指出一些他认为不好的部分. 我还要特别感谢其他几位出色的审稿人员（按字母排序）： Alan Harriman, Allen Galleman, Andrea Branca, Andy Sen, Bill Caputo, Charles Herbaut, Charlie Toland, Chris Lopez, Debbie Utley, Glenn Vanderburg, James Hanrahan, Jeff Miller, Jeff Patton, Jesper Kornerup, Jim Sawyer, John Brewer, John Cook, Keith Damon, Laurence Archer, Michael, Van Hilst, Nick Fortescue, Patrick Manion, Phil Goodwin, Richard Pfeiffer, Ron Holiday, Scott Jackson, Ted Young, Tom DeMarco, and Tracy Bialik. 我要加倍感谢的是The Silicon Valley Patterns Group, 他们不厌其烦地对本书的每一部分都进行了剖析. The Salt Lake production团队的Elizabeth Wilcox, Cathy Gilmore, John Roberts和Malia Howland完成了奇迹般的工作, 他们在非常短的时间内将手稿变成了最后正式出版的书籍. 每个人都不遗余力地帮助我修改不足的章节, 保留好的章节.如果我能有再多一点时间来修改这本书, 我可以让他们更加满意.在这里, 我诚心地感谢他们的努力, 并向他们道歉, 因为我没有来得及修改所有有缺陷的部分. 感谢上帝, Beans & Brews 咖啡店终于又开始播放爵士乐和摇滚了.我已经好几个月没有听重金属和乡村音乐了.感谢盐湖烤肉店直到深夜还为我敞开大门. 为了避免将来发生让人尴尬的局面, 我要说明的是我的名字的发音是"Co-burn", o发长音. 附加版权信息 '"Scandinavian Design" by Pelle Ehn, from Usability: Turning Technology into Tools, Paul S.Adler and Terry A.Winograd(Eds.), Copyright (c)1992 by Oxford University Press, Inc.Used with permission, Oxford University Press, Inc. "Programming as Theory Building" by Peter Naur, from Computing: A Human Activity, ACM Press, 1992.Used with permission, Peter Naur. From The Book of Five Rings by Miyamoto Musashi, translated by Thomas Cleary, (c)1993, 1994.Reprinted by arrangement with Shambhala Publications, Inc., 300 Massachusetts Avenue, Boston, www.shambhala.com. "Shu Ha Ri" by Ron Fox, from The laido Newsletter, Volume 7 number 2 #54, February, 1995.Used with permission, Ron Fox, MSU Kendo Club fro Shu Ha Ri. References to eBucks.com and the description of Crystal Orange Web used with permission, Michael Jordaan, eBucks.com. Figure 3-10 used with permission, Joshua Kerievsky, Industrial Logic, Inc., www.industriallogic.com, Copyright (c)2001. Figure 3-11 used with permission, Joshua Kerievsky, Ann Anderson, &Chet Hendrickson, Extreme Programming Installed, Addison-Wesley, 2001. Figures 3-1, 3-9, 3-15,and 3-16 used with permission, Evant Solutions Corporation, www.evantsolutions.com, Copyright (c)2001. Figures 3-2, 3-3, 3-6, 3-7, and 3-8 used with permission, ThoughtWorks, Inc., www.thoughtworks.com, Copyright (c)2001. Figures 3-12 and 3-13 used with permission Ken Auer, RoleModel Software, Inc., www.rolemodelsoft.com, Copyright (c)2001.