8.6 如何预估任务的时间？

[GreyZeng]

原文出自《构建之法》第 8 章 8.6 —— 计划和估计

软件项目计划的一个重要环节就是估计项目各类工作(特别是各种功能)所需的时间。

软件项目的难度还体现在另一个方面，软件工程师的【能力】没有合适的衡量单位，而且大部分依赖于估计值。例如，如果移山公司的程序员果冻一天能写一千行C++代码，那他10天就 能写好一万行代码?!而且什么叫写好一万行代码?如果你估计一个项目的代码量是10万行， 难道10个像果冻这样的人10天就能做完?
————————————————
版权声明：本文为CSDN博主「wangxiaoge2001」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/wangxiaoge2001/article/details/131262974

[GreyZeng]

在学期之初，我有如下观点：

正如书中所说，由于软件项目本身叠加了太多不可量化的因素，精确的估计一个项目所需的时间十分困难。针对这个问题，书中给出的解决方法有：参考前人经验（有些项目的难度有一定客观规律，谁来做都要花一定时间）、快速原型法（用一个小型demo快速试水、从而估计整个项目的时间）、Wideband Delphi方法（所有人在每一轮提出一个估计时间和解释说明，相互说服，最终在多轮迭代中达成统一意见）、经验公式法（Y = X ± X ÷ N Y=X±X\div NY=X±X÷N ）

作为一个喜欢计划的人，如何高效预估一个任务所需的时间，一直是我在思考的问题。比如，我在看到软工第一周作业——阅读和提问后，我并没有一开始就去空想我读一本400多页的书+提5-10个问题要花多少时间，而是先尝试尽可能快地去阅读，并提一两个问题。在完成上述工作后，我对整个任务所需的时间就有了个大致的估计，之后就可以不紧不慢地安排空闲的碎片时间来完成整个任务。事后复盘时我才发现，这和书中提到的快速原型法如出一辙。

但我认为上述方法还是有很多不完善的地方。快速原型法基于时间成本与任务量成线性关系的假设，但这在大规模工程中显然不一定适用。例如，对于一个由多个小项目组合而成的大项目，除了考虑每个小项目本身的时间成本外，还需要考虑将小项目组合成大项目的时间成本。此外，有些项目的技术还有学习成本，这上面的时间估计也具有很强的不确定性。

综上，在如何预估任务的时间上，虽然书中给出了较多的方法，但我仍然觉得难以上手。希望在经过一学期的软件工程实践后，我能在这方面有所提升。

经过了一学期的实践，我有如下体会：

在结对编程任务中，由于我们的题目和往年的题目有较高的相似性，我采用了“前人经验法”来预估任务花费的时间。在实际执行后，我发现“前人经验法”的一个重要问题是，每个前人本身的技能树差异较大，最终实现的软件质量也参差不齐，因此“前人经验”本身的方差就很大。更加合理的方式是根据前人经验先得到一个统计学结果，再结合自己的技能树来做一定偏差估计。

在团队项目中，我们并没有具体估计每个任务需要花费多少时间，而是采用了每一到两天分配一个有明确验收标准的子任务的方式。在分配任务时，我们本身也留了一定的冗余天数，因此如果某个任务在原本分配的期限内未全部完成，我们可以根据反馈及时做出调整，例如分配更多的资源到这个任务上。
————————————————
版权声明：本文为CSDN博主「wangxiaoge2001」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/wangxiaoge2001/article/details/131262974