文章图片
对于单一任务 ， 中值比均值的猜对正确率更高 。 但如果是其中最大的模式值 ， 那在整个项目的大范围内会错的更离谱 。 这里会出什么问题呢？人们常用的“自然猜测”基于中位数 ， 使猜中的概率最大化 。 然而在事件数量足够大时 ， 答案总会更接近均值 。 所以 ， 执行的任务越相似 ， 累计的估计错误就会越多 。 基于该假设的延迟方程 。 项目中的编程任务往往非常相似 ， 或可以分配到类似的任务集合中 。 这个等式还表明问题可以进一步扩展 。 虽然我们希望软件项目中的一切任务时间都是可伸缩的 ， 但是出现问题总是不受欢迎 。 那么如何使用该知识呢？说实话 ， 在写这篇文章的时候我并没有想根据这个假设给出什么时间估计的“指示” ， 这只是一种探索性的分析 ， 以一种假说结尾 。 如何使用与解释则取决于你自己 。 当然 ， 我知道很多人会对这个开放式的结论感到失望 。 个人的结论如下：·与任务Y相比 ， 判断任务X是否会花费更多/更少/相同的时间 ， 要比准确地判断它们会花费多长时间更容易 。 这是因为 ， 如果曲线的偏度大致相同(类似的任务也是如此) ， 比较中值和比较平均值一样有效 。 ·我不会回忆或记录每一个类似的任务来计算花费时间的平均数(也找不到任何数据来进行这种估算) 。 因此 ， 我通常根据对开发环境的适应程度(比如我喜欢这种语言/框架吗)来估计不可避免的错误(均值减中值)在任务时间中所占的百分比 。 我有好的调试工具吗?(30%) ， 有没有良好的IDE支持?(25%)等 。 ·我开始把冲刺分成同等大小的任务 ， 这是为了在时间估计过程中创造一致性 。 这让我受益于第一点 ， 它应该很容易判断两个任务在时间上是否大致相等 。 这也使得任务更加相似 ， 使得假设适用的更加完美 ， 事情也变得更加可预测 。 ·应用这些原则后 ， 如果有项目资源 ， 就可以进行“测试运行” 。 例如 ， 如果在X1天内Y1开发人员完成了统一任务Z1 ， 那么我们可以很容易地在已知Y2(可用开发人员)和Z2(剩余任务总数)求出X2（剩余开发时间） 。 造成项目延迟的原因有很多 ， 本文也只是其中之一 。 做到精准预估用时真的很难 ， 我们只能向着这个终极目标不断靠近 。

文章图片

文章图片
推荐文章阅读

文章图片

• 千元预算，拿下27寸144Hz高刷曲面屏，问就是满满环绕感
• 保护企业数据安全 绝不仅仅就是碎个纸
• 这就是瑞典的公平？华为5G遭多方反对，爱立信居然为华为出头？
• 新版微信迎来重大更新，这4个功能悄悄上线，学到就是涨知识
• 单反开始贬值了？全画幅无反这样转，你就是赢家
• 华为手机，以及荣耀投入的软件成本不一样，这就是隐形价值的体现
• MIUI很出色，唯一不满意的地方就是：多任务，打开慢
• 小米王腾：iPhone12就是涨价了，不是加量不加价
• 数据|面对“大数据杀熟”“干”就是了
• 这就是我不买iPhone12的原因