需求波动性是软件工程的核心问题

我们开发软件的原因是为了满足某些客户，客户，用户或市场的需求。软件工程的目标是使开发可预测且具有成本效益。 

自首届IFIP软件工程大会以来，已有50多年的历史，当时提出了许多不同的软件工程方法，流程和模型来帮助软件开发人员实现可预测且具有成本效益的流程。但是50年后，我们似乎仍然遇到同样的问题：交货延迟，结果不令人满意以及项目完全失败。

拿我几年前工作的政府合同。至少从通常的项目管理指标的角度来看，它无疑是我迄今为止最成功的项目：它提早完成，在预算内完成，并且在三天内完成了计划的为期一个月的验收测试。

该项目在一些非同寻常的约束下运行：合同以外币计价和支付，并且绝对是固定的固定价格，而合同中根本没有变更管理流程。实际上，作为合同的一部分，验收测试是按照一系列可观察的，该做此和此后进行的测试进行布置的，可以进行检查，是或否，几乎没有争议。由于合同的规定，要求或汇率变化的所有风险均由我公司承担。

这个过程绝对是经典瀑布，我们充满信心地完成了所有步骤，直到最终系统完成，交付并通过了验收测试。

之后，我又花了18个月的时间对系统进行修改，直到它真正满足客户需求为止。 

在签订合同和交付软件之间的中间一年中，报告格式发生了变化，硬件平台的某些组件被新的更好的产品所取代，并对系统必须做出的法规更改进行了更改。 

需求变更。每个软件工程项目都会在某个时候面临这个难题。

考虑到这一点，所有软件开发过程都可以看作是对此基本事实的不同回应。最初的（并且是幼稚的）瀑布式过程只是假设您可以首先确定要满足的条件。

罗伊斯（WW Royce）在他的论文“管理大型软件系统的开发”中首先观察到瀑布，而数百个软件工程论文，教科书和文章中的插图都是他创建的图表，这一点得到了公认。但是，在Royce的原始论文中经常忘记的是，他还说：“（在图中）实现是有风险的，并且会导致失败。” 

使您的过程与您的环境相匹配

罗伊斯（Royce）的观察是一个很好的发现-从确定需求和提议的解决方案到构建软件，然后对其进行测试以查看其是否满足这些需求，这些开发都经历了可识别的阶段。实际上，即使是在第一次课堂作业中，每个程序员都对此很熟悉。但是，当您的需求在项目进行过程中发生变化时，即使您完全满足原始需求，也可以保证您无法满足客户的需求。

对此，实际上只有一个答案：您需要找到一种方法来使需求开发交付周期与需求变化的速率相匹配。在我的政府项目中，我们是人为地这样做的：任何物质都没有变化，因此可以很容易地进行规格和验收测试。

罗伊斯（Royce）的原始论文实际上认识到了开发过程中的变化问题。他的论文描述了一种迭代模型，其中在开发过程中反馈了无法解决的意外更改和设计决策。

软件开发中的现实主义

一旦我们接受了所有软件开发中的核心不确定性（即需求永远不会随着时间的推移而保持不变），我们就可以以可以应对不可避免的变更的方式开始进行开发。

首先，接受改变是不可避免的。 

任何项目，无论计划多么周密，都会产生与最初设想的至少有些不同的结果。开发过程必须接受这一点，并准备好应对它。 

结果，软件永远不会完成，只会被放弃。

我们喜欢在开发项目“完成”时提出明确的定义。但是现实是，我们所说的“完成”的任何固定时间仅仅是人为的分界线。新功能，修订功能和错误修复将在“成品”交付时开始出现。（实际上，在软件发布的那一刻，仍然需要进行一些更改，包括技术债务和延期的要求。）只要使用软件产品，这些更改就会继续。

这意味着没有软件产品能够完全令人满意。真正的软件开发就像在移动的目标上射击一样—目标，目标的运动，风和振动的各种随机变化可确保即使您靠近精确的靶心，也永远无法达到完美。 

使我们的流程适应环境

从这个角度来看，软件开发似乎令人沮丧，甚至令人沮丧。听起来好像我们是在说可预测的，具有成本效益的开发的整个概念正在追求一个不可能实现的梦想。

不是。只要我们牢记现实，我们就可以成为非常有效的开发人员。

第一个现实是，尽管不可能做到完美，但务实的成功却是可能的。精益创业运动使MVP（“最小可行产品”）成为了创业公司的通常目标。我们需要将此思想扩展到所有开发中，并认识到每个产品实际上都是MVP，这是当前对问题的理解的最佳解决方案。

第二个现实是，我们无法真正停止需求的变更，因此我们需要应对变更。在实际的软件开发中，人们已经很早就了解了这一点-Parnas识别模块的规则是构建模块以隐藏可更改的需求。同时，人们反复尝试描述期望提供逐次逼近的软件开发过程-增量开发过程（我称之为“曾经与未来的方法论”）。

一旦我们接受了增量开发的必要性，一旦将自己从完成完美解决方案的想法中解放出来，我们就可以从容地接受变化。

第三个也是最后一个现实是，所有日程表实际上都是带时间限制的日程表。我们进入一个开发项目，无法确切说明最终产品是什么。因此，无法对完成时间进行早期预测，因此所有最终交付都将是部分交付。

敏捷发展来拯救

敏捷宣言源于对这些事实的认识。定期交付工作软件是这种认可的一部分：一个真正敏捷的项目会定期进行部分工作实施。与最终客户的密切关系确保了随着需求变化的显现，它们可以适应工作计划。

理想情况下，在敏捷项目中，从项目的早期开始就有部分可行的实施方案，并且从一开始就朝着令人满意的产品迈进。再次考虑目标射击的隐喻-随着我们的前进，我们越来越靠近中心环，靶心。我们可以确信，随着时间的推移，产品将至少接近目标。