软件项目 困难_为什么制作软件如此困难？

软件项目 困难

我们经常将软件开发视为基于逻辑和清晰度的追求。 有一些定型的软件开发人员是虔诚的逻辑追随者，他们对二进制数字的兴趣远大于对同伴的兴趣。 从这个角度来看，令人震惊的是发现软件项目的故障率很高 ，而有些项目的失败率高达数十亿。 在一个逻辑学科中，由科学家领导的这种混乱状态怎么可能？

如果我们能更好地了解项目如何遭受失败的影响，那么我们可以学会将来更安全地处理项目。 最危险的风险是我们看不到的风险，尤其是如果我们的思维方式使我们对它们视而不见。

关于软件开发的刻板印象

我们作为逻辑追求的软件开发形象体现在由编程语言和由它们构成的应用程序的精确而严格的句法规则中。 这遍及了大众的理解以及技术思想。 使用时，某些应用程序的规则对于应用程序的用户可能很清楚-像太空入侵者这样的简单游戏通常没有页面来解释规则，因为我们只是看到它们。 在其他时候，可能很清楚应用程序具有规则，但是它们却是晦涩难懂的，从而导致了熟悉的“计算机说不”的现象。 无论哪种方式，都倾向于感觉到规则的严格性，这会影响我们对软件开发的假设。

计算问题的著名示例在我们的软件中也占很大一部分，并且这些定义往往非常严格。 教科书中的旅行推销员比现实生活中受到更多的限制（他们很少乘电梯或与同事分担工作或下床喝酒）。 我们倾向于将软件工程与有关破解密码的示例紧密联系在一起，而不是与有助于评估保险索赔的软件联系在一起。

但是软件开发人员并非全是学者，也不是全部都致力于解决明确的问题。 专业软件开发涉及将规则编纂成一个能够满足一系列业务目标的系统。 它旨在产生逻辑产物，以在混乱的世界中发挥作用。

因此，尽管普遍存在严格意义上的软件开发逻辑，但世界的混乱在软件制作过程中的确发挥了重要作用-使软件在世界上发挥作用。 通过对世界做出错误的假设或对他们尝试做的事情感到困惑，项目可能会出错。

即使这样，这仅是部分解释。 软件项目如此危险且如此频繁地失败怎么办？ 我们该如何编写软件？

软件开发图片

软件项目可能会发生巨大变化，项目实施方式的生命周期也会发生很大变化。 在制作软件的过程中形成清晰的画面并保持头脑清晰是非常棘手的。 它变化如此之大，以至于在某种程度上人们仅需从经验中学习。 但是，拥有更清晰的软件开发图景将有助于我们更好地理解软件开发中的风险来源。

考虑到抽象软件开发的程度，可能会倾向于依赖更具体的学科。 尤其是，诱人可以比作建筑或物理工程。 因此，这种类比吸引人，以至于它在历史上影响了很多软件项目管理方法（特别是在瀑布模型上）。 但是我们应该对此谨慎：

我非常怀疑使用其他专业的隐喻来推理软件开发。 特别是，我认为工程隐喻损害了我们的职业，因为它鼓励了将设计与建筑分离的想法。 马丁·福勒

正如福勒指出的那样，危险的是认为我们事先知道问题是什么。

认为我们事先知道工具是什么也是危险的。 容易想到程序员编写代码，因此主要工具是编程语言。 但是，当代的商业发展在很大程度上取决于现有的工具和库，这些工具和库必须选择并应用于手头的任务。 程序员不仅编写代码来解决问题，而且程序员大量编写代码来将其他人的部分解决方案组合在一起。 根据选择，可能很难使工具用于特定目的（需要大量思考和拼接代码）或例行程序，或者实际上是不可能的。

施工还涉及工具选择的问题。 例如，为了承重和耐用性，必须选择砖或材料的类型。 与软件的不同之处在于，工具本身是概念性的，因此，至少在不花费大量时间的情况下，很难清楚地看到其工作范围。 经常发现所选工具不支持我们想要的特定数据格式或通信协议，这是很正常的。

毫无疑问，有关工具的早期假设无疑会导致超支和成本增加，从而导致故障。 但是，在业务目标空间中，更具破坏性的假设往往是不容质疑的假设。 这里的构造隐喻再次没有反映风险。 关于建筑物设计是否为将使用该建筑物的人数提供足够的空间以及是否有足够的电梯，肯定存在错误假设的范围。 但是视觉计划有助于提出假设，而实现越具体，就越容易找到假设。 由于软件本质上是抽象的，因此很难在不完全构建解决方案的情况下将其具体化到足以消除假设的程度（届时将产生所有成本）。

完善问题规范以消除假设可能比科学还重要。 完善规范并选择解决这些问题的工具对于软件开发人员而言都是至关重要的。 风险是两者固有的。 让我们尝试表达比构造隐喻更好地表达这一隐喻的隐喻。

更好的隐喻

软件开发既具有逻辑性又具有创造力 （其中存在混乱）。 一类特殊的问题既有创造力又是逻辑上的，一类问题可能被认为属于“谜语”（尽管我并不认为所有被称为“谜语”的东西都一定很合适）。 通过考虑拉格纳·罗德布鲁克（Ragnar Lodbrok）的古老北欧故事中的解谜故事，我们可以探索这种创造性的解决问题的方式如何充当软件开发的隐喻。

