需求变化是软件工程的核心问题

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

第一次关于软件工程的IFIP会议至今已有50多年，在此期间，提出了许多不同的软件工程方法、过程和模型，以帮助软件开发人员实现可预测的、经济有效的过程。但50年后，我们似乎仍然看到我们经常遇到的同样类型的问题:延迟交付，不满意的结果，以及整个项目的失败。

以我多年前为之工作的一份政府合同为例。毫无疑问，这是我参与过的最成功的项目，至少从通常的项目管理度量的角度来看是这样的:它提前完成了，在预算范围内完成了，并且在三天内完成了一个计划的长达一个月的验收测试。

这个项目是在一些不寻常的约束下运作的:合同是以外币计价和支付的，并且是绝对固定的固定价格，在合同中没有任何变更管理过程。事实上，作为合同的一部分，验收测试被安排为一系列可观察的、做这个和做这个的测试，这些测试可以被检查，是或不是，几乎没有争论的余地。根据合同条款，任何需求或外汇汇率变化的风险都由我公司承担。

这个过程是绝对的，坚定的，经典的瀑布式的，并且我们满怀信心地进行这些步骤，直到最终的系统被完成，交付，验收测试被接受。

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

在合同签署和软件交付之间的这一年，报告格式发生了变化，硬件平台的一些组件被新的和更好的产品取代，系统必须对监管方面的变化作出反应。

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

记住这一点，所有的软件开发过程都可以看作是对这个基本事实的不同反应。原始的(和幼稚的)瀑布过程简单地假设您可以从要满足的需求的坚定声明开始。

W.W. Royce被认为是在他的论文“管理大型软件系统的开发”中第一次观察到这个瀑布，并且在数百篇软件工程论文、教科书和文章中都可以看到他创建的图表。但是在Royce的原始论文中经常被忘记的是，他还说“(图中的)实现是有风险的，会招致失败。”

将流程与环境匹配

Royce的观察是很好的——每个开发都要经历可识别的阶段，从确定需求和提出的解决方案，到构建软件，然后测试它以确定它是否满足这些需求。事实上，每个程序员都很熟悉这个，甚至在他们的第一次课堂作业中。但是，当您的需求在项目持续期间发生变化时，您就可以保证，即使您完全满足了最初的需求，您也无法满足客户。

对于这个问题，实际上只有一个答案:您需要找到一种方法，使需求-开发-交付周期与需求变化的速度相匹配。在我的政府项目中，我们是人为地这样做的:没有任何实质性的变化，所以很容易按照规范和验收测试进行构建。

Royce的原始论文实际上认识到了开发过程中的变化问题。他的论文描述了一个迭代模型，在这个模型中，意外的变化和无法实现的设计决策会在开发过程中得到反馈。

软件开发的真实性

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

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

任何项目，无论计划得有多好，都会导致至少与最初预想的有所不同的结果。开发过程必须接受这一点，并准备好应对它。

因此，软件永远不会完成，只是被抛弃了。

我们喜欢创建一个特殊的、清晰定义的点，在此点上开发项目“完成”。然而，现实是，任何一个我们说“完成了”的固定时间只是人为的分界线。新特性、修订的特性和错误修复将在“完成”的产品交付时开始出现。(实际上，在软件发布的那一刻，仍然会有需要的变更，代表技术债务和延期的需求。)只要软件产品还在使用，这些变化就会继续。

这意味着没有一个软件产品是完全令人满意的。真正的软件开发就像射击一个移动的目标——所有的目标、目标的运动、风和振动的各种随机变化都确保你可能接近准确的靶心，但你永远不会达到完美。

使我们的流程适应环境

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

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

第一个现实是，完美是不可能的，务实的成功是很可能的。精益创业运动使得MVP——“最小可行产品”——成为创业公司通常的目标。我们需要将这个想法扩展到所有的开发中，并认识到每个产品都是真正的mvp——我们对当前理解问题的最佳近似解决方案。

第二个现实是我们不能真正停止需求的变化，所以我们需要处理这些变化。这在实际的软件开发中已经理解了很长一段时间——parnas识别模块的规则是构建模块来隐藏可能发生变化的需求。与此同时，人们一再尝试描述期望提供连续近似的软件开发过程——增量开发过程(我称之为“一次性和未来方法学”)。

一旦我们接受了增量开发的必要性，一旦我们从完成完美解决方案的概念中解放出来，我们就可以坦然地接受变更。

第三个也是最后一个事实是，所有的时间表都是有时间限制的时间表。当我们进入一个开发项目时，我们无法确切地说出最终的产品是什么。因此，早期预测的完成时间是不准确的，所有最终交付都将是部分交付。

敏捷开发可以解决这个问题

敏捷宣言就是基于对这些事实的认识而产生的。定期交付可工作的软件是这种认识的一部分:一个真正敏捷的项目有定期工作的部分实现。与最终客户的密切关系确保当需求变化变得明显时，它们可以适应工作计划。

在一个敏捷项目中，理想情况下，在项目的早期就有一个工作的部分实现，并且从一开始就朝着一个令人满意的产品取得了可观的进展。再想想射击的比喻——当我们前进时，我们越来越接近中心环，也就是靶心。我们可以确信，当时间到了，产品至少会接近目标。