本书全面论述了敏捷软件开发生态系统的有关内容，阐述了变化驱动的信息时代经济的关键特征，介绍各个敏捷软件开发生态系统，提供各种类型的项目，展示了一个敏捷软件开发生态系统的实例。总之，通过本书的学习，读者能够了解到敏捷软件开发生态系统方面的基础知识、前沿方法和先进理念，并在学习和工作中受益。 　　本书简明、易懂、实用性强，适于计算机软件专业的专科生、本科生和研究生使用，也可作为相关从业人员的参考用书。 　　在一个瞬息万变的软件开发环境中，开发者必须十分灵活，反应迅速，能够实现不断变化的目标 ——简而言之，他们必须十分敏捷。敏捷软件开发的目的是满足对速度和灵活性的需要。敏捷软件开发吸收了既有软件工程技术的精华，又避免了传统软件开发方法的局限，为软件工程开创了新的方向。 　　本书对敏捷软件开发方法进行了全景展示。作者是敏捷软件开发运动的领导人之一，在与其他的敏捷领导人Kent Beck、Robert Charette、Alistair Cockburn、Martin Fowler、Ken Schwaber和Ward Cunningham面谈之后完成了本书。本书深入剖析这种灵活而又极其成功的软件开发新思维，提出所有敏捷开发方法的核心实践，提供对各种特定技术的总体看法，并阐述如何去选择最适合自己组织的方法。
　　本书深刻描述最重要的敏捷开发原理：交付对客户有价值的东西，关注开发者个人及其技能，强凋协作和可以工作的软件产品，以及技术卓越的重要性。这些敏捷方法包括：
　　　Scrum
　　　动态系统开发方法
　　　Crystal方法
　　　特性驱动开发
　　　精益开发
　　　极限编程
　　　自适应软件开发

Jim Highsmith足著名的顾问、软件开发者、作家和讲演家，也是敏捷联盟的发起人和第一任理事，敏捷宣言的执笔人之一，Cutter Consortium的敏捷项目管理咨询主管，他还是2000年度Jolt奖得主《Adaptive Software Development》一书的作者。

