入门

为什么采用敏捷开发

大石难投。
—— 德国谚语

假设我们需要开发一个支持金融机构前台交易员的应用程序。交易员必须能够买卖产品，并计算每笔交易的风险。其中一大难点在于，可供交易的产品不断变化。

此外，客户会告诉我们，没有这个应用程序，他们就无法交易这些新推出的期权。每天延迟开发，公司就会损失数十万美元。更糟糕的是，他们指出竞争对手已经可以交易这些产品。他们保证，只要我们的应用能为这些产品提供一些支持，哪怕只是部分功能，也能帮助减少损失，因为他们目前还能手动完成部分操作。因此，他们并不坚持要求完全支持新产品的交易功能，尽管这当然是理想情况。

类似的情况也出现在电信行业或任何以电子商务为核心的领域。现代应用与传统应用之间最大的区别在于，现代应用必须快速推向市场。否则，当应用首次投入使用时，可能已经过时，或者公司可能已经倒闭。

注意： 有时，快速满足客户的基本需求比后期再满足全部需求更为重要，因为后者可能已经太迟。

上世纪八九十年代的重型开发流程难以应对这类不断变化的需求。它们在需求稳定的领域中曾取得过成功。在这些领域中，所有内容都可以被形式化，项目初期即可制定详细计划，并且整个项目可以“盲目”遵循该计划，无需担心更新或修改。

例如国防项目、航空业项目或核电站项目。除了需求稳定外，这些项目往往还拥有近乎无限的成本和时间预算。因此，比起按时按预算交付部分功能，更重要的是确保所有需求都被完整实现。然而，即使是这些领域，目标也在发生变化。例如，在国防领域，支持需求变更的流程正变得越来越重要。

注意： 敏捷流程承诺能够灵活应对持续变化的需求。这也是为什么敏捷流程被视为成功软件开发的万能解药。

敏捷开发在大型项目中是否可行？

敏捷流程通常仅推荐用于小型项目和小团队，这对那些需要应对快速需求变化的大团队来说可能是个坏消息。但好消息是，本课程将探讨大型项目中的敏捷流程。

对敏捷流程扩展性的质疑

软件工程师常常对在大型项目中应用敏捷开发持怀疑态度，不仅因为大多数敏捷流程声称主要适用于小团队，还因为大多数失败的项目都是大型项目。大多数（大型）项目失败的原因在于团队成员之间、团队与管理者之间、团队与客户之间的沟通不畅。

沟通是敏捷流程的核心重点之一。但能否在大型团队中建立有效的沟通？普遍观点认为不可能；这导致一种想法：如果开发团队有百人规模，就应该至少裁掉80人，只保留最顶尖的20人，甚至更少。这样项目的成功率将显著提高。

然而，我们通常无法避免大型项目。有时我们会面临必须使用大团队完成大项目的约束。例如，有些项目范围极其庞大，仅靠小团队在规定时间内根本无法完成。

如果我们希望利用敏捷流程的优势，就会产生一系列问题：敏捷流程能否扩展？也就是说，能否放大以支持大型项目？它们是否真的能够支撑大型项目？当企业决定在一个大型甚至关键任务级项目中采用敏捷流程时，会遇到哪些问题？本课程将尝试回答这些问题以及更多关于敏捷软件开发的疑问。但在深入探讨之前，我们首先需要明确“大型项目”究竟指什么。