进度估算问题

[weiwill]

使用comcmmo模型进行进度估算时，如cocomo81:
Duration=2.5*(Effort)**0.32
按照这个公式对于60个人月以上的大项目，比较合适。但如果是8个人月或者极端点1个人月的小项目，得到的工期就太长了。
请问谁有针对小项目的更好进度估算公式？
谢谢！

[项目花园范德彪]

大 需求 15%
设计 12%
编码 36%
单元测试 9%
综合测试 9%
确认测试 7%
发布 12%
中 需求 13.5%
设计 21%
编码 27%
单元测试 7.5%
综合测试 14%
确认测试 8%
发布 9%
小 需求 13%
设计 17%
编码 28%
单元测试 6%
综合测试 14%
确认测试 16.7%
发布 5.3%


另外偏差也不一样,大的不能过10%,而小的可以到达20%呀,

方法也不太一样呀,

[weiwill]

谢谢!您提供的比例非常有参考价值，
但是您可能没有理解我的问题。
我的问题是如何从工作量（人月）换算成总的进度时间（月），有无针对小项目的公式？

[wolftop]

看看人月神话吧~!

[a00]

没有公式，总的来说跟你的资源分配和关键任务有关。

[饮水需思源]

还应考虑其他因素

[YiYanXiYin]

我就是一个简单的程序员，刚刚接触软件工程/管理方面的一点点知识
我在看《人月神话》的时候，也觉得书上的很多观点我也不能正确的理解
我发贴的目的就是为了想通过大家的回答来澄清一些观点，谢谢zhf_karen(zhf)的经验之谈

[YiYanXiYin]

神话的人月（ The Mythical Man Man-Month Month）
在众多软件项目中，时间进度的缺乏是造成项目偏移的最主要原因，比其他所有因素加起来影响还大。
导致这种普遍性灾难的原因是什么呢？
首先，缺乏有效的估算技术。更加严肃的讲，它反映了一种无声，但并不真实的假设——一切都将运作的很好。
第二，我们采用的估算技术，错误地将进度与工作量相混淆，隐藏了人和月是可以互换的假设。
第三，由于对估算不确定，所以我们缺乏一种谦逊的坚持。
第四，对安排的进度缺少跟踪和监督。在其他工程领域被验证的技术和常规的程序在软件工程中往往是快速演化的。
第五，当进度的偏移被识别时，自然（且传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而开始了一场注定导致灾难的循环。
进度监督是另一篇论文的主题。本文我们对该问题的其他方面进行更详细的考虑。
乐观主义所有的编程人员都是乐观主义者。可能这个现代的魔术特别吸引那些相信美满结局的人。可能成百上千琐碎的挫折赶走了所以的人，除了那些习惯上只关注结果的人。可能仅仅因为计算机还很年轻，程序员更加年轻，而年轻人总是些乐观主义者。但不管所选择的过程如何工作，结果是勿庸置疑的：“这次它肯定会运行。”或者“我刚刚找出了最后一个错误。”所以系统编程的进度安排背后的第一个假设是：一切将正确运作。即每一项任务仅耗费它所“应该”花费的时间。
对这种在编程人员中乐观主义的弥漫理应受到慎重的分析。Dorothy Sayers 在她的《The Mind of the Maker》一书中，将创造性活动分为三个阶段：构思、实现和交流。书籍、计算机、或者程序的出现是首先作为一个构思概念或模型，在时间和空间之外构建，而在作者的脑海中完成。它们通过钢笔、墨水和纸，或者通过电线、硅片和铁氧体，在现实的时间和空间中被实现。当某人阅读书本、使用计算机和运行程序的时候，创作过程得以结束，从而与创意的作者相互交流。
以上Sayers 的阐述不仅仅可以描绘人类创造性活动，而且描述基督教义的形成过程。它可以协助我们日常的工作。对于创造者，我们构想的不完整性和不一致性只有在实现的过程中才能发现。因此，对于理论家而言，书写、试验以及“工作实现”是基本、必要的部分。
许多创建性的活动中，实施的媒介很难掌握，如木头切割、油漆、电器安装。这些媒介的物理约束限制了能被表达的构思，同样它们对实现造成了预料之外的许多困难。
由于物理媒介和构思背后的不完善，创造性的实现需要花费大量的时间和汗水。对遇到的大部分实现上的困难，我们总是责怪那些物理的介质；因为它们并不是顺应“我们”构思的思路，且我们的骄傲主观引导了我们的判断。
相应的，计算机编程基于非常容易掌握的介质。编程人员凭空通过思考来创建程序，即概念和和非常灵活的表达。因为介质的易于驾驭，我们期待在实现的过程中不会遭遇困难；因而造成了乐观主义的弥漫。而由于我们的构思是具有缺陷的，因此会有Bug；所以我们的乐观主义并不是得到认可的。
在单个的任务中，“一切都将运转正常”的假设在时间进度上具有随机性。由于将遭遇的延迟具有一定的概率分布，所以事实可能如计划安排的那样，而“不会延迟”仅具有有限的概率。大型的编程工作，或多或少包含了许多任务，某些任务间具有前后的次序。而一切正常的概率变得非常小，接近于无。
人月第二个谬误的思考方式是在估计和进度安排中使用的工作量单位：人月。成本的确随产品的人数和时间的长短变化非常大。进度却不是如此。从而使用人月作为测量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人数和时间是可以相互代替的。
人数和时间的互换仅仅适用于某个任务可以被分解给参与的人员，并且他们之间不需要相互交流（图2.1）。这在割小麦或收获棉花时是可行的；而在系统编程中近乎不可能。
图2.1（略）
当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助（图2.2）。无论多少个母亲，孕育一个生命都需要十个月。由于调试、测试的次序要求，许多软件均具有这种特性，图2.2（略）
对于可以分解，但子任务之间需要相互沟通、交流的任务，沟通的工作量必须添加到待完成的工作中。
因此，相同人月的前提下，使用人数的增加来减少时间的最好情况也较未调整前也要差一些（图2.3）。
图2.3（略）
沟通所增加的负担由两个部分组成，培训和相互的交流。每个成员需要进行技术上的、项目目标以及总体策略上的培训。这种培训不能被分解，因而这部分增加的工作随人员的数量线性的变化。
相互之间交流的情况更糟一些。如果任务的每个部分必须分别同其他的部分单独的协作，则工作量按照n(n-1)/2 递增。单对单交流的情况下，三个人工作量是两个人的三倍；四个人则是两个人的六倍。而如果需要在三个、四个人之间召开会议，大家共同的解决问题，情况变得更糟。所增加的沟通的工作量可能会完全抵消对原有任务的分解，则我们会被带到图2.4 的境地。
因为软件构建本质上是一项系统工作——相互错综复杂关系下的一种实践——沟通、交流的工作量非常大，它很快会支配源于任务分解所节省下来的个人时间。从而，更多的人手的添加，实际上延长了，而非缩短了时间进度。