2001年2月11-13日，在犹他州Wasateh山的滑雪胜地Snowbird的一幢大楼中，17个人聚在一起交谈、滑雪、休闲，试图找到某些共同话题。这次会议形成了敏捷软件开发运动，其中包括：极限编程(eXtreme Programming ，XP)、Scrum、动态系统开发方法(Dynamic Systems Development Method，DSDM)、自适应软件开发(Adaptive Software Development，ASD)、Crystal方法、特性驱动开发(Feature-Driven Development，FDD)、实用程序设计等。这些方法可满足对不同于文档驱动的、严格的软件开发过程的新方法的需要。会议的结果是17名与会者签署了“敏捷软件开发宣言”(The Manifesto for Agile Software Development)，宣告：
　　我们通过实践寻找开发软件的更好方法，并帮助其他人使用这些方法。通过这一工作我们得到以下结论：
　　个体和交流胜于过程和工具。
　　工作软件胜于综合文档。
　　客户协作胜于洽谈协议。
　　回应变革胜于照计划行事。
　　这个观点有许多鲜明的特点，并不在于至少有17个人的一致同意。尽管这些人具有丰富经验并被认为是软件开发界的领军人物，但是宣言中选择词语“寻找”表明了作者并没有所有的答案，也不赞成“银弹理论”。
　　短语“通过实践”表明作者确实在自己的工作中实际实践了这些方法。Ken Schwaber曾讲过他自己出售过自动综合的、属于“重”方法学的工具。Ken的公司那种快速反应给Jeff Sutherland留下了深刻印象，他问：　“哪些严格的方法学被用于内部研发 ”Ken评价道：“当我告诉他，‘从不使用，如果我们使用其中任何一个，我们就会倒闭。’我仍记得Jeff的脸色。”作者以敏捷开发实践来帮助他人，并在互相学习中丰富自己的知识。
　　上述价值陈述有一个格式。在每一陈述中，前半部分具有一种优先权，而后半部分则描述了一个项，尽管这个项很重要，但优先级要低。这种区别是敏捷方法的核心，但简单地要求别人列出什么是有价值的，还不能找到其根本差别。Roy Singham是ThoughtWorks公司的CEO，他很好地表达了这一点：正是边界情况和困难的选择使我发生了兴趣。　“是的，我们评价计划、综合文档、过程和工具，这些都容易做到，困难的是问：　‘哪些价值更高 ”’当把这些问题提出来时，必须有所回答，我们必须清楚保留什么，放弃什么。
　　第一条价值陈述认识到，过程和工具虽然重要，但人才之间的交流更重要。严格的方法学及业务过程再工程的同事们强调过程重于人。敏捷开发方法将这一点反了过来。如果我们相信个人是独一无二的，那么过程应该融入个人和团队，而不是其他什么别的方式。
　　类似地，虽然综合文档并非有害，但重点一定要在最终产品——工作软件上。就是说，每一个项目组必须自己决定，哪些文档在交付工作软件时是非有不可的。摆在开发者和发起人面前的工作软件说明了实质——哪些地方与当初的承诺是不同的。工作软件可以被包装、修改、分析，但却是真实的。
　　洽谈协议，无论是通过内部项目章程，或者通过外部的合法合同，并不是坏事，但光有这些是不够的。客户要的是交付能满足他们需求的产品。Ron Holliday说：“洽谈协议会增加不确定范围[偶然性]。这会使完成项目的时间更长，成本更高，并减缓对变化了的需求做出响应。客户和供应商的团队协作可能是最好的解决方案。”协议和项目章程提供了边界条件，这样参与者得以工作，但只有通过不断的协调，开发小组才有希望真正理解客户需求，并交付客户需要的产品。
　　有人能证明照计划行事是个好主意吗 没有。不管怎样，在一个业务和技术都混乱的世界里，严格照计划行事，即使是忠实地执行计划，都有可能带来可怕的后果。不管计划制定得多么详细，如果这个计划阻碍你随机应变，它就变得很危险。本书提供的一些案例研究说明，几乎没有项目是按开始计划时那样来完成的。只有那些足够敏捷的开发小组，不断适应外部的变化，才会取得成功。在信息时代，制定计划是重要的，但更加重要的是要接受任何计划都有偏差是正常现象这一观点。
　　2000年春，由Kent Beck组织的极限编程带头人的会议在俄勒冈州召开，一些局外人，但却是“热心者”——包括我自己也应邀参会。这次会议孕育了在Snowbird的会议。与会者一致支持各种“轻”方法学。在2000年，许多论文都参考了有关“轻”或“轻量级”实践的分类。在谈话中，即使采用“敏捷”开发方法的作者们不喜欢“轻”这个词语，但在那时这个词语仍在用。
　　2000年9月，素有“鲍勃大叔”之称的芝加哥Object Mentor公司的Martin发出一封e-mail，从而开始了“敏捷”之球的滚动。e-mail内容为：“我希望于2001年1—2月在芝加哥举行一个为期两天的短会，会议的目的是把所有的轻量级方法的带头人聚到一起。我邀请你们所有人，我很想知道你是否能来 ”鲍勃设定了一个在线论坛，从而开始了热烈讨论。Alistair Cockburn也以书信形式加入了讨论。他对“轻”一词感到不满意：“我并不在意将方法学称为‘轻’，但我并不想因参加一个轻量级方法学家的会议而被称为是轻量级的，听起来有点像一帮极瘦的、低能的人努力想记住今天是什么日子。”
　　最激烈的争议是会议地点，芝加哥的冬天较冷，无处可玩。有人提议到犹他州的Snowbird，虽冷，但可以玩耍，至少可以滑雪。Martin Fowler第一天就去滑雪了。还有人提到温暖而有趣的加勒比安圭拉岛，但路途太远。最后，选择了Snowbird和滑雪。
　　敏捷宣言的价值陈述表达了一个更深的主题，这一主题激励着许多(但不是全部)宣言的签署者。在两天会议快结束时，Bob Martin开玩笑说，他打算做一个“柔软的”陈述。尽管有点幽默，但没有人否认鲍勃的感觉。我们都感觉很荣幸能和一群有相似观点的人在一起工作，基于互相的信任和尊重，提倡以人为本的组织形式，建立工作成员之间的合作和交流。我认为关键点是，敏捷软件开发者确实具有柔软特性，交付给客户的产品可以工作在一个变化不定的场合。因此，最后分析认为，对敏捷软件开发感兴趣的人数和持批评态度的人数均有所上升，这就反映了价值和文化的柔软特性。
　　例如，我最后认为，XP在应用中已经成熟，许多人对其感兴趣，原因并不是结对编程或重构，而是一种总体考虑，是在实践中定义了从公司的计划束缚中解放出来的开发团体。Kent Beck说过以前工作中的一件事，他估计某个程序设计工作需要2人工作6周，他的经理一开始就为任务分配了另一个编程员(有效地平分资源)，Kent用了12周完成了任务——感到不可思议!　当然，Kent的老板在后面6周中大感不满，抱怨他是一个如此“失败”的程序员。Kent最后认识到他最初关于2人工作6周的估计是十分精确的，他的“失败”其实是他的经理的失败，他没有对项目资源进行合理分配。这种情况可以说每天都发生在那些人身上：他们不愿意做出难以权衡的决策，而是强行发布不合理的命令。
　　敏捷运动不是反方法学的，事实上，我们在努力恢复方法学概念的可信性。我们要恢复一种平衡关系。我们接受建模，但不是为了写一些流程图后再丢进公司的储藏间；我们接受文档，但不是要数百页的从不修改和极少使用的卷宗；我们制定计划，但能认识到在一个激烈变化的环境中，计划有很大的局限性。在一些人的思想中，总把FDD或Scrum或任何一个敏捷方法归入“黑客技术”，其实这是对黑客方法和黑客基本定义无知的表现——名词“黑客”是指：热衷于解决复杂程序设计问题的编程者，而不是那些进行特定开发或解密的人。敏捷软件开发可以结合已证明的软件工程技术，但没有传统方法学的约束。
　　敏捷联盟诞生于2001年，但其各种方法和研究这些方法的人的历史可追溯到10—15年前。本书描述了这些人的研究实践和背后的相关原理，但更重要的是，本书剖析了正在开发各种方法的人和使用这些方法为客户创造商业价值的人。

