敏捷开发方法是否有可行的替代方案？

两种主要的软件开发方法是瀑布式和敏捷式。在讨论这两者时，通常会着重于将它们区分开的特定实践（结对编程，TDD等与功能规范，大型前期设计等）。

但是真正的差异要深得多，因为这些实践来自一种哲学。

Waterfall说： 更改成本很高，因此应将其最小化。
敏捷说： 改变是不可避免的，所以要使改变便宜。

我的问题是，不管您如何看待TDD或功能规格，瀑布式开发方法真的可行吗？

真的有人认为对于希望交付有价值的软件的人来说，最小化软件更改是一个可行的选择吗？还是真正的问题是，哪种方式在我们的情况下最能应对不可避免的变化？

当然瀑布是可行的。它把我们带到了月球！

这是一位敏捷教练在这里讲话！

除非您能清楚地确定与项目管理方式有关的问题，否则就没有更改的正当理由。

作为敏捷方法和瀑布方法的替代方法，我将建议您使用方法。适用于您的特定业务，您的特定团队，您的产品，您的工作方式，您的公司文化……这就是为什么Scrum被称为简单框架而不是方法。

想要实施一种方法，因为您喜欢的博客上有人谈论它，就像让问题不做任何事情一样愚蠢。

首先，我不同意您的陈述：

Waterfall说：更改成本很高，因此应将其最小化。
敏捷说：改变是不可避免的，所以要使改变便宜。

我的解释是：

Waterfall说：客户知道他们想要什么。
敏捷说：客户不知道他们想要什么，因此我们将不得不制作一些不同的版本。

我见过的“瀑布”的最佳实现是一个庞大的集成项目，该项目具有非常大的金融客户，并且涉及大约40多个子项目。我们提供的桌面和网站软件包只是这40多个子项目中的一个。虽然我认为他们过分地浪费了别人的钱，但他们把自己的东西放在一起，并让40多艘不同的船一起编队。该项目在目标日期上线（目标在项目期间移动了一次），尽管我认为他们可以更加节俭和敏捷地完成它，但它却按时，按规格完成。上夜活动的时间表大约100页，其中大约40页是涉及到的所有人员的紧急恐慌联系方式。这个客户给我留下了深刻的印象。

或者，你可以做什么我们做，这是跑来跑去，做最近期的投诉/ bug报告是什么，叫那敏捷。

您首先说：

瀑布式开发和敏捷开发是两种主要的软件开发理念。

这是错误的。这种二分法是敏捷社区构建的，目的是创建一个自己定位的对手。在敏捷流行之前，人们曾经谈论过各种各样的构建软件的方法。它们今天仍然存在，但是不知何故，它们经常被敏捷的拥护者混为一谈，称为“瀑布”。

我使用OPEN / Metis及其变体已有10多年了，取得了巨大的成功。它绝对不是敏捷的，而且绝对不是瀑布。每天都有成千上万的开发人员使用非敏捷方法为飞机，生命攸关的系统，银行业务等创建极其复杂的软件。

因此，是的，当然有可行的替代敏捷的方法。

是的，根据您的问题领域，各种软件开发技术都是可行的。这是“课程的马匹”。

例如，您正在编写控制核电站或驱动NASA航天飞机的软件。这类问题域可能更适合瀑布式（甚至更严格）的方法，如果可能的话，您希望提前解决所有问题（或BOOM！）。

建立最新的Web 2.0 / 3.0 / Buzzy营销术语用户界面？敏捷是一种更好的方法（您需要快速的反馈和更改）。

无论哪种方法论，我都可以称之为软件工艺原则，这些原则仍然可以应用：

• 源代码控制
• 建立和CI
• 配对编程
• TDD
• 我给一个^％$$＆

和更多。

无论您做什么，都不要听从等式两边的狂热分子，去做适合自己，您的团队和问题领域的事情。

问题源于软件的复杂性。瀑布对于桥梁建设和铺路等非常有用，因为物理原理永远不会改变。当然，在某个时候，我们将开发一种新的沥青，但不会改变公路的建造方式。桥的悬架中的钢的大小正确或不正确。您不能像使用软件那样拖延或存根真正的建设项目。

软件变更。软件变化迅速。摩尔定律指出，芯片上的晶体管数量每18-24个月就会增加一倍。结果，程序中的代码行数也加倍。因此，这些代码行之间的复杂性会随着bigO之类的2 ^（2t）而增加。

软件变化迅速，并且复杂度随之增加。

在控制软件成本时，您希望控制指数因子，而不仅仅是乘数或加法。更改代码以指数方式增加了复杂性（并且随着项目的进行本身也成倍地复杂）。

变化是不可避免的。编程的本质是通过类和自定义方法扩展语言，从而改变了语言本身。您无法在任何其他类型的工程学科中做到这一点（例如，修筑道路。您不能仅仅为了在堪萨斯州的堪萨斯州铺平道路而发明新的路面）。

敏捷方法还为您提供了一个用于处理将来的版本和错误修复的平台。您已拥有开发版本控制软件的管理工具，流程，受过培训的员工。使用瀑布式方法，您将需要对团队进行再培训，以处理甚至较小的错误修复。

无论如何，我的2美分。

要回答这个问题，是否有可行的替代方法，至少在一般情况下，对于软件可能不是-或尚不可行。我认为这取决于软件的性质。作为信息的软件可以免费复制。与桥梁或房屋不同。这意味着，通过实践，我可以擅长盖房并在相对简单的领域进行操作。在什么时候不使用一次性方法？

