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

敏捷开发 软件工程 需求
2020-12-24 16:15:05
175 13 0

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

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

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

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

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

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

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

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

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

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

将流程与环境匹配

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

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

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

软件开发的真实性

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

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

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

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

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

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

使我们的流程适应环境

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

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

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

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

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

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

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

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

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

作者介绍

用微信扫一扫

收藏