20世纪90年代是rr业快速发展的10年。我们遵从着CMM和ISO体系，不仅仅追求软件构造方式的完美性，也注重总体的可预测性。我们的结论是，仅将事情做对是不够的。我们必须预定一个基调来预先准确说明打算做什么，然后再不多不少地严格执行。我们打算(按CMM的术语)“将工作计划好，并为完成计划而工作”。
　　20世纪90年代我们的工作重点在很大程度上和我们着迷于日本人的工作方式有关。回想1990年，回忆那时的研究主题，充满着一种失落感。西方人丧失了他们的机遇，　日本人则能把握将来。毕竟他们工作更努力，经常加班加点，有极为严格的纪律，并有严格的质量等级制度，这对其他人来说，只能是一种梦想。日本现象，所谓“太平洋虎”，就是那时发生的一切。我们当时认为，如果要生存，最好像日本人那样工作，所以我们采取了更加日本化的方式：严格和过程化。
　　但在凹世纪90年代，　日本的发展并不一帆风顺。在90年代的最后几年日本经济急剧下跌，导致了大衰退。这说明，努力工作、守纪律、高效率、严格，这些80年代适用的内容并不是90年代的取胜法宝。20世纪90年代所要把握的就是——灵活。因特网改变了一切，只有那些随时准备应付这些快速变化的人，才能赢得胜利。敏捷是关键所在，其余的并不重要。
　　类似地，过于严密的过程并不代表有好的结果，从20世纪90年代早期到后期，靠遵从CMM获得极大成功的公司名单在不到10年时间已逐渐缩短，谈起来就像一都不断缩水的名人录。步骤过于严密对一切都在快速变化的时代不是一个正确的应对方案。提首预测你的每一步骤所应达到的目标这种有点愚蠢的方式应该结束了。在你甚至不能确信所要到达的目标是什么时，提前预计你的每一个步骤是没有什么意义的。　　
　　今天，采用臃肿过程的时代已经结束，正如Jim Highsmith所说：“采用简化过程的时代已经来临。”为了优化速度和灵敏度，必须让过程简化。抛弃日常文牍和官僚作风，简化无休止的代码检查，培养人员，使他们能驾驭自己在现代IT项目这个无序的迷宫中灵活地穿行，这些就是软件开发的敏捷方法之根本。
　　Jim Highsmith以概括性的方式对敏捷方法学进行了综述。他采用引人入胜的叙事方式，而不是讨论一些概念。同任何好的故事一样，人在其中起支配地位。因此，他通过给我们讲述敏捷方法的倡导者和发明者，如Kent Beck、Alistair Cockburn、Martin Fowler及其他“轻方法学家”，从而让我们了解敏捷方法。这些方法和思想正在改变着IT行业的运作方式。这就是本书所讲述的内容。
　　Tom DeMarco
　　Camden，Maine

（美）Jim Highsmith：暂无简介

姚旺生 杨鹏：暂无简介

