（已有19条评价）基本信息
- 原书名：The Art of Agile Development
- 原出版社： O'Reilly Media, Inc.
- 作者： James Shore Shane Warden
- 译者： 王江平
- 丛书名： 北京华章图文信息有限公司O'Reilly系列
- 出版社：机械工业出版社
- ISBN：9787111268048
- 上架时间：2009-9-29
- 出版日期：2009 年8月
- 开本：16开
- 页码：448
- 版次：1-1
- 所属分类：计算机 > 软件工程及软件方法学 > 综合
编辑推荐
本书教你如何采用XP实践，详细描述了每一种实践，然后讨论了一些原则，使你可以更改XP并创建自己的敏捷方法。尤其是，本书为敏捷开发中一些较为困难的方面(合作的需要和团队成员之间的信任)提供了解决办法。
内容简介
书籍
计算机书籍
本书为那些正在考虑应用敏捷开发来构建有价值软件的人们提供了实用的指导。现在已经有大量的书籍描述敏捷开发是什么或者为什么它能帮助软件项目成功，但很少有哪一本书能把针对开发者、管理者、测试者和客户的信息合并成一个整体，从而使其能够直接应用。.
本书为敏捷的计划、开发、交付和管理提供了严谨的建议，这些建议来自于作者多年的极限编程(Extreme Programming，XP)经验。你将看到敏捷开发过程的全景图，包括为非技术类读者准备的全面指导，以及为开发者和测试人员准备的实用技术实践。
本书为以下问题提供了明确的答案：
怎样才能采用敏捷开发?
我们真的需要结对编程吗?
汇报应该详细到什么程度?
如果无法让客户参与进来该怎么办?..
我们应该编写多少文档?
何时进行设计和架构?
作为一名非开发人员，我应如何同敏捷团队一起工作?
计算机书籍
本书为那些正在考虑应用敏捷开发来构建有价值软件的人们提供了实用的指导。现在已经有大量的书籍描述敏捷开发是什么或者为什么它能帮助软件项目成功，但很少有哪一本书能把针对开发者、管理者、测试者和客户的信息合并成一个整体，从而使其能够直接应用。.
本书为敏捷的计划、开发、交付和管理提供了严谨的建议，这些建议来自于作者多年的极限编程(Extreme Programming，XP)经验。你将看到敏捷开发过程的全景图，包括为非技术类读者准备的全面指导，以及为开发者和测试人员准备的实用技术实践。
本书为以下问题提供了明确的答案：
怎样才能采用敏捷开发?
我们真的需要结对编程吗?
汇报应该详细到什么程度?
如果无法让客户参与进来该怎么办?..
我们应该编写多少文档?
何时进行设计和架构?
作为一名非开发人员，我应如何同敏捷团队一起工作?
目录
前言.
第1部分入门
第1章为什么需要敏捷
理解成功
成功不只是如期完成
组织成功的重要性
走进敏捷
第2章如何做到敏捷
敏捷方法
不要自己炮制方法
精通之道
寻找一位导师
第3章理解XP
XP生命周期
XP团队
XP概念
第4章采用XP
XP适合我们吗
现在开始!
评估你的敏捷度
第1部分入门
第1章为什么需要敏捷
理解成功
成功不只是如期完成
组织成功的重要性
走进敏捷
第2章如何做到敏捷
敏捷方法
不要自己炮制方法
精通之道
寻找一位导师
第3章理解XP
XP生命周期
XP团队
XP概念
第4章采用XP
XP适合我们吗
现在开始!
评估你的敏捷度
译者序
关于本书
2008年初夏，当机械工业出版社华章图书信息有限公司的陈冀康先生把这本书介绍给我，并询问我愿不愿意翻译它的时候，出于对敏捷方法的喜爱和浓厚兴趣，我自然一口应允。但那时，我还没有料到这本书会是如此优秀。就我所读过的敏捷开发或极限编程方面的书籍而言，这一本无疑是最好的。当然，这并非平白无故，用原作者的话说，他们是“站在多位巨人而不是一位巨人的肩膀上”。.
本书介绍了敏捷价值、敏捷原则，以及各种极限编程(XP)实践。并围绕着XP这一特定的敏捷过程，详细讨论了敏捷开发方法的方方面面：需求、分析、设计、计划、编码、发布……最后，作者提供了大量的建议，引导软件开发者在掌握了敏捷开发艺术的基础上，如何根据实际情况，定制出更适合自身的敏捷方法或敏捷过程。
翻译本书使我由衷地叹服两位作者丰富的经验、缜密的思维和循循善诱的讲解。很少有哪一本书能像本书这样把针对开发者、管理者、测试者、客户和所有利益相关者的内容严丝合缝地融合到一起。假如你对敏捷过程或XP实践有疑问，我相信你都能从本书中找到答案。
说到敏捷开发，人们很容易联想到另一本重量级的作品：Robert Martin的《Agile Software Development：Principles，Patterns，and Practices》。本书的内容跟上面这一本有很大的不同。本书并没有花笔墨在OO设计模式和OO设计原则上。事实上，本书没有详述关于程序设计和程序开发的任何具体技术，也没有详述版本控制、过程管理或缺陷跟踪等方面的任何具体工具。在这些具体工具和技术的问题上，作者只是在教我们如何选择它们，并在敏捷开发过程中有效地运用它们。
另外，读者大可不必被书中“哲学”和“艺术”等字眼吓倒。哲学艺术本就是生活中无处不在的东西，更不要说在软件开发这种创造性的过程中了。静下心来读一读，你会发现，作者的讲解是非常实在的，尽管不一定完全实用(对你的特定情形而言)。
关于术语
关于术语的翻译，只要已有书籍或文献中已经有普遍接受的译法，而且表意没有太大的偏差，本书一概沿用。但下面几个术语的翻译有必要解释一下：
Heuristics：这一词在许多文献中翻译成“启发式方法”，本书结合上下文，翻译成了“试探法”。
Planning：Plan用作动词时，许多人认为翻译成“计划制定”或“规划”更准确一些。但细想下来，又觉得“计划制定”过于啰嗦，而“规划”则有点偏离了原味。考虑到“计划”在汉语中同样可以用做动词，译者便直接用“计划”一词来翻译名词和动词两种情况。比如，本书中说“迭代计划”和“发布计划”，而不说“制定迭代计划”或“发布规划”。
Stakeholder：这似乎是近年刚流行起来的一个词，一般表示共同承担风险、共同获取利益的各方。按照作者的说法，在软件开发中，stakeholder包括终端用户、购买者、经理、执行官等。译者实在想不出一个更加通顺的译法，遂决定跟随主流，将它译成了“利益攸关者”。
Story：同样想不出更合适的译法，又不想认同个别已有的译法。译者将该词照字翻译为“故事”，这样，就算是不准确，至少能让细心的读者“推想”出英文原词，从而方便理解。
Planning Game：有个别书籍将该词译为“计划游戏”。按照本书原作者的意思，“Planning Game”的提法是从“Game Theory”(博弈论)中引申而来。所以，译者将该词译为“计划博弈”。
另外，对于重要的术语，本书都在相关词语后面的扩号内附上了英文原词，以辅助读者阅读理解。..
关于参考文献
原作者在书中提到了大量的书籍文献。对于它们的名字或标题，“翻译”时译者采用了“原文为主、中文为辅”的方式，即使用原文名字为主，同时在扩号中适当翻译一下。这可以方便读者按标题检索这些书籍或文献。
对于书籍，只要有中译本引进而且译者能查到，那么中译本的书名也被一并附在译文中，以方便感兴趣的读者购买它们。
关子勘误
本书英文原版出版后原作者发表在配套网站(http：／／patterns．cs．up．ac．za／)上面的勘误内容在翻译时已经修正。
致谢
2008年初夏，当机械工业出版社华章图书信息有限公司的陈冀康先生把这本书介绍给我，并询问我愿不愿意翻译它的时候，出于对敏捷方法的喜爱和浓厚兴趣，我自然一口应允。但那时，我还没有料到这本书会是如此优秀。就我所读过的敏捷开发或极限编程方面的书籍而言，这一本无疑是最好的。当然，这并非平白无故，用原作者的话说，他们是“站在多位巨人而不是一位巨人的肩膀上”。.
本书介绍了敏捷价值、敏捷原则，以及各种极限编程(XP)实践。并围绕着XP这一特定的敏捷过程，详细讨论了敏捷开发方法的方方面面：需求、分析、设计、计划、编码、发布……最后，作者提供了大量的建议，引导软件开发者在掌握了敏捷开发艺术的基础上，如何根据实际情况，定制出更适合自身的敏捷方法或敏捷过程。
翻译本书使我由衷地叹服两位作者丰富的经验、缜密的思维和循循善诱的讲解。很少有哪一本书能像本书这样把针对开发者、管理者、测试者、客户和所有利益相关者的内容严丝合缝地融合到一起。假如你对敏捷过程或XP实践有疑问，我相信你都能从本书中找到答案。
说到敏捷开发，人们很容易联想到另一本重量级的作品：Robert Martin的《Agile Software Development：Principles，Patterns，and Practices》。本书的内容跟上面这一本有很大的不同。本书并没有花笔墨在OO设计模式和OO设计原则上。事实上，本书没有详述关于程序设计和程序开发的任何具体技术，也没有详述版本控制、过程管理或缺陷跟踪等方面的任何具体工具。在这些具体工具和技术的问题上，作者只是在教我们如何选择它们，并在敏捷开发过程中有效地运用它们。
另外，读者大可不必被书中“哲学”和“艺术”等字眼吓倒。哲学艺术本就是生活中无处不在的东西，更不要说在软件开发这种创造性的过程中了。静下心来读一读，你会发现，作者的讲解是非常实在的，尽管不一定完全实用(对你的特定情形而言)。
关于术语
关于术语的翻译，只要已有书籍或文献中已经有普遍接受的译法，而且表意没有太大的偏差，本书一概沿用。但下面几个术语的翻译有必要解释一下：
Heuristics：这一词在许多文献中翻译成“启发式方法”，本书结合上下文，翻译成了“试探法”。
Planning：Plan用作动词时，许多人认为翻译成“计划制定”或“规划”更准确一些。但细想下来，又觉得“计划制定”过于啰嗦，而“规划”则有点偏离了原味。考虑到“计划”在汉语中同样可以用做动词，译者便直接用“计划”一词来翻译名词和动词两种情况。比如，本书中说“迭代计划”和“发布计划”，而不说“制定迭代计划”或“发布规划”。
Stakeholder：这似乎是近年刚流行起来的一个词，一般表示共同承担风险、共同获取利益的各方。按照作者的说法，在软件开发中，stakeholder包括终端用户、购买者、经理、执行官等。译者实在想不出一个更加通顺的译法，遂决定跟随主流，将它译成了“利益攸关者”。
Story：同样想不出更合适的译法，又不想认同个别已有的译法。译者将该词照字翻译为“故事”，这样，就算是不准确，至少能让细心的读者“推想”出英文原词，从而方便理解。
Planning Game：有个别书籍将该词译为“计划游戏”。按照本书原作者的意思，“Planning Game”的提法是从“Game Theory”(博弈论)中引申而来。所以，译者将该词译为“计划博弈”。
另外，对于重要的术语，本书都在相关词语后面的扩号内附上了英文原词，以辅助读者阅读理解。..
关于参考文献
原作者在书中提到了大量的书籍文献。对于它们的名字或标题，“翻译”时译者采用了“原文为主、中文为辅”的方式，即使用原文名字为主，同时在扩号中适当翻译一下。这可以方便读者按标题检索这些书籍或文献。
对于书籍，只要有中译本引进而且译者能查到，那么中译本的书名也被一并附在译文中，以方便感兴趣的读者购买它们。
关子勘误
本书英文原版出版后原作者发表在配套网站(http：／／patterns．cs．up．ac．za／)上面的勘误内容在翻译时已经修正。
致谢
前言
问：你如何到达卡耐基音乐大厅?.
答：实践，朋友，实践!
我们想帮你掌握敏捷开发(Agile Development)的艺术。
敏捷开发，跟其他任何基于团队的软件开发方法一样，从根本上讲是一门人类艺术，一门受制于个体的奇特行为及其交互协作的艺术。要掌握敏捷开发，你必须学会估计无数的可能性，每时每刻，并凭借直觉选出最佳的行动方案。
你怎样才可能学会如此困难的一种技能呢?实践!
首先，也是最重要的，本书详细描述了实践敏捷开发的一种方法：极限编程(Extreme Programming，XP)。它是这样的一种实践指导：如果你保持遵循它，它能使你以XP的形式成功地将敏捷开发引入你的团队——或者能帮你确定对于你的情况来说它并不是一个好选择。
我们的第二个目的是帮你掌握敏捷开发的艺术。要掌握敏捷，意味着超越我们所列出的实践方法。敏捷开发与具体环境的关系十分紧密，不可能有一种方法完全适合所有的情况，敏捷开发也十分精妙，任何一本书都不可能教会你怎样精通它。精通来自于经验，也来自于对一种选择所能引发的后果有直觉的理解。
你的选择会在组织范围内引起怎样的后果，这个我们无法教给你。我们也不试图教你这些。必须提供细微差别以及相关理解的是你自己。这是掌握艺术的唯一方法。遵循这些实践，观察发生的结果，思考它们为什么能起作用……或者不起作用。然后再次实践它们。哪些结果是相同的?哪些不同?为什么?然后再次实践它们。再次实践它们。
对于如何展开每种实践，开始的时候你理解起来可能很吃力。敏捷开发或许看起来容易，但将它们投入实际行动就不是那么容易了。要坚持实践，直到它们变得容易。
随着XP变得容易，你会发现我们给出的某些规则并不适合于你。开始的时候，你会无法确定问题是出在我们的规则上面，还是出在你遵循它们的方式上面。坚持实践，直到你有了确定的答案。当你确定之后，就可以打破规则。修改我们给出的指导方法，使之更适合你的具体情况。
本书的第一部分和第二部分包含我们实践XP的方法。第一部分帮你开始极限编程之旅，第二部分对每种XP实践提供了详细指导。第一部分和第二部分的内容就足以使你忙上好几个月了。
当你准备好打破规则的时候，就转向第三部分。提醒一句：第三部分中没有任何内容是帮你实践XP的。相反，这一部分的内容都是帮你深入理解XP和敏捷开发思想的。
有一天你会发现规则不再使你感兴趣。毕竟，XP和敏捷开发不是关于遵循规则的。“它是关于简单和反馈、沟通和信任的”，你会想，“它是关于交付价值——并有勇气在正确的时间做正确的事情。”你将估计无数的可能性，每时每刻，并凭借直觉选出最佳的行动方案。
当你能达到这种水平的时候，就把这本书传给别人看吧，尽管它的纸张已经卷角了或者破损了，这样另外一个人也能掌握敏捷开发的艺术。
致实用主义者
如果你并不想掌握一门所谓的艺术，你只是想开发出好的软件，那该怎么做呢?
不必担心，本书仍然适合你。第一部分和第二部分正是你需要的。在这两部分中，我们阐释了多年的敏捷开发和极限编程经验，并把它们浓缩成了一个个单一的、明确定义的、综合的方法。
这种方法使我们能够使用简单直接的语言，而不必附加许多限定说明或扯到细枝末节上。我们在最终的内容中包含了大量实用的小技巧。我们清晰地描述我们给出的方法何时不起作用，以及当它不起作用时有哪些替代方法可以考虑。
只讨论一种方法有一个缺点：没有单独的一套方法能适合所有的人。我们的建议对你的团队或者你的情况来说可能并不适合。在将我们的建议投入实践之前一定要阅读第4章。
即使你不能采用所有的XP方法，你也可以采用它的一部分。第二部分中，每一种实践的“禁忌”一节都描述了什么时候一种实践会不适合。如果这符合你的情形，“更多选择”一节能帮你确定正确的做法会是怎样的。
答：实践，朋友，实践!
我们想帮你掌握敏捷开发(Agile Development)的艺术。
敏捷开发，跟其他任何基于团队的软件开发方法一样，从根本上讲是一门人类艺术，一门受制于个体的奇特行为及其交互协作的艺术。要掌握敏捷开发，你必须学会估计无数的可能性，每时每刻，并凭借直觉选出最佳的行动方案。
你怎样才可能学会如此困难的一种技能呢?实践!
首先，也是最重要的，本书详细描述了实践敏捷开发的一种方法：极限编程(Extreme Programming，XP)。它是这样的一种实践指导：如果你保持遵循它，它能使你以XP的形式成功地将敏捷开发引入你的团队——或者能帮你确定对于你的情况来说它并不是一个好选择。
我们的第二个目的是帮你掌握敏捷开发的艺术。要掌握敏捷，意味着超越我们所列出的实践方法。敏捷开发与具体环境的关系十分紧密，不可能有一种方法完全适合所有的情况，敏捷开发也十分精妙，任何一本书都不可能教会你怎样精通它。精通来自于经验，也来自于对一种选择所能引发的后果有直觉的理解。
你的选择会在组织范围内引起怎样的后果，这个我们无法教给你。我们也不试图教你这些。必须提供细微差别以及相关理解的是你自己。这是掌握艺术的唯一方法。遵循这些实践，观察发生的结果，思考它们为什么能起作用……或者不起作用。然后再次实践它们。哪些结果是相同的?哪些不同?为什么?然后再次实践它们。再次实践它们。
对于如何展开每种实践，开始的时候你理解起来可能很吃力。敏捷开发或许看起来容易，但将它们投入实际行动就不是那么容易了。要坚持实践，直到它们变得容易。
随着XP变得容易，你会发现我们给出的某些规则并不适合于你。开始的时候，你会无法确定问题是出在我们的规则上面，还是出在你遵循它们的方式上面。坚持实践，直到你有了确定的答案。当你确定之后，就可以打破规则。修改我们给出的指导方法，使之更适合你的具体情况。
本书的第一部分和第二部分包含我们实践XP的方法。第一部分帮你开始极限编程之旅，第二部分对每种XP实践提供了详细指导。第一部分和第二部分的内容就足以使你忙上好几个月了。
当你准备好打破规则的时候，就转向第三部分。提醒一句：第三部分中没有任何内容是帮你实践XP的。相反，这一部分的内容都是帮你深入理解XP和敏捷开发思想的。
有一天你会发现规则不再使你感兴趣。毕竟，XP和敏捷开发不是关于遵循规则的。“它是关于简单和反馈、沟通和信任的”，你会想，“它是关于交付价值——并有勇气在正确的时间做正确的事情。”你将估计无数的可能性，每时每刻，并凭借直觉选出最佳的行动方案。
当你能达到这种水平的时候，就把这本书传给别人看吧，尽管它的纸张已经卷角了或者破损了，这样另外一个人也能掌握敏捷开发的艺术。
致实用主义者
如果你并不想掌握一门所谓的艺术，你只是想开发出好的软件，那该怎么做呢?
不必担心，本书仍然适合你。第一部分和第二部分正是你需要的。在这两部分中，我们阐释了多年的敏捷开发和极限编程经验，并把它们浓缩成了一个个单一的、明确定义的、综合的方法。
这种方法使我们能够使用简单直接的语言，而不必附加许多限定说明或扯到细枝末节上。我们在最终的内容中包含了大量实用的小技巧。我们清晰地描述我们给出的方法何时不起作用，以及当它不起作用时有哪些替代方法可以考虑。
只讨论一种方法有一个缺点：没有单独的一套方法能适合所有的人。我们的建议对你的团队或者你的情况来说可能并不适合。在将我们的建议投入实践之前一定要阅读第4章。
即使你不能采用所有的XP方法，你也可以采用它的一部分。第二部分中，每一种实践的“禁忌”一节都描述了什么时候一种实践会不适合。如果这符合你的情形，“更多选择”一节能帮你确定正确的做法会是怎样的。
