（已有7条评价）基本信息
- 原书名：Scaling Software Agility: Best Practices for Large Enterprises
- 原出版社： Addison-Wesley Professional
- 作者： (美)Dean Leffingwell
- 译者： 李冬冬 冯雁 娄嘉鹏
- 丛书名： 软件工程研究院
- 出版社：电子工业出版社
- ISBN：9787121082160
- 上架时间：2009-5-16
- 出版日期：2009 年5月
- 开本：16开
- 页码：304
- 版次：1-1
- 所属分类：计算机 > 软件工程及软件方法学 > 综合
编辑推荐
国内首部聚焦可伸缩敏捷开发的大师译著.
深度破解敏捷开发无法大型化的传统误区...
内容简介
书籍
计算机书籍
敏捷开发实践虽然在一些圈子内仍然存在着争议，但是它却给我们带来了不可否认的益处，例如：更加快速地向市场交付、更好地响应变化的客户需求以及提供更高的软件质量。然而，敏捷方法一直定义或者推荐在小型团队中应用。在 《可伸缩敏捷开发（Scaling Software Agility ）》这本书中，Dean Leffingwell 介绍了如何将敏捷方法应用于企业级的开发上。.
第 1 部分介绍了最通用且最有效的敏捷方法。
第 2 部分介绍了扩展到企业级规模的7个敏捷最佳实践。 ..
第 3 部分介绍了公司所能掌握的获得企业范围内软件敏捷性全部好处的另外一套实践，即7个组织能力。
该书对于软件开发人员、测试人员及 QA 人员、经理和团队领导，以及软件组织的执行人员是非常有价值的，这些组织的目标是提高软件开发过程的质量和生产率，但是这些组织面临着在企业范围内开发软件的所有挑战。...
计算机书籍
敏捷开发实践虽然在一些圈子内仍然存在着争议，但是它却给我们带来了不可否认的益处，例如：更加快速地向市场交付、更好地响应变化的客户需求以及提供更高的软件质量。然而，敏捷方法一直定义或者推荐在小型团队中应用。在 《可伸缩敏捷开发（Scaling Software Agility ）》这本书中，Dean Leffingwell 介绍了如何将敏捷方法应用于企业级的开发上。.
第 1 部分介绍了最通用且最有效的敏捷方法。
第 2 部分介绍了扩展到企业级规模的7个敏捷最佳实践。 ..
第 3 部分介绍了公司所能掌握的获得企业范围内软件敏捷性全部好处的另外一套实践，即7个组织能力。
该书对于软件开发人员、测试人员及 QA 人员、经理和团队领导，以及软件组织的执行人员是非常有价值的，这些组织的目标是提高软件开发过程的质量和生产率，但是这些组织面临着在企业范围内开发软件的所有挑战。...
作译者
Dean Leffingwell是一位知名的软件开发方法论者和作者，也是一个软件团队指导，他用自己的经历帮助软件开发团队实现他们的目标。他是Requisite公司的创始人和前CEO，是RequisitePro的创造者，也是Rational公司的前副总裁并在Rational公司负责RUP商业化。在过去的五年里，他的工作角色是独立顾问，并担任Rally软件公司的顾问兼方法论者。Leffingwell先生致力于将敏捷方法应用于跨国公司分布式大型开发团队，他以在此过程中获得的经验为基础，写成了此书。Leffingwell先生也是《软件需求管理：用例方法（第2版）》（Addison-Wesley公司，2003）的第一作者。...
目录
第1部分 软件敏捷概述.
第1章 敏捷方法介绍 5
1.1 在软件经济中获得竞争优势 5
软件开发方法与行业一起发展 5
1.2 走进敏捷方法 6
1.3 敏捷的规模 7
1.4 了解敏捷方法 8
敏捷宣言 9
1.5 采用敏捷方法的趋势 10
1.6 软件敏捷的企业效益 11
1.6.1 提高生产力 11
1.6.2 提高质量 12
1.6.3 提升团队士气和工作满意度 12
1.6.4 更快地面市 12
1.7 XP、Scrum及RUP的简介 13
1.7.1 极限编程（XP） 13
1.7.2 Scrum 13
1.7.3 Rational统一过程 14
1.8 小结 15
第2章 为什么瀑布模型不适用 17
第1章 敏捷方法介绍 5
1.1 在软件经济中获得竞争优势 5
软件开发方法与行业一起发展 5
1.2 走进敏捷方法 6
1.3 敏捷的规模 7
1.4 了解敏捷方法 8
敏捷宣言 9
1.5 采用敏捷方法的趋势 10
1.6 软件敏捷的企业效益 11
1.6.1 提高生产力 11
1.6.2 提高质量 12
1.6.3 提升团队士气和工作满意度 12
1.6.4 更快地面市 12
1.7 XP、Scrum及RUP的简介 13
1.7.1 极限编程（XP） 13
1.7.2 Scrum 13
1.7.3 Rational统一过程 14
1.8 小结 15
第2章 为什么瀑布模型不适用 17
前言
软件方法论生涯的第1阶段：在RELA 和Requisite公司的经历.
在我的职业生涯中，我一直致力于改进软件工程及软件开发管理实践方法。即使这是一个需要持续努力的目标，但是现在我根据我对软件开发实践方法的理解，将我的经历总结为3个不同的阶段。在第1个阶段，我是RELA公司的首席执行官，在这个公司我们与他人签订合同为其开发软件。RELA开发各种各样的软件应用程序，从令人反胃的冒险乐园骑乘设备到维持生命的医疗设备。因为总是为他人编写软件，我们逐渐意识到需要“建立正确的东西”。个人的生计、我们的公司及其他利益相关者都依赖于我们理解方案需要解决什么问题的能力，以及在实现方案时怎样应用有效的最佳实践方法的能力。
为了做到这一点，那个时候我们使用严格的基于瀑布模型的实践方法。事实上，我们的一些客户及FDA（美国食品和药物管理局）等一些主要监管机构指定使用这种方法，因此，我们遵照要求使用这种方法，并且曾试图对其进行改进。虽然现在我们中的很多人以批评和取笑我们曾使用的方法为乐，但事实是瀑布方法比起过去的试验性方法是一个极大的进步。更重要的是，使用这种方法能够交付成果。当时，我主要关注需求过程，因为在这个过程中，要进行重要的分析，要定义解决方案并且要作为合同的基础。
这段经历促使我进入了下一个职业，担任Requisite公司的创始人和总裁，并开发了产品需求管理的解决方案RequisitePro。在Requisite公司，我们提出并且开发了需求实践方法和产品，因此，在一定意义上成为软件生命周期前端的专家。在1997年我们将Requisite出售给了Rational公司，接着我开始了软件开发过程职业生涯的第2个阶段。
软件方法论生涯的第2阶段：在Rational软件公司的经历
在这个阶段，我是Rational软件公司的一名高级行政人员，参与了统一建模语言（Unified Modeling Language，UML ）和Rational统一过程（Rational Unified Process，RUP）的颁布。在Rational软件公司，我有幸与Grady Booch、Ivar Jacobson、James Rumbaugh、Walker Royce和Philippe Kruchten等软件思想领袖一起工作。在这段时间内，Don Widrig和我也出版了Addison-Wesley教材《管理软件需求》的第1版（2000）。
接着，我们开始考虑基于面向对象技术，这项技术为我们的开发方法提供了更多的灵活性，为我们所编写的软件提供了更多的伸缩性。同时也带来了一种新的软件开发过程，这个过程完全不同于瀑布模型，它的特点是迭代和增量。在此方法中，每一次迭代是编写一段可以被客观地估量和评价的代码。这种方法远比我以前使用的方法敏捷：我们不必依靠文件和设计审查等类的中间产品，就可以看到和衡量实际工作的进展。
Rational公司在一份书面过程描述中，将这个过程命名为Rational统一过程（Rational Unified Process），之后，它的销售和应用在整个行业内获得了成功。此外，在需要4个国家多达800人的团队成员合作的项目开发与发布中，我们也应用了这个过程。Rational Suites每年发布两次，每一次都是一套集成的产品和一个共同的安装程序。Rational最终被IBM公司购买，今天RUP的销售由IBM的Rational软件事业部（Rational Software Division）负责，数十万的从业人员都在使用它。..
软件方法论生涯的第3阶段：使用敏捷和在Rally公司的经历
离开Rational公司之后，我成为发展阶段软件企业的独立顾问和指导，我指导6个新企业的经营策略和软件开发实践。我利用这个机会应用一些更为创新的、轻量级的方法，包括XP和Scrum ，并亲眼目睹了这些方法给小规模团队所带来的工作效率和质量的改进。
经过一段短暂的时间，这些方法征服了我，因此，很快我开始拒绝参加不理解敏捷方法的任何企业或者团队。否则企业的风险太大了！在同一时间，我开始觉察到这些方法的局限性。随着团队和应用程序的扩大，团队重构代码变得不切实际，并且我们也注意到，需要更多地保证需求的沟通。在这个时候，我还是Rally软件公司的专家顾问，帮助发展其分布式敏捷开发的安置解决方案。在Rally软件公司，与Ryan Martens、Ken Schwaber、Jim Highsmith、Mike Cohn、Tom、Mary Poppendieck和Jeff Sutherland等敏捷思想领导者的交流对我产生了重大影响。
在企业级规模应用敏捷的经历
此时，我遇到了在一些大型组织中应用敏捷方法的挑战。我很不安地接受了这项任务，并在接下来的几年内，将敏捷的核心原则应用到大型组织中，同时也应用了我在BMC软件公司的大规模开发的经验。在BMC软件公司，我们曾为交付超大规模的新应用程序与数以百计的高度分布的开发人员一起工作。
在这个过程中，我很高兴地发现敏捷方法所提供的很多最佳实践方法给企业带来了立竿见影的价值。同时，我也发现这些最佳实践方法并不能完全解决企业规模的挑战。因此，我们逐渐形成了获得更好的敏捷所必需的一套扩展实践方法。当我发现市场上几乎没有出版物可供大型公司阅读参考时，我下定决心写这本书。我这样做是希望你的企业可以吸取我们的经验，并应用这些经验给客户提供更高的生产力和更好的品质。在软件占主导地位的世界中，很难想象我们的行业是在一个较高的支点上，确实，我们的经济是一个整体。
如何阅读本书
第1部分：软件敏捷概述
本书共分为3部分。第1部分介绍了敏捷运动的简短历史，讨论了一些目前使用的主要敏捷方法，包括XP和Scrum，也讨论了应用在敏捷方式中的RUP，RUP是一种迭代和增量方法。此外，我们也简要地介绍了其他一些促进敏捷运动的方法，包括精益软件开发（Lean Software Development）、动态系统开发方法（Dynamic System Development Method，DSDM），以及特性驱动开发（Feature-Driven Development，FDD）。我们介绍这些方法并不是为了教授这些方法本身，而是为理解第2部分和第3部分的内容打下基础。你会发现，每一种方法都为软件开发实践带来了大量的新思路，每一种方法都为技术发展做出了重大贡献。此外，你也将看到形成了一套最佳敏捷实践方法，其中的许多方法都已经得到大规模应用，我们将利用这些作为建立企业敏捷性的基础。
第2部分：7种可伸缩的敏捷团队实践
第2部分介绍了可伸缩的7种敏捷团队实践方法，每章介绍一种。从一定意义上讲，这些实践方法可以被视为敏捷的本质，因为所有的敏捷方法都明确或含蓄地应用了这些实践。对于那些刚刚涉入敏捷方法的人或者意图实施这些实践的大机构来说，本书的第2部分应该是些安慰，因为通过理解所描述的一些敏捷方法，或者更进一步，基于公司的背景进行一些必要的融合和匹配，这些最佳实践方法很自然就出现了并为在任何范围内的实际应用提供了益处。这些方法不是微不足道的，它们的作用已经在各种各样的项目背景中得到了证实，采用这些方法的所有团队都将受益。
本书第1部分和第2部分介绍了软件敏捷的概要，并描述了可以应用在任何规模的7种最佳实践方法，每个实践方法都可以直接并且立即促进采用此方法的团队的生产力和成果的质量。
在我的职业生涯中，我一直致力于改进软件工程及软件开发管理实践方法。即使这是一个需要持续努力的目标，但是现在我根据我对软件开发实践方法的理解，将我的经历总结为3个不同的阶段。在第1个阶段，我是RELA公司的首席执行官，在这个公司我们与他人签订合同为其开发软件。RELA开发各种各样的软件应用程序，从令人反胃的冒险乐园骑乘设备到维持生命的医疗设备。因为总是为他人编写软件，我们逐渐意识到需要“建立正确的东西”。个人的生计、我们的公司及其他利益相关者都依赖于我们理解方案需要解决什么问题的能力，以及在实现方案时怎样应用有效的最佳实践方法的能力。
为了做到这一点，那个时候我们使用严格的基于瀑布模型的实践方法。事实上，我们的一些客户及FDA（美国食品和药物管理局）等一些主要监管机构指定使用这种方法，因此，我们遵照要求使用这种方法，并且曾试图对其进行改进。虽然现在我们中的很多人以批评和取笑我们曾使用的方法为乐，但事实是瀑布方法比起过去的试验性方法是一个极大的进步。更重要的是，使用这种方法能够交付成果。当时，我主要关注需求过程，因为在这个过程中，要进行重要的分析，要定义解决方案并且要作为合同的基础。
这段经历促使我进入了下一个职业，担任Requisite公司的创始人和总裁，并开发了产品需求管理的解决方案RequisitePro。在Requisite公司，我们提出并且开发了需求实践方法和产品，因此，在一定意义上成为软件生命周期前端的专家。在1997年我们将Requisite出售给了Rational公司，接着我开始了软件开发过程职业生涯的第2个阶段。
软件方法论生涯的第2阶段：在Rational软件公司的经历
在这个阶段，我是Rational软件公司的一名高级行政人员，参与了统一建模语言（Unified Modeling Language，UML ）和Rational统一过程（Rational Unified Process，RUP）的颁布。在Rational软件公司，我有幸与Grady Booch、Ivar Jacobson、James Rumbaugh、Walker Royce和Philippe Kruchten等软件思想领袖一起工作。在这段时间内，Don Widrig和我也出版了Addison-Wesley教材《管理软件需求》的第1版（2000）。
接着，我们开始考虑基于面向对象技术，这项技术为我们的开发方法提供了更多的灵活性，为我们所编写的软件提供了更多的伸缩性。同时也带来了一种新的软件开发过程，这个过程完全不同于瀑布模型，它的特点是迭代和增量。在此方法中，每一次迭代是编写一段可以被客观地估量和评价的代码。这种方法远比我以前使用的方法敏捷：我们不必依靠文件和设计审查等类的中间产品，就可以看到和衡量实际工作的进展。
Rational公司在一份书面过程描述中，将这个过程命名为Rational统一过程（Rational Unified Process），之后，它的销售和应用在整个行业内获得了成功。此外，在需要4个国家多达800人的团队成员合作的项目开发与发布中，我们也应用了这个过程。Rational Suites每年发布两次，每一次都是一套集成的产品和一个共同的安装程序。Rational最终被IBM公司购买，今天RUP的销售由IBM的Rational软件事业部（Rational Software Division）负责，数十万的从业人员都在使用它。..
软件方法论生涯的第3阶段：使用敏捷和在Rally公司的经历
离开Rational公司之后，我成为发展阶段软件企业的独立顾问和指导，我指导6个新企业的经营策略和软件开发实践。我利用这个机会应用一些更为创新的、轻量级的方法，包括XP和Scrum ，并亲眼目睹了这些方法给小规模团队所带来的工作效率和质量的改进。
经过一段短暂的时间，这些方法征服了我，因此，很快我开始拒绝参加不理解敏捷方法的任何企业或者团队。否则企业的风险太大了！在同一时间，我开始觉察到这些方法的局限性。随着团队和应用程序的扩大，团队重构代码变得不切实际，并且我们也注意到，需要更多地保证需求的沟通。在这个时候，我还是Rally软件公司的专家顾问，帮助发展其分布式敏捷开发的安置解决方案。在Rally软件公司，与Ryan Martens、Ken Schwaber、Jim Highsmith、Mike Cohn、Tom、Mary Poppendieck和Jeff Sutherland等敏捷思想领导者的交流对我产生了重大影响。
在企业级规模应用敏捷的经历
此时，我遇到了在一些大型组织中应用敏捷方法的挑战。我很不安地接受了这项任务，并在接下来的几年内，将敏捷的核心原则应用到大型组织中，同时也应用了我在BMC软件公司的大规模开发的经验。在BMC软件公司，我们曾为交付超大规模的新应用程序与数以百计的高度分布的开发人员一起工作。
在这个过程中，我很高兴地发现敏捷方法所提供的很多最佳实践方法给企业带来了立竿见影的价值。同时，我也发现这些最佳实践方法并不能完全解决企业规模的挑战。因此，我们逐渐形成了获得更好的敏捷所必需的一套扩展实践方法。当我发现市场上几乎没有出版物可供大型公司阅读参考时，我下定决心写这本书。我这样做是希望你的企业可以吸取我们的经验，并应用这些经验给客户提供更高的生产力和更好的品质。在软件占主导地位的世界中，很难想象我们的行业是在一个较高的支点上，确实，我们的经济是一个整体。
如何阅读本书
第1部分：软件敏捷概述
本书共分为3部分。第1部分介绍了敏捷运动的简短历史，讨论了一些目前使用的主要敏捷方法，包括XP和Scrum，也讨论了应用在敏捷方式中的RUP，RUP是一种迭代和增量方法。此外，我们也简要地介绍了其他一些促进敏捷运动的方法，包括精益软件开发（Lean Software Development）、动态系统开发方法（Dynamic System Development Method，DSDM），以及特性驱动开发（Feature-Driven Development，FDD）。我们介绍这些方法并不是为了教授这些方法本身，而是为理解第2部分和第3部分的内容打下基础。你会发现，每一种方法都为软件开发实践带来了大量的新思路，每一种方法都为技术发展做出了重大贡献。此外，你也将看到形成了一套最佳敏捷实践方法，其中的许多方法都已经得到大规模应用，我们将利用这些作为建立企业敏捷性的基础。
第2部分：7种可伸缩的敏捷团队实践
第2部分介绍了可伸缩的7种敏捷团队实践方法，每章介绍一种。从一定意义上讲，这些实践方法可以被视为敏捷的本质，因为所有的敏捷方法都明确或含蓄地应用了这些实践。对于那些刚刚涉入敏捷方法的人或者意图实施这些实践的大机构来说，本书的第2部分应该是些安慰，因为通过理解所描述的一些敏捷方法，或者更进一步，基于公司的背景进行一些必要的融合和匹配，这些最佳实践方法很自然就出现了并为在任何范围内的实际应用提供了益处。这些方法不是微不足道的，它们的作用已经在各种各样的项目背景中得到了证实，采用这些方法的所有团队都将受益。
本书第1部分和第2部分介绍了软件敏捷的概要，并描述了可以应用在任何规模的7种最佳实践方法，每个实践方法都可以直接并且立即促进采用此方法的团队的生产力和成果的质量。
序言
如果你刚刚涉入敏捷方法的领域，那么打开这本书时你可能会充满忧虑和怀疑，这不足为怪。关于敏捷方法似乎有一些奇怪的表述，例如，冲刺（sprint ）、速度（velocity）、并列争球（scrum）（这是橄榄球比赛吗？）、极限编程（extreme programming）（我们是穿着滑雪板跳过悬崖吗？）、用户故事（user stories）、事迹和传奇（epics and sagas）（这是作家工作室吗？）等，还有一些怪异的社交形式，例如，结对编程（pair programming）、用户审查（user retrospectives）、聚集或者每日站立例会（huddles or daily stand-up meetings）（开发人员和测试人员在工作中互相拥抱吗？）等。敏捷团队似乎也消耗大量的彩色便签和4×6索引卡，他们在可以触及的任何墙面贴满了这些东西，整个事情似乎都不太对劲。这一切似乎是Scott Adams的Dilbert漫画的好素材！但是请不要误会：敏捷软件开发过程就是“穿越鸿沟”，这里用到了Jeffrey Moore创造的一个术语。我们今天已经远远不再是说些搞笑且令人讨厌的行话了，而是形成了有效的、有生产力的并且可扩展的开发方法。你必须向前迈进，否则就要落后。.
另外，你可能看到或听说过，敏捷开发通常是反对“计划驱动”开发的，你可能认为这是一件非常混乱或者无法无天的事情，比起既系统又有计划的行动倒退了一大步。但是实际上，敏捷项目是经过精心策划的，只是他们的计划不同，并且该计划的修订和完善更为频繁。可能也有人告诉过你，敏捷方法能够很好地支持小型团队（7~12人）、短期项目（2~9个月），但是它不能适用于大型的、长期的和分布在全球各地的软件开发项目。然而，请你不要合上这本书。随着世界各地的众多项目对这些界限的推动，以及敏捷在软件成果的高生产力和高质量方面取得的成功，一切都在快速地变化。
这就是Dean Leffingwell在本书中的重要贡献，他以XP、Scrum、Lean、DSDM、FDD、Unified Process等不同的敏捷过程之间的争论为基础，找到了这些方法之间的共性并作为基准，然后才进入他的主要目标，说明如何扩展这些敏捷方法并使其超越当前的适用范围。他不是在本已很长的名册中补充一个新的敏捷过程方法，相反，他利用一套新的实践方法扩展了敏捷方法，并把这些包括技术和管理在内的更高层次的实践方法融合集成到现有的已经建立的敏捷实践方法（名字很有趣）中。除了综合并且扩充了敏捷方法中所共有的最佳工程实践方法之外，他还描述了用于大型敏捷项目管理的方法：发布计划等主题，协调大规模的分布式团队，建立项目的企业价值观，处理大型的、长生命周期的开发过程，等等，我这里仅举这几例。..
作者的工作不是学术性的，他不只是提出一些新的、大胆的猜测让你去尝试。他的建议根植于他多年积极的自身实践，这些实践来自于许多公司的众多项目，所涉及的行业范围极为广泛，从维持生命的医疗设备到软件工具，从游乐园骑乘设备到大型IT基础设施的应用。我知道这第一手资料是因为我曾有幸先后在Rational Software公司和Rally Software Development公司与Dean一起工作了大约10年。
我再补充一句我自己的建议。看完这本书后（可能有很多人都在寻求好的方法），不要期望像食谱中的配方一样能够立即使用并且肯定成功。房地产商的座右铭是“位置，位置，位置”，我想说，采用新的软件开发实践方法的关键是“背景，背景，背景”。了解你的背景，将其与Leffingwell所介绍的背景相比；了解相关的目标、项目范围和规模，以及文化和改进业务的合约。然后，调整、适应和改变Dean的建议以适合你的需要。背景包括很多方面：你的领域（行业的类型），待开发系统的规模，团队的历史，他们自己的个人和集体经验或教育，所使用的技术，系统的危险程度，甚至企业和国家的文化。Dean介绍给你的东西是在他自己的背景基础上形成的，他曾有作为一个企业家、软件开发经理、主管、方法学家及顾问的经历，从这些经历中他形成了自己的一套价值观和规范。你的背景会有所不同。如果有任何疑问，就回到基本的原则，即敏捷的基本原则，包括本书所描述的那些原则，而不能被束缚在具体的术语和战术中。
我们一直在说“敏捷过程”，但是实际上，不论是正式的还是在人们头脑中所默许的描述，过程本身都不是敏捷的。人可以敏捷；团队或者组织可以敏捷。你是“敏捷的”，但是你不能“做敏捷”。如果你只是做敏捷而不是敏捷地去做，那么你就会失败，并且不会知道为什么失败，接下来你可能会将失败归咎于一些书。因此，你要跨越这个鸿沟，就不仅是决定采用“指定的”敏捷方法和/或Dean等人所描述的这样或那样的实践方法。这需要改变观念或态度，这不是很容易做的事。仅仅读一本书或者参加一个学习班是不够的。你和你的组织想要把敏捷原则变成自己的思想方式，并获得真正敏捷性的好处，你必须要尝试这些新的实践，并且是一次又一次地实践。然后，总结你自己的经验并进行反思，回头看看你已得到（或者没有得到）什么，继而再进一步调整和适应以及采用敏捷的原则。换句话说，就是不要相信一本书能够使你敏捷。它需要的不仅仅是去做，还需要思考、感觉和变化。
然而，如果你是敏捷领域里的一位老资格的人，如果在20世纪70年代你就已经了解敏捷了，那么这本书有什么给你看的呢？有很多东西值得你看。我个人学到了很多东西，并开始反思自己的经验和实践。我同意Dean写的所有内容吗？不。我的背景和我的经验与他是有些不同的，但是如果不去深究具体的战术或者词汇的话，Dean和我在大多数问题上最终都是一致的，特别是在原则和总体战略方面。（此外，他最近指出，我们似乎很享受辩论的过程和辩论本身，辩论可以作为我们明确自身思想的有效渠道，也可以作为一种了解他人想法的交流工具。）有了这一观点，我猜想，即使是最有经验的“敏捷人员”也会学到一些宝贵的经验教训。
说永远不如做。从前言开始，翻开这本书，开始阅读吧。欣赏和学习敏捷吧！...
Philippe Kruchten, Ph.D., P.Eng.
软件工程的教授，英属哥伦比亚大学（University of British Columbia），温哥华，加拿大
另外，你可能看到或听说过，敏捷开发通常是反对“计划驱动”开发的，你可能认为这是一件非常混乱或者无法无天的事情，比起既系统又有计划的行动倒退了一大步。但是实际上，敏捷项目是经过精心策划的，只是他们的计划不同，并且该计划的修订和完善更为频繁。可能也有人告诉过你，敏捷方法能够很好地支持小型团队（7~12人）、短期项目（2~9个月），但是它不能适用于大型的、长期的和分布在全球各地的软件开发项目。然而，请你不要合上这本书。随着世界各地的众多项目对这些界限的推动，以及敏捷在软件成果的高生产力和高质量方面取得的成功，一切都在快速地变化。
这就是Dean Leffingwell在本书中的重要贡献，他以XP、Scrum、Lean、DSDM、FDD、Unified Process等不同的敏捷过程之间的争论为基础，找到了这些方法之间的共性并作为基准，然后才进入他的主要目标，说明如何扩展这些敏捷方法并使其超越当前的适用范围。他不是在本已很长的名册中补充一个新的敏捷过程方法，相反，他利用一套新的实践方法扩展了敏捷方法，并把这些包括技术和管理在内的更高层次的实践方法融合集成到现有的已经建立的敏捷实践方法（名字很有趣）中。除了综合并且扩充了敏捷方法中所共有的最佳工程实践方法之外，他还描述了用于大型敏捷项目管理的方法：发布计划等主题，协调大规模的分布式团队，建立项目的企业价值观，处理大型的、长生命周期的开发过程，等等，我这里仅举这几例。..
作者的工作不是学术性的，他不只是提出一些新的、大胆的猜测让你去尝试。他的建议根植于他多年积极的自身实践，这些实践来自于许多公司的众多项目，所涉及的行业范围极为广泛，从维持生命的医疗设备到软件工具，从游乐园骑乘设备到大型IT基础设施的应用。我知道这第一手资料是因为我曾有幸先后在Rational Software公司和Rally Software Development公司与Dean一起工作了大约10年。
我再补充一句我自己的建议。看完这本书后（可能有很多人都在寻求好的方法），不要期望像食谱中的配方一样能够立即使用并且肯定成功。房地产商的座右铭是“位置，位置，位置”，我想说，采用新的软件开发实践方法的关键是“背景，背景，背景”。了解你的背景，将其与Leffingwell所介绍的背景相比；了解相关的目标、项目范围和规模，以及文化和改进业务的合约。然后，调整、适应和改变Dean的建议以适合你的需要。背景包括很多方面：你的领域（行业的类型），待开发系统的规模，团队的历史，他们自己的个人和集体经验或教育，所使用的技术，系统的危险程度，甚至企业和国家的文化。Dean介绍给你的东西是在他自己的背景基础上形成的，他曾有作为一个企业家、软件开发经理、主管、方法学家及顾问的经历，从这些经历中他形成了自己的一套价值观和规范。你的背景会有所不同。如果有任何疑问，就回到基本的原则，即敏捷的基本原则，包括本书所描述的那些原则，而不能被束缚在具体的术语和战术中。
我们一直在说“敏捷过程”，但是实际上，不论是正式的还是在人们头脑中所默许的描述，过程本身都不是敏捷的。人可以敏捷；团队或者组织可以敏捷。你是“敏捷的”，但是你不能“做敏捷”。如果你只是做敏捷而不是敏捷地去做，那么你就会失败，并且不会知道为什么失败，接下来你可能会将失败归咎于一些书。因此，你要跨越这个鸿沟，就不仅是决定采用“指定的”敏捷方法和/或Dean等人所描述的这样或那样的实践方法。这需要改变观念或态度，这不是很容易做的事。仅仅读一本书或者参加一个学习班是不够的。你和你的组织想要把敏捷原则变成自己的思想方式，并获得真正敏捷性的好处，你必须要尝试这些新的实践，并且是一次又一次地实践。然后，总结你自己的经验并进行反思，回头看看你已得到（或者没有得到）什么，继而再进一步调整和适应以及采用敏捷的原则。换句话说，就是不要相信一本书能够使你敏捷。它需要的不仅仅是去做，还需要思考、感觉和变化。
然而，如果你是敏捷领域里的一位老资格的人，如果在20世纪70年代你就已经了解敏捷了，那么这本书有什么给你看的呢？有很多东西值得你看。我个人学到了很多东西，并开始反思自己的经验和实践。我同意Dean写的所有内容吗？不。我的背景和我的经验与他是有些不同的，但是如果不去深究具体的战术或者词汇的话，Dean和我在大多数问题上最终都是一致的，特别是在原则和总体战略方面。（此外，他最近指出，我们似乎很享受辩论的过程和辩论本身，辩论可以作为我们明确自身思想的有效渠道，也可以作为一种了解他人想法的交流工具。）有了这一观点，我猜想，即使是最有经验的“敏捷人员”也会学到一些宝贵的经验教训。
说永远不如做。从前言开始，翻开这本书，开始阅读吧。欣赏和学习敏捷吧！...
Philippe Kruchten, Ph.D., P.Eng.
软件工程的教授，英属哥伦比亚大学（University of British Columbia），温哥华，加拿大
媒体评论
“尽管公司实施大型敏捷项目已经许多年了，但是“敏捷方法只适用于小型项目”这样的话依旧是新手所面临的普遍障碍，并且成为制定敏捷标准的战斗口号。关于敏捷开发的资料很多，但是缺少一本关于使用敏捷方式开发大型项目细节的可靠且具有实用性的书。Dean Leffingwell 的这本书 《可伸缩敏捷开发（Scaling Software Agility ）》极好地填补了这一空白。它为架构、需求开发、多级发布计划以及团队组织等大型项目问题提供了有实际意义的指导。Leffingwell 在这本书中也为大型项目和大型组织向敏捷开发过渡提供了必要的指导。”.
——Jim Highsmith，主管，Agile Practice，Cutter Consortium， 敏捷项目管理（Agile Project Management）的作者
“快速构建软件与交付可持续软件之间，以及保持对市场变化的响应与维持稳定程度之间存在着矛盾。 Dean Leffingwell 在其最新的著作《可伸缩敏捷开发（Scaling Software Agility ）》中，介绍了如何实现这些方面之间的实际平衡。Leffingwell 对问题的观察、对解决方案的建议以及对结果的最佳实践的描述都来自于他的经验：他本人一直参与在敏捷实践当中，并且看到了效果。”
——Grady Booch，IBM Fellow （IBM院士，即IBM最高级别的专家）...
——Jim Highsmith，主管，Agile Practice，Cutter Consortium， 敏捷项目管理（Agile Project Management）的作者
“快速构建软件与交付可持续软件之间，以及保持对市场变化的响应与维持稳定程度之间存在着矛盾。 Dean Leffingwell 在其最新的著作《可伸缩敏捷开发（Scaling Software Agility ）》中，介绍了如何实现这些方面之间的实际平衡。Leffingwell 对问题的观察、对解决方案的建议以及对结果的最佳实践的描述都来自于他的经验：他本人一直参与在敏捷实践当中，并且看到了效果。”
——Grady Booch，IBM Fellow （IBM院士，即IBM最高级别的专家）...