随着科学技术的高速发展和因特网的普及应用，人们生活和工作的方式发生了很大变化。而随着我国加入WTO，竞争环境则越来越严酷，尤其是在IT行业。一个IT企业要想在这种环境下生存并发展，就必须采用新的管理方法和工作模式。
　　只要编写过软件，就一定会熟悉结构化、模块化，知道什么是自顶向下。CMM(能力成熟度模型)是一个象征公司软件开发能力的标志，ISO则是一个象征公司管理规范化程度的标志。在CMM和ISO体系中，为了达到最终的完美结果，需要预先制定出严格的工作步骤，然后再严格按步骤实施。预先制定严格的方法和步骤在很多企业十分有效，但在IT行业却可能成为例外。因为许多情况下要在项目的开始就确定用户的最终需求几乎是不可能的事情。一个成功的项目小组总是在和用户不断地交流，根据用户的建议不断调整自己的工作计划和目标，
同时也以务实的态度来满足用户的需求。
　　因此，在软件产品的开发过程中，应该随时调整计划、方法和目标。或者说，为了交付使用户满意的软件产品，项目小组和开发人员必须具有“敏捷”特性。
　　敏捷软件开发方法以人为本，以满足用户需求为目标，其特征是：具有随时响应外界变化的能力。这种变化体现在许多方面：如经济全球化导致的业务和经济环境更难确定，竞争对手的策略和用户需求的不断变化，技术的高速发展，员工薪酬的不断提高，等等。采用敏捷方法的公司具有驾驭这种不确定性的能力，从而能立于不败之地，蓬勃发展。
　　敏捷软件开发生态系统包含了许多方法，这些方法构成了敏捷软件开发的总体。没有哪一种方法是最有效的，必须根据实际情况灵活运用。这种灵活性就是敏捷方法的精髓。
　　因此，如果你在开发软件并期望取得成功，就需要采用敏捷方法；如果你希望能在不确定的世界中把握自己的方向，就应该采用敏捷方法；如果你希望能压制住竞争对手取得更大的市场份额和商业利润，就必须采用敏捷方法；如果你想塑造一个团结协作、奋发向上、灵活高效的企业文化，最好采用敏捷方法；如果你想让用户对开发出来的工作软件十分满意，惟一的选择就是运用敏捷方法。
　　本书序、前言、引言和第一部分由姚旺生翻译，第二部分由杨鹏翻译，第三部分由张晓东翻译，其余部分由周飞和姚旺生共同翻译，赵德忠也参与了翻译工作。
　　国防科技大学计算机学院徐锡山教授审阅并修订了本书的译稿。贲可荣教授为本书的翻译出版做了大量协调工作，提出了许多建设性意见，在此一同表示感谢。
　　本书适合计算机行业的各类人员阅读。对于从事软件项目开发的管理人员和技术人员，本书也是一本有助于开扩思路的好书。对于学习软件工程专业的本科生和研究生，本书可作为软件工程方法学教材或教学参考用书。
　　由于译者水平有限，且时间比较仓促，不当之处在所难免，恳请广大读者批评指正!
　　译　者
　　2002年12月