但是由于软件的复制成本为零，所以为什么您会做两次相同的事情？软件趋向于脱离制造业。因此，如果所有软件都是新产品的创建，那么我们总是在一个复杂的域中运行，在某种程度上，我们不知道我们在做什么。或者预先知道会很昂贵，而通过做来发现会更便宜。在一个复杂，有风险的领域中，我想尝试进行实验并进行递增和迭代。

核电站和绕线飞行系统通常作为您想瀑布式运行的软件示例。但是航天飞机航空电子系统不是迭代开发的吗？像加拿大和美国的空中交通管制系统一样吗？

如果OPEN / Metis是迭代的和增量的，那么对我来说，即使它不与其他常见的敏捷实践相关联，它听起来也具有敏捷的哲学。

瀑布方法无疑是可行的，并且在哲学上与其他方法一样合理。请记住，Waterfall比敏捷开发的时间长得多，但是请注意，这并不是要说明一种方法是否优于另一种方法的论点。

当您对整个问题域以及客户希望通过软件包实现的目标非常清楚时，可以使用Waterfall方法。签订合同时，您可能已经报价了固定价格，并且您的客户了解他们不能偏离任何商定的要求。严格来说，您的过程是在开发的各个阶段之间进行一系列签核的过程，通常情况下，每个阶段都是由不同的团队（有时甚至是不同的公司）完成的，每个团队不一定都在与其他人联系。当您将Waterfall招标给外部承包商时，通常会看到它们在军事和政府项目中发挥了良好的作用。当开发人员遇到问题时，Waterfall和其他类似方法获得不良声誉的地方是，例如估算不正确，计划的时间表没有应急时间，或者对问题域的理解不充分或不完整。这个问题从来都不是方法论的真正错，而在于它的应用。

敏捷与任何方法之间的比较都是错误的。敏捷不是一种方法论，它是一种哲学，或者也许最好说它是一个笼统的术语，代表了一种不同的方式来研究开发软件的方式。方法论仅仅是一种工具，因此它的价值将始终小于处于敏捷意义的核心的个人和互动。

真的有人认为对于希望交付有价值的软件的人来说，最小化软件更改是一个可行的选择吗？

最大限度地减少变更的每一个机会对于开发人员和客户都是宝贵的。更改可能导致进度表延误，或者为了满足进度表而忽略了某些功能。这是您管理变更影响项目价值的方式。

还是真正的问题是，哪种方式在我们的情况下最能应对不可避免的变化？

您的实践可能有助于变更管理，或者可能完全忽略变更。重要的是您的开发实践，与您的客户关系的管理以及这些事情对于所有相关方是否有效地结合在一起。

我们这些谁是对所有意图和目的敏捷明白，你选择一个适合自己的方法。如果您喜欢特定的方法，请遵循它。如果它不能完全满足您的需求，请进行更改。制作软件的方式实际上归结为尝试充分利用手头的资源，并最大限度地减少那些可能导致项目失败的做法，而且您经常发现需要更改方法以适合您的需求。即将进行的特定项目。

说“好吧，现在我们是敏捷的”是一回事，而按照敏捷的哲学实际生活和工作则完全是另一回事。无论您使用Waterfall，Incremental，Spiral，SCRUM，XP，FDD还是任何其他方法，您基本上都非常看重敏捷：

• 个人与流程和工具之间的互动
• 工作软件超过全面的文档
• 客户合作而非合同谈判
• 响应计划变更

以及将工具，方法和经验结合在一起的位置，以便成功应用这些价值。

是的，瀑布，螺旋，迭代和其他混合过程模型都是可行的，但改变是不可避免的。过程不仅仅在于如何处理变更，而且（我声称）最大的决定因素是您对问题的了解/了解的程度以及计划和预测的准确性。

指出“两种主要的软件开发方法是瀑布式和敏捷性”是不恰当的，因为软件开发过程种类繁多，许多公司合成了自己的过程模型版本，这些模型通常会针对给定项目进行更改。有两种以上可行的软件开发方法。尽管Waterfall和Agile往往落在“变化”光谱的两端，但是将这些竞争方法典型地描述为：

Waterfall说：更改成本很高，因此应将其最小化。

敏捷说：改变是不可避免的，所以要使改变便宜。

但这还不是全部。业务需要能够计划和预测，但是软件是一个创造性的过程，而估算通常是错误的。还记得好-快速-便宜的三角形吗？添加第四个维度，即流程，您会发现，当估算结果错误并且项目有延迟的危险时，减少流程工作量也可以压缩进度。软件是一个可替代的（可变的）过程，敏捷，迭代，螺旋式都可以在较短的间隔内提供增量功能。

Waterfall和其他需求驱动的流程模型具有处理变更的控件，因此说Waterfall最小化变更是不准确的，说Waterfall可以识别和管理变更并传达变更的影响（因为变更会在您使用时造成时间表影响）是不准确的。事先有要求和设计）。在构建产品或需要完全定义需求（功能）时，您将被迫采用其中一种混合模型。

当估计错误时，通常会牺牲过程（铁三角的第四段）来满足进度表。

成熟的敏捷方法和瀑布方法是无法区分的。您对瀑布方法的目标的假设是不正确的。他们俩的目标都是生产高质量的软件。如果您对整个公司都没有可靠的开发方法，则需要查看哪种方法对采用的影响最小。在最后的短暂开发周期中，扎实的质量保证团队和推动开发的业务是生产一流软件的最重要条件。