|
|
4 回复 | 直到 14 年前
|
1
6
让我们以一个桥为例,将其与软件进行比较。 这座桥的外部规格将更少。它将有一些相当严格的规格,但其中很多是内部的(如材料强度)。 它将由那些知道桥梁设计不会过于匆忙的人设计。一般来说,土木工程师从管理层得到的尊重要比软件开发人员多。此外,土木工程师还将在一个更为有限的问题空间工作。没有多少方法能像库存系统那样成为一座桥梁。 设计完成后,一个或多个持照专业工程师将在设计上签字。这是在承担真正的责任。(或者,没有一个PE会把他或她的许可证押在它的可靠性上,设计也不会去任何地方。)这在软件中不会发生,部分原因是问题空间是如此的不受约束。 最后,这座桥将被建造,这需要几个月的时间和大量的重型设备。软件最初将使用编译器构建,并使用便宜的工具无限期地复制。这里有一个很重要的心理意义:人们往往认为项目具有重要的设计和重要的制造阶段,如果制造过于琐碎,则倾向于认为设计的一部分是制造。 如果软件更像土木工程,我们将需要标准实践,充分和可靠,为大多数事情。我们需要工程师来研究这些实践,并愿意证明软件的设计是否正确,实际上我们需要根据这些实践完成的项目几乎完全可靠。我们需要在那里承担更正式的责任。我们需要更多的外部尊重,因为那些不敢插手一个1000万美元的建设项目的经理们对于搞砸一个2000万美元的软件项目往往毫无疑虑。 简而言之,软件是一门不成熟的学科,不能像土木工程那样工作。 |
|
|
2
8
我认为最大的区别是,他们永远不会考虑用我们得到的同样劣质的要求来启动一个项目。也许我们也应该停止这样做,在我们开始尝试编码之前强迫人们真正定义他们想要什么。 我想补充一点,我们作为一个行业,在需求(如需求)发生变化时,要用新的时间线和预算来推回这项糟糕的工作。我们开始在这里做更多的推后工作,告诉客户所请求的更改需要多少小时(和更多的钱),增加两天的额外时间来完成现有的最后期限,并使他们正式提出更改请求。一旦我们坚持要求变更会有成本,对初始需求的变更数量就会急剧下降。这一变化也将我们从公司的成本中心转移到了利润中心,因为我们做了很多额外的工作,但并没有向客户收取超过最初估计的费用。 |
|
|
3
2
可从工程中吸取的教训: 遵守非功能性要求 . 功能需求是非常困难的,因为他们期望用户、开发人员、分析师和其他任何相关人员能够定义业务所需的内容。 非功能性需求是工程师和技术人员提出的,功能性人员可能看不见的东西。很容易忽略或淡化非功能。我以前工作过的一些PM不想听到非功能性的消息,因为它们不能直接与业务需求联系在一起,并且引入了会威胁到“按时和按预算”指标的任务。 例子 功能要求 :豪华船必须能载客x人。 非功能要求 :船足够大,可以运载x数量的乘客,需要有厚度为y的船体单元,以保持完整性,即使受到冰山的冲击。 计算成本 为什么软件PMS不尊重非功能需求?因为这种不尊重的代价对于工程来说和软件开发是不同的。 在我的船例子中忽视非功能性需求的成本 失去生命。 忽视软件中非功能的成本 :一些被称为技术债务的懦弱的东西,稍后将由长期被从项目团队中除名的人和项目团队的完成奖金支付。 当然,我的例子很简单。并非所有的工程缺陷都会导致死亡,而一些有缺陷的软件肯定会导致死亡(例如航空电子设备、医疗或交通控制系统)。但我想你明白了。 |
|
|
4
1
软件开发和工程或建筑行业有区别——规范总是可以更改的。
--爱德华诉贝拉德( from here ) 您可以在“项目管理”的开头找到对项目管理方法差异的更详细解释。 Extreme Programming Applied “书。 |
推荐文章