第一部分　新问题，新方法
第1章　变革驱动的经济
1．1　动荡：泡沫与趋势
1．2　开发与优化
1．3　探索性项目
1．4　命令控制与领导协作文化
1．5　边沿的繁荣
第2章　IDX系统公司
2．1　 IDX的故事
2．2　一个活动的敏捷小组
第3章　敏捷方法
3．1　敏捷
3．1．1　创造和回应变革
3．1．2　灵活性和即兴创作
3．1．3　与现实的一致性
3．1．4　灵活性和结构的平衡
3．2　"敏捷"研究
3．2．1　因特网时代的产品开发
3．2．2　"重"敏捷项目
3．3　敏捷软件开发生态系乙
第二部分　开发思想和代表人物
第4章　人物访谈：Kent Beck
第5章　原理1：交付有用的产品
5．1　HAHT商业公司
5．2　客户交付原理
5．2．1　交付对客户有价值的东西
5．2．2　客户的意见
5．2．3　工作软件
5．2．4　经常地交付
5．2．5　每天一起工作
5．3　交付有用特性的实践
5．3．1　客户-开发者界面
5．3．2　代理用户
5．3．3　具有丰富领域知识的开发者
5．3．4　合同：塑造客户关系
5．4　明显的东西并不明显
第6章　人物访谈：Alistair　Cockbum
第7章　原理2：依赖于人
7．1　Thought Works公司
7．2　你称谁为一般
7．3　信任、怀疑和交流
7．4　才能、技能和过程
7．4．1　过程与技能
7．4．2　制品和信息流
7．4．3　创新和创造性
7．5　编程的没落和复苏
7．6　由人完成软件
第8章　人物访谈：Ken Sehwaber
第9章　原理3：鼓励协作
9．1　ITL的现代运输小组
9．2　一个创造和交流的协作游戏
9．3　实践与过程
9．4　文档并没有得到理解
9．5　协作的维度
9．6　实际的小组
第10章　人物访谈：Martin Fowler
第11章　原理4：技术优势
11．1　Generali Group的PDFS小组
11．2　敏捷并不特别
11．3　排除缺陷
11．4　注重代码
11．5　简单设计
11．6　大冲击与增量
11．7　建模和抽象
11．8　领域认知
11．9　文档与交谈
11．10　专家与通才
11．11　质量与速度
11．12　建立与反建立
11．13　价值和原理
11．14　思考
第12章　人物访谈：Ward Cunningham
第13章　原理5：做尽可能简单的事情
13．1　Trimble Navigation的测量控制器小组
13．2　Musashi
13．3　简单性的三个方面
13．3．1　简单性与极小化
13．3．2　简单性与优秀设计
13．3．3　简单性与生成规则
13．3．4　适应简单规则
13．4　简单性的最后要点
第14章　人物访谈：Jim Highsmith
第15章　原理6：成为自适应
15．1　Cellular公司的Mustang小组
15．2　伟大的划分：预测性或自适应性
15．3　正在改变的业务生态系统
15．4　拥抱变革
15．4．1　推动变革
15．4．2　把再加工看做优点
15．4．3　控制最终组件
15．4．4　在多个层次上不断反馈
15．4．5　多过程层次
15．5　以预期来平衡自适应
15．6　给斗牛犬涂口红
15. 7　变革的费用
15．8　符合实际：度量成功
15．9　自适应性是思想倾向
第16章　人物访谈：Bob Charette
第三部分　敏捷软件开发生态系统大观
第17章　Scrum
17．1　Scrum过程
17．1．1　Pre-Sprint计划
17．1．2　Sprint
17．1．3　Post-Sprint会议
17．1．4　监测进展
17．2　Scrum的贡献
第18章　动态系统开发方法
18．1　Afie van Bennekum
18．2　DSDM原理
18．3　DSDM过程
18．4　DSDM的贡献
第19章　Crystal方法
19．1　方法学设计原理
19．2　Crystal框架
19．3　Crystal方法举例：Crystal Clear方法
19．4　Crystal方法的贡献
第20章　特性驱动开发
20．1　新加坡项目
20．2　FDD过程模型
20．3　超越FDD的过程描述
20．4　概念上的相似和区别
20．5　FDD的贡献
第21章　精益开发
21．1　欧洲电信
21．2　精益开发的战略基础
21．3　精益开发的起源
21．4　什么是精益开发
21．5　精益开发环境
21．6　精益开发的贡献
第22章　极限编程
22．1　XP：基础
22．2　价值和原理
22．3　XP的贡献
第23章　自适应软件开发
23．1　面向变化的生命周期
23．2　基本自适应软件开发生命周期
23．2．1　推测：启动与规划
23．2．2　协作：并发特性开发
23．2．3　学习：质量评审
23．3　领导-协作管理
23．4　ASD的贡献
第四部分　开发-个敏捷软件开发生态系统
第24章　表达生态系统
24．1　机遇和问题领域
24．2　文化领域
24．2．1　竞争型文化
24．2．2　控制型文化
24．2．3　协作型文化
24．2．4　培养型文化
24．2．5　文化的相对性
24．3　让方法学同机遇和文化相匹配
24．4　方法学的选择
24．5　表达价值和原理
第25章　设计自己的敏捷方法
25．1　对方法的期望值
25．2　方法要素和实践系统
25．2．1　保持简洁
25．2．2　实践和原则
25．3　方法设计原则
25．4　框架、模板和场景
25．4．1　阶段和阶段级生命周期框架
25．4．2　问题域模板
25．4．3　场景
25．5　敏捷方法设计步骤
25．5．1　评估项目的目标和特征
25．5．2　设计方法的框架、模板和场景
25．6　为团队定制模板
25．6．1　一种定制方法
25．6．2　根据使用情况调整模板
25．7　扩展敏捷方法
25．7．1　方法的扩展：平衡优化和适应的成分
25．7．2　协作扩展
25．7．3　体系结构和集成扩展
25．8　面向企业的敏捷方法
第26章　敏捷蜕变
26．1　混沌有序的观点
26．2　协作的价值和原理
26．3　刚好够用的方法
26．4　敏捷的级别
26．5　最后的思考
参考文献