freeCodeCamp/guide/chinese/agile/actual-time-estimation/index.md

53 lines
4.2 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

---
title: Actual Time Estimation
localeTitle: 实际时间估计
---
## 实际时间估计
实际时间估计是预测基于不完整,不确定和嘈杂输入开发或维护软件所需的最实际的努力量(以人 - 小时或金钱表示)的过程。努力估算可用作项目计划,迭代计划,预算,投资分析,定价流程和投标轮次的输入。
### 国家的实践
已发布的估算实践调查表明,在评估软件开发工作时,专家评估是主要策略。
通常情况下工作量估算过于乐观并且对其准确性存在强烈的过度信任。平均努力超支似乎约为30而不会随着时间的推移而减少。有关工作量估算误差调查的评论请参阅。但是估算误差的测量存在问题请参阅评估估算的准确性。平均而言如果软件专业人员有90的信心或“几乎肯定”将实际工作量包括在最小 - 最大间隔内则可以看出工作量估算准确性的强烈过度自信包括实际工作量仅为60-70
目前“努力估计”一词用于表示不同的概念如最有可能使用努力模态值相应于50不超过中位数概率的努力计划的努力预算的努力或用于向客户提出出价或价格的努力。这被认为是不幸的因为可能发生通信问题并且因为概念服务于不同的目标。
### 历史
自从至少20世纪60年代以来软件研究人员和从业人员一直在解决软件开发项目的工作量估算问题;比如,见法尔和尼尔森的作品。
大多数研究都集中在正式软件工作量估算模型的构建上。早期模型通常基于回归分析或数学上来自其他领域的理论。从那时起,已经评估了大量的模型构建方法,例如基于案例推理的方法,分类和回归树,模拟,神经网络,贝叶斯统计,需求规范的词汇分析,遗传编程,线性规划,经济生产模型,软计算,模糊逻辑建模,统计自举以及这些模型中的两个或更多个的组合。
目前最常见的估计方法是参数估计模型COCOMOSEER-SEM和SLIM。它们的基础是在20世纪70年代和80年代进行的估算研究并且从那时起更新了新的校准数据最后一个主要版本是2000年的COCOMO II。估算方法基于基于功能的尺寸测量例如功能这一点也是基于20世纪70年代和80年代进行的研究但是采用改进的尺寸测量和不同的计数方法进行了重新校准例如20世纪90年代的用例点或对象点以及2000年代的COSMIC。
实际时间估算是一种估算开发工作的基于时间的方法。
能够估计敏捷项目的完成时间至关重要,遗憾的是,它也是规划敏捷项目最困难的部分之一。
其目的是最好地估计完成给定开发任务所需的时间量。
您可以使用的一种技术是估计完成用户故事所需的时间。当您这样做时,请记得咨询敏捷团队的其他成员。对于每个用户故事,请确保您估计一个现实可行的时间,但不要太多,以至于客户端因简单工作而被多收费用。咨询您团队的成员,以便您能够利用他们的专业知识来了解需要多少工作以及需要多长时间。当您对每个用户故事达成共识时,您可以累计时间来进行时间估算。
随着项目要求的变化,您可以更新估算值。如果项目丢失了最初分配给它的一些资源,您可能需要剪切用户故事,以便能够在相同的总时间内完成它们。同样,如果您想提高应用程序的质量,您可能需要为每个用户故事分配更多时间,以确保您的团队有时间以所需的质量完成应用程序。
通常,这些估算是使用理想的工程时间计算的。
例子:
**此任务将在10天内完成。**
要么…
**这项任务将于1月10日完成。**
要么…
**此任务需要25个开发时间才能完成。**
### 更多信息:
* [敏捷约束](http://www.brighthubpm.com/agile/50212-the-agile-triangle-value-quality-and-constraints/)
* [您如何评估敏捷项目?](http://info.thoughtworks.com/rs/thoughtworks2/images/twebook-perspectives-estimation_1.pdf)