如何解释很难估计更大的软件项目所需的时间?


37

我是一名初级开发人员,发现很难估算完成一个较大的软件项目需要多少时间。我知道一般如何构造体系结构,但是我很难知道我必须做哪些细节以及必须解决什么问题。因此,很难估计完成一个较大的项目将花费多少时间,因为我不知道我需要解决什么问题以及解决它们需要多长时间。

我如何向非软件开发人员解释


5
好奇:为什么您作为初级开发人员向非软件开发人员解释这一点?您的工作组或管理链中是否有人可以帮助您说服需要说服的人?
亚历克斯·费曼

@Alex:不,不是同一家公司的人。只是一个有想法的人来创业。我是他唯一与之联系的开发人员。
乔纳斯(Jonas)



Answers:


48

您可以要求他/她估计她需要多长时间才能进入这个世界上无人居住的角落。举一个极端的例子,让我们在喜马拉雅山中选择一个鲜为人知的山峰,那里很少有人爬过。她甚至需要在开始旅程之前就进行大量准备工作和练习,再加上一堆许可证,每份许可证都可能使旅途延迟数月至数年……以及一支优秀的支持团队……然后一旦上山在斜坡上,她将需要等待并祈祷好天气才能开始攀登到山顶……等等。这些都是很难甚至不可能估计的,即使有以前的经验。

关键是:每个软件项目都有点像爬上一座新山,以前没有人去过,所以没有人有直接的先验经验。经验丰富的开发人员可能已经或多或少地收集了类似项目的经验,但是总会有新的元素和惊喜-否则,如果一个软件项目与以前的某个项目完全一样,那么绝对没有意义


更多的未知数意味着更多的不确定性。
surfasb

9
忘记远了。让他们估计-直到今天-他们今晚下班回家的时间。如果交通不一样怎么办?如果下雨怎么办?如果开车时接电话怎么办?等等。如果事情如此平凡,并且像开车回家一样频繁,那么就无法以任何精确度来衡量-那么如何我们是否可以期望更好地估计实施某些复杂软件所需的时间,该软件中有许多重要变量,而工作量很少。
2011年

8
@qes,我使用公共交通,这样我就可以用约10%的准确度告诉我的时候会到家-我想大多数SW项目经理将很高兴与这一水平acccuracy的;-)
彼得Török

1
软件项目的目标也会改变,因此在他们估计了所需的时间之后,OP可能会问他们在有人告诉他们在第一个目标的中间位置切换峰时是否仍然按时进行。
保罗

18

你向那个人解释过了吗?您是专业的软件工程师,因此在为软件系统设计和实现时,要为其构建软件的人员应考虑您的知识和反馈。

不确定性的锥可能是一个很好的起点。在了解更多细节之前,很难估算软件项目,这在项目后期会发生。此外,不断变化的需求也将改变估计。您在项目开始时的初步估计会产生很大的可变性。

您可能也对其他估算技术感兴趣。您提到您只是初级开发人员。通常,经验丰富的开发人员具有更好的估算能力,因为他们看到了更多的问题,已解决了这些问题,并且(希望)跟踪估算与实际时间之间的关系。您可以使用诸如宽带delphi规划扑克之类的估算技术来利用此优势。

作为初级开发人员,现在就开始跟踪估算值和实际时间。您可能对阅读软件工程学院开发的个人软件过程感兴趣。PSP的核心书籍是《软件工程学》,《PSP:软件工程师的自我完善过程》《个人软件过程简介》。我相信“个人软件过程简介”将涵盖您认为最有帮助的主题。我认为对于大多数开发人员来说,这通常是过高的,但是它确实有一些好的想法和好的实践经验,可以加以借鉴和使用,以提高个人生产力并磨练在职业生涯中会不断使用的各种技能(包括估算)。

如果您将在估算方面做更多工作,我强烈推荐史蒂夫·麦康奈尔(Steve McConnell)的两本书:软件估算:揭秘妖术(侧重于艺术和科学方面的估算)和快速开发:驯服野性软件时间表(通用软件)工程流程和项目管理主题)。


7

参考文献。有大量复杂且通常相互矛盾的材料,经实践(实验)证明,这些材料不能按预期工作。至少学者们被一堆书所左右。

必须阅读:http : //en.wikipedia.org/wiki/The_Mythical_Man-Month

《神话人月:软件工程论文集》是弗雷德·布鲁克斯(Fred Brooks)撰写的一本有关软件工程和项目管理的书,其主题是“在较晚的软件项目中增加人力会使它变得更晚”。这个想法被称为布鲁克斯定律,并与第二系统效应和原型倡导一起提出。