随着故事的发展，拉格纳尔的男人向他报告说，他们见过每一个美丽的女人克拉卡。 拉格纳（Ragnar）引起了他的兴趣，他派遣了她，但他决定考验她的智慧。 他命令她既不穿衣服也不穿衣服，不饿也不饱，也不要一个人陪伴。 面对挑战，克拉卡（Kraka）披上了网，扎着长长的头发，咬着洋葱，只带着狗作为伴。 拉格纳留下深刻的印象并与她结婚。

Ragnar的要求在至少一个关键方面与软件项目的规范没有不同。 拉格纳（Ragnar）在看到请求之前并不完全知道什么会满足他的请求。 他知道某些需要满足的约束条件，但他不知道Kraka发现的解决方案是可能的解决方案，直到他看到为止。

为了更清楚地了解这种联系，让我们想象一下拉格纳尔不会立即嫁给克拉卡。 取而代之的是，他接下来规定，克拉卡（Kraka）首先应通过更加英勇的锻炼证明自己的价值。 他要求她生产一个系统，该系统将处理他目前雇用整个团队的文件批准和拒绝。 就规范而言，Ragnar几乎不需要团队就可以完成任务的概念，就像以前的谜一样，Ragnar不知道没有团队就可以处理文档的批准和拒绝。 需要向他展示解决方案，然后才能知道它是否正在执行他目前所谓的“文档批准和拒绝”。

在这两种情况下，Kraka都必须将Ragnar带入一个未知领域，这一点很重要。 拉格纳（Ragnar）不确定他会称之为“既不穿衣服也不脱衣服”的事情。 同样，如果没有团队执行批准/拒绝，Ragnar不确定他将如何称呼“文档批准和拒绝”，并且Kraka必须充分理解这些表达方式才能提出Ragnar称之为解决方案的内容。

因此，与软件项目一起出现的基本不确定性是，直到我们有了完整的解决方案，我们才能完全了解解决问题的方法。 如果一切顺利，那么随着项目的进行，人们会看到解决方案的形式越来越清晰。这是软件项目与制造项目之间的关键区别–对于制造项目，一个人可以在产品的早期阶段就形成相对清晰的画面进行生产，然后可以精确地绘制和物理构造。 在制造项目中，由于要生产的产品是物理物品，因此有可能尽早形成清晰的图片。 软件产品是抽象的，软件问题的解决方案是概念性的。 （软件程序可以在物理上实例化，但这并不能脱离其概念性质。）

如果要为物理产品或结构起草需求，那么从一开始就比软件项目更容易理解这些需求。 例如，如果要建造一座桥，那么从一开始就很清楚地说要承受X的负载，每辆都要重这么多的汽车。 由于软件需求是抽象的，因此很可能难以理解，有时看起来似乎很清晰，但根据后来的发展却变得不清楚。

让我们回到克拉卡和拉格纳尔，想象一下，克拉卡是在兔子而不是狗的陪伴下到达的。 拉格纳尔可能会说他不会接受这个解决方案–他认为与兔子同行并不算是陪伴。 如果这看起来不可行或不公平，那么可以想象一下，克拉卡（Kraka）带着一条金鱼来了。 我们可以找到情况，使克拉卡和拉格纳尔对被视为“陪伴”的人持不同看法，这似乎是有道理的。 但自从拉格纳提出问题以来，拉格纳尔的观点就很重要。

Kraka和Ragnar之间在软件项目上存在类似的争议-开发人员有时可以对问题的解决方案和最终用户认为可以接受的问题有不同的看法。 Kraka可能从一开始就通过进一步探究该问题来试图避免此类问题的发生-她可能已经进行了等效的需求分析。 我们可以想象Kraka戴上商务分析师的帽子，然后问诸如“您的意思是有人陪伴吗？ 那宠物呢？ 但是即使经过大量需求分析，这些类型的歧义仍然会保留。 即使确实很清楚Ragnar会接受宠物，也可能不清楚（直到他看到他之前才对他）他不会接受金鱼。

隐喻的用途

当我试图寻找一种确定的答案，即某个特定的设计将“起作用”还是所选的工具将满足特定的需求时，我个人发现逻辑解决问题的隐喻是一个有用的后备。 有时我们无法确定是否提供解决方案。 我们可能非常希望获得前期确定性，但我们却无法实现。

当项目中正在进行很多工作时，我还发现这个比喻很有用，我需要更好地了解项目动态-项目的运作方式以及尝试达到的目标。 通过对逻辑问题解决方案进行开放式比较来思考一个项目，可以帮助我了解那些本来可以忽略的方面的重要性。 它可以为我提供一个更好地理解项目动态的原理，而不是查看一组消耗图表。 如果我们将软件项目视为解决集体问题的练习，那么我们会将思维重心从计划的图形上转移到驱动项目的人员和动机上。

本文基于我的“为什么制作软件如此困难”，ACM SIGSOFT软件工程说明39

翻译自: https://hackernoon.com/why-making-software-is-so-difficult-vm8i30gv

软件项目 困难