DDL就是生产力？为什么我们无法准确估计项目用时？

最新推荐文章于 2024-06-18 16:10:07 发布

「已注销」

最新推荐文章于 2024-06-18 16:10:07 发布

阅读量907

点赞数 1

文章标签：人工智能编程语言软件开发 weex ai

本文链接：https://blog.csdn.net/duxinshuxiaobian/article/details/109792463

版权

全文共2500字，预计学习时长7分钟

图源：unsplash

就算你是高级项目经理，就算你拥有20年的项目经验，就算你是天才也无法确切地知道一个项目的确切用时。这个问题在软件工程中尤为普遍，但在其他的工程学科中也时有发生。因此，虽然本文主要关注的是软件工程相关问题，一定程度上也适用于其他学科。

普遍存在的事实是，软件项目很少能够按时完成。带来的后果是，营销的努力可能会被浪费，客户可能会不满意，压力重重的开发人员可能会编写质量很差的代码来赶deadline，产品的可靠性岌岌可危。最终，项目可能会直接被取消。

已知原因如下：

· 错误地时间估计（本文重点）。

· 项目开始时需求不明确，之后发生了需求变化。

· 过分关注了工作外的细节。

· 在研究和架构设计阶段没有花足够的时间，也可能花了太多地时间。

· 忽略了第三方集成的潜在问题。

· “一次解决”地愿望过于强烈。

· 同时做太多项目或其他原因分心（打断完整流程）。

· 质量和产能规模不平衡。

邓宁-克鲁格效应：纯粹的不确定性or只是数学问题？

规定时间内做不完，是不是因为我们过度乐观了呢？人们常常会忽略这个问题，常识告诉我们，在临近最后期限时，任何赶工的开发人员都不会是乐观的。

有人将错误的时间估计归因于邓宁-克鲁格效应。但如果只是缺乏经验，高估了自己的能力或是低估了任务所需的时间，经验肯定能缓解这种境况。然而那些拥有近乎无限资源大公司，也常常错过截止日期，所以这个归因是不成立的。

大多数开发人员，特别是有经验的开发人员，会认为这纯粹是因为不确定性，计划赶不上变化嘛。我们唯一能做的是，努力满足客户的需求，在事情出错的时候抓紧时间。我们都熟悉工作压力、垃圾代码和挑战截止日期时所造成的绝对混乱。

这种焦虑有解决办法吗？这就是我们应对这个问题的最好方法吗？笔者并不这么认为，我试图找到一个合理的数学解释，解释为何所有的“聪明人”都无法估算他们做某件事需要的时间。

纯数学解释

有一天，我做了一项本该10分钟完成的任务，结果却花了2个小时。我开始思考其中误差的根本原因，思考过程如下：

· 我认为这需要十分钟，因为我的脑子里百分之百知道我需要些什么代码。

· 完成代码确实只花了我7-10分钟，最后总共用了两个小时，因为我没有预料到框架中的一个Bug。

人们喜欢在项目管理中被称之为“不可抗力”，即延迟的外部不可控原因。读者可能会认为我的归因不具有代表性。当然，不确定性是这个任务延迟的根本原因是我根本没有猜到Bug的存在，但是这应该对整个项目的延误负责吗？这就是需要去做区分的地方：单个任务不能代表整个项目，反之亦然。

人们通常是如何估计时间的

通常的分布

正态分布存在于我们身边各处，人类的大脑已经对此习以为常。

如果你一个月去附近的711大概20次，每次大约五分钟。有时电梯需要维修，必须多等待10分钟，也有可能在下雨，你需要多等几分钟直到雨停。考虑这些情况，你现在觉得去一趟711要花多少时间？还是五分钟吗？

笔者的意思是，就算回答15分钟，这个答案也是没有意义的，因为下雨和电梯维修是罕见事件，五分钟可能就是正确答案。如果20次里有18次都只需要五分钟，那么这次很可能就的确只需要五分钟（作为中值），可能性大约有90%。（在不考虑更复杂代数的情况下）。

倾斜

即使很擅长估计一项任务的所需时间，也不意味着很擅长估计项目所需的时间。这常常是反直觉的。你肯定已经意识到之前模因中的小图表是一个右偏正态分布。让我们来具体看看：

对于单一任务，中值比均值的猜对正确率更高。但如果是其中最大的模式值，那在整个项目的大范围内会错的更离谱。

这里会出什么问题呢？人们常用的“自然猜测”基于中位数，使猜中的概率最大化。然而在事件数量足够大时，答案总会更接近均值。所以，执行的任务越相似，累计的估计错误就会越多。

基于该假设的延迟方程。

项目中的编程任务往往非常相似，或可以分配到类似的任务集合中。这个等式还表明问题可以进一步扩展。虽然我们希望软件项目中的一切任务时间都是可伸缩的，但是出现问题总是不受欢迎。

那么如何使用该知识呢？

说实话，在写这篇文章的时候我并没有想根据这个假设给出什么时间估计的“指示”，这只是一种探索性的分析，以一种假说结尾。如何使用与解释则取决于你自己。当然，我知道很多人会对这个开放式的结论感到失望。个人的结论如下：

· 与任务Y相比，判断任务X是否会花费更多/更少/相同的时间，要比准确地判断它们会花费多长时间更容易。这是因为，如果曲线的偏度大致相同(类似的任务也是如此)，比较中值和比较平均值一样有效。

· 我不会回忆或记录每一个类似的任务来计算花费时间的平均数(也找不到任何数据来进行这种估算)。因此，我通常根据对开发环境的适应程度(比如我喜欢这种语言/框架吗)来估计不可避免的错误(均值减中值)在任务时间中所占的百分比。我有好的调试工具吗?(30%)，有没有良好的IDE支持?(25%)等。

· 我开始把冲刺分成同等大小的任务，这是为了在时间估计过程中创造一致性。这让我受益于第一点，它应该很容易判断两个任务在时间上是否大致相等。这也使得任务更加相似，使得假设适用的更加完美，事情也变得更加可预测。

· 应用这些原则后，如果有项目资源，就可以进行“测试运行”。例如，如果在X1天内Y1开发人员完成了统一任务Z1，那么我们可以很容易地在已知Y2(可用开发人员)和Z2(剩余任务总数)求出X2（剩余开发时间）。

造成项目延迟的原因有很多，本文也只是其中之一。做到精准预估用时真的很难，我们只能向着这个终极目标不断靠近。

推荐阅读专题

留言点赞发个朋友圈

我们一起分享AI学习与发展的干货

编译组：董昱粲、张静影