[YiYanXiYin]

用人月作为单位来估计项目的工作量的错误的
“人月是危险和带有欺骗的神话，因为它暗示人员数量和时间是可以相互替换的。”

[zhf_karen]

嘿嘿，我对于人月神话倒是有一些自己的看法，人和月之间的确不能互换，因为人月更多是一个成本因素，而不是一个时间因素。所以用人月来兼顾成本和时间，就必然会发生错误。但是，用人月来估算成本，我个人觉得并没有什么太大问题，事实上，我们估算成本从根本上，还是依照工作能够分割，能够量化，并且能够衡量成为标准人工的初始条件来确定的，不然任何估算都无法展开；

无论干特图和人月，都存在一些即使从逻辑上来说的不可靠性，但是，现在我们没有更好地选择。至少管理层不会如此看待问题。因为我们是在做工程而不是技术研究工作；

比如说一点：增加人员能否加速项目推进？在很多情况下，中期切入人员还是能够提高的，在晚期，如果有合适的测试大纲和详细设计，工作能够拆分，那么还是可行的；至少在我的项目管理过程中所搜集的数据来看，即使晚期加入人员，也能部分提高推进效率，即使这些效率是用2-3倍成本来提高的。

不要告诉我别人是如何说的，告诉我你是如何理解的？抄书是研究生论文干得事情，不是我们工程人员干得事情。告诉我你的事实是什么？你的解决方案是什么？我喜欢一句话：你不说，我不说，我们用数据来说话！

告诉我，大家不用人月衡量成本，用什么衡量成本？是否有更好的方式？FP方法，讲白了，就是更精致的人月概念。

虽然我不喜欢人月这个概念，但是我更不喜欢什么都是抄书的概念！