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的文章以帮助我使自己的观点变得更加成熟。我猜你也会从它们身上发现类似的价值。