Brooks的观察基于他在IBM管理OS / 360的开发中的经验。他在一个进度落后的项目中增加了更多的程序员,这一决定后来反直觉地得出结论,使该项目进一步推迟了。他还犯了一个错误的说法,即不管涉及多少工人(需要更长的时间),编写一个ALGOL编译器项目都将需要六个月的时间。经理人倾向于在项目开发中重复这样的错误,导致布鲁克斯嘲笑他的书被称为“软件工程圣经”,因为“每个人都引用它,有人读过它,而有些人则忽略了它”。这本书被广泛认为是软件工程中人为因素的经典著作。


2

找出他们打算用这个估计做些什么。他们想知道这是需要几个月还是几年,而您正在尝试获取确切的小时数(典型工程师)。

看看您是否可以处理项目的一部分,然后根据需要进行更好的估算。

如果他们继续努力,那么您将被迫逐项列出尽可能多的任务。告诉他们,一旦您发现任何可能影响估计值并进行调整的信息,便会立即告知他们。人们通常会尽量避免出现意外。


1

我遇到了一些声称可以估算软件的人,但是我不知道他们是如何做到的。他们中的任何一个都无法解释他们是如何做到的。

作为顾问,我的客户经常要求我以固定出价的方式工作。因此,我需要估算一下,以便我可以准备一个实际的报价。我从来没有成功过。有人会认为我会比我低估的次数多,但事实并非如此。结果是,我经常在合同中损失很多钱,最终收入要比我在一家正规公司工作时要少得多。

我一直在寻找一本可以教我如何估算软件的书,但是我还没有找到。

至于向不是编码员的人解释这一点。您可能会指出,行业内没有人能够始终如一地满足他们的估计。新软件产品一直在进行预发布,只是在最初发布日期之后的几个月或几年内才发布。

如果像Microsoft这样的大公司无法弄清楚如何估算自己生产产品的时间,我该怎么办?

不论我是按小时还是按时领薪,我的客户始终希望我提供这些估计。我不知道在任何地方都没有这样的估计时,他们如何期望我产生这些估计,而且我没有合理的估计依据。


1
史蒂夫·麦康奈尔(Steve McConnell)的书《软件估算:揭秘妖术》非常善于解释软件工程师的估算方式。您可以学习技术和工具,但是擅长估算的唯一方法是不断估算,从估算中学习并重复。至于没有人能够始终如一地达到估计值,有些组织的估计值始终在几个百分点之内-McConnell的书谈到了实现这一目标的组织(通常是CMMI 4级或5级,具有持续的改进和详细的跟踪)始终如一。
Thomas Owens

至于您的估算错误的问题。您是否跟踪估算与实际完成时间?如果是这样,请确定您低估了什么因素,然后将所有估算值乘以该数字。
kubi


0

整个项目时间的估算通常由项目经理而非程序员执行。

您可以基于项目经理具有所需任务的完整列表这一事实来构建自变量。没有此列表,任何估计都将是“错误”的猜测。

另外,时间取决于许多因素,例如有多少人可用以及需求范围,而您并未说过。仅仅架构是不够的。


根据项目管理方法,项目经理甚至可能没有完整的任务清单。在诸如滚动项目管理之类的东西中,通常会有一个模糊的桶描述非常高的任务水平,通常太大而无法以任何适当的置信度进行估算。随着先前任务的完成,存储桶中的任务部分得到了更好的定义,并且可以进行估计。在敏捷方法中,经常在各个位置添加,删除或重新安排任务的优先级,这又使估算几次迭代之后的长期里程碑变得更加困难。
Thomas Owens

0

您可能要说的另一点是,与其他工程领域相比,软件工程仍处于起步阶段,并且还不够成熟,无法出现可估算的开发技术。

软件工程也处于不断变化的状态。当一种技术已经足够成熟到可以被认为已经成熟时,它常常被一些新技术所取代。这会阻止任何人获得任何一种技术的足够经验,从而无法得出可靠的估计。

将此与施工估算进行对比。这是一个非常容易理解的问题,这不仅是因为合同是根据竞标授予的,而且还因为人类自文明诞生以来就一直在建设事物。


1
(到目前为止)软件工程还比大多数其他工程学科年轻(42岁)。但是,有许多成熟的估算技术和工具。宽带delphi(1970年代开发,由Barry Boehm的软件工程经济学在1981年流行),功能点(1979年),SEER-SEM(起源于1960年代),基于代理的估计(用于PSP中,于1994年在(SEI),COCOMO(1981)和COCOMO II(1997)。在仅42年的领域中,已经有将近40年的项目估算工作。
Thomas Owens
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.