敏捷项目进度怎么估算_您项目的最佳估算方法是敏捷的还是传统的？

任何项目负责人所需的主要技能之一是具有良好的工作量估计。 掌握估算至关重要，因为它会严重影响项目交付的截止日期。 不正确的估算会严重影响任何项目的成本和盈利能力。 它还影响所有团队成员和客户对项目负责人的看法和信任。 知道如何估算对于所有团队成员都是至关重要的，因为他们都参与估算过程。 毫无疑问，整个团队建立这种能力至关重要。 但是，我们必须承认在软件行业的评估过程中我们面临的挑战，因为几乎不可能简单地复制相同的项目并假设所有评估都可以维持。 每个项目总是带有一组新的需求，风险，技术，团队成员等等。 估计挑战可以概括为：

学到更多。 开发更多。 连接更多。

新的developerWorks Premium会员计划可通过Safari图书在线访问强大的开发工具和资源，包括500项顶级技术标题（数十种专门针对Web开发人员），获得顶级开发人员活动的折扣，最近O'Reilly的视频重播，会议等。 立即注册 。

• 极端估计可能过于乐观或过于悲观。
• 个人错误地认为估算是一种承诺。
• 对适应可能影响估计的新出现因素的抵抗。
• 缺乏可以提供估计基础的专业知识或历史信息。
• 项目范围或业务要求的不确定性。
• 不良的风险缓解计划。
• 无法衡量的临时活动，例如会议，假期，演示，原型。
• 缺乏使用更新的工具和流程来跟踪估计的方法。

为了获得这项技能，每个人都需要知道他们可以使用哪些选项。 可以使用哪些不同的技术？何时使用？ 本文介绍了各种估算技术，这些技术可帮助控制项目并改善决策。 本文首先概述了一些流行的常规方法，然后介绍了一些敏捷技术。 本文最后总结了敏捷开发与传统方法之间的比较。 您还将学习一组要素，以使自己成为更好的估算者。

常规估算方法

许多项目估算是根据以前的项目历史或主题专家（SME）的专业知识建立的。 在下一节中，您将学习着重于项目之间相似性的方法。

历史资料

PROBE（基于代理的估计）

卡内基梅隆大学软件工程学院的Watts Humphrey将该技术创建为PSP（个人软件过程）的一部分。 它基于以下思想： 如果工程师正在构建与以前构建的组件相似的组件，则将花费与过去相同的精力 。 在PROBE技术中，保留了一个存储库，其中包含以前构建的每个组件的所有详细信息。 然后，当需要估算新项目时，将其分解为与历史信息匹配的组件。 然后使用公式来计算每个任务的估算。

可可二世

1980年，开发了建设性成本模型（COCOMO）。 它基于对63个软件开发项目的统计研究结果进行分析。 十年后，引入了称为COCOMO II的更新版本，该版本涵盖了现代开发生命周期并使用了更广泛的数据集。 新模型采用一组输入变量，并根据先前研究的项目计算目标估算值。

小组估算

宽带德尔菲 （ Wide Band Delphi）是1940年开发的一个过程。它取决于小组评估，项目经理选择主持人和评估小组。 主持人没有偏见并可以管理会议。 主持人还确保每个人都参与。 项目经理必须是估算团队的成员，以便团队知道需求的优先级。

该过程以启动会议开始，团队会熟悉项目目标。 会话的输出是任务的高级列表以及主持人编写并分发给团队的一组假设。 评估团队的每个成员分别创建一组准备结果，如图1所示，以便为下一次评估会议做准备。 始终可以添加其他任务或假设以进行进一步讨论。 在估算会话中，主持人向每个估算者分配一个空表格。 每个估算者都根据其准备结果填写估算表。

图1.准备结果

如图2所示，每个估计器都将任务列表与相应的估计和估计形式的假设放在每一行中。 然后，主持人收集此信息，并将其写到白板上进行第一轮。

图2.估算表

估算器之间的讨论涉及每个估算器使用增量列调整估算。 主持人每轮将新的估算值写在白板上。 请注意，在每个回合中，对估计的共识变得越来越紧密，如图3所示。这是可以预期的，因为团队成员的观点已得到澄清。

图3.白板上写的估算

在估算会议之后，项目经理将所有输出汇总到一个表中，并列出所有估算，最佳方案和最坏方案。 大的估计差异被标记为进一步讨论。 项目经理召集最终审查会议，与估算员分享总结的结果，并允许进行更多的讨论或达成共识。

参数估计

参数估计方法使用历史数据和其他参数之间的关系，以便通过数学公式得出估计值。 一个简单的例子是：如果编写一个方法的估计时间是2个小时，那么编写50个方法将需要100个小时。 本节介绍了不同种类的参数估计。

用例点（UCP）

该技术于1993年开发。它基于统一建模语言（UML）中使用的用例来估计软件的大小。 UCP评估许多元素，例如用例参与者，技术复杂性和环境复杂性。 然后将它们全部放到公式中，以计算总体大小。

UCP =（UUCW + UAW）×TCF×ECF

公式键：

• UUCW ：用例权重未调整
• UAW ：未调整的演员体重
• TCF ：技术复杂性因素
• ECF ：环境复杂性因素

有关更多信息，请参阅用例点估计方法 。

功能点分析（FPA）

作为一个概念，它与用例点非常相似。 功能需求分为五类之一：输出，查询，输入，内部文件和外部接口。 然后根据功能的复杂性为其分配多个功能点。 使用以下数学公式，可以计算出估算值。

FP = UAF×VAF

公式键：

• FP ：功能点
• UAF ：未调整的功能点
• VAF ：价值调整因子

有关更多信息，请参阅FPA基础 。

三点估计

此方法通过使用程序评估和评审技术（PERT）解决估计的不确定性。 PERT技术根据三个估算值计算估算值，然后将其放入数学公式中以分析输出。

E =（O + 4M + P）/ 6

公式键：

• E ：估计
• O ：乐观的最佳情况
• P ：悲观的最坏情况
• M ：最可能的情况

有关更多信息，请阅读有关PERT技术的信息 。

敏捷估计方法

传统方法与敏捷方法之间的估计之间的核心区别在于相对估计概念的使用。 敏捷估算中没有数天或数小时的绝对估算。 而是使用故事点。 其背后的理由是，许多研究表明，在进行比较时，人类如何更准确。 例如，您可以携带两个袋子，估计一个袋子比另一个袋子重，但是您无法确定每个袋子的实际重量。 在以下各节中，您将学习一些敏捷估计中最流行的估计方法。

规划扑克

规划扑克是最流行的敏捷估计技术之一。 它保证所有成员都通过玩游戏积极参与。 游戏从向团队中的每个成员分发一组卡开始。 每组纸牌在很大程度上遵循斐波那契数列包含一个不同的数字：0、1、1、2、3、5、8、13、21、34，依此类推。 如图4所示，这些数字代表对故事的相对评估。 零表示故事太琐碎而无法追踪。 二十岁意味着故事需要分解成小故事。 使用斐波那契的基本原理是要创造不确定性，这将鼓励讨论，尤其是在进行大量讨论时。 现在回到游戏。 团队中的每个成员都开始估计某个故事，然后每个人都从他或她的角度显示包含该故事估计的卡片。 估计最高和最低值的成员解释了他们的观点。 作为回报，这些解释使整个团队重新思考推理，然后分享经验和假设。 整个团队一次又一次地重新评估故事，直到他们达成共识。 有关更多信息，请阅读《 规划扑克》 。

图4.计划扑克牌样本

T恤尺码

在这种方法中，将分发一组尺寸卡。 每个大小卡都包含一个特定的大小，即：特小（XS）; 小（S）； 中（M）; 大号（L）和特大号（XL）。 卡片水平分布在桌子上。 团队共同合作，将每个故事添加到适当的大小类别下。 整理完所有用户故事后，团队为每种大小放置一个等效的故事点，如表1所示。例如：XS是1个故事点，S是2个故事点，M是4个故事点，等等。 此方法确保所有故事都映射到故事点。

表1.故事点中映射的T恤尺寸

T恤尺寸	故事点
XS	1个
小号	2
中号	4
大号	6
加大码	10

同样，其他方法也鼓励使用更具创造性和趣味性的方法。 例如，使用吉娃娃最小，大丹犬最大的狗的体重。 另一个使用动物大小，例如，鼠标最小，大象最大。

估计大量故事

如果您需要快速估计大量故事怎么办？ 在这种情况下，请使用相对质量估计 。 这是一种快速分类和估计大量积压案例的方法。 要使用此方法，您需要为每个故事准备一张卡片。 主持人在桌子上拿着一套故事卡，拿起其中一张卡片，问团队：“这个故事被认为是大，中还是小？” 根据团队的回答，该卡将放置在桌子上的特定位置。 如果它很大，则该卡在桌子的左侧。 如果很小，则它位于表格的右侧。 如果中等，则将该卡放在桌子的中央。 转到下一张卡片，将询问相同的问题，并相对于之前的卡片放置新故事。 此过程将继续进行，直到所有故事都放在桌子上为止。

另一种类似的目标是快速估计大量待办事项的方法被称为Wall估计 。 这种方法使用一堵大空墙来对故事进行排序。 顶部的故事表示最高优先级，而底部的故事表示较低优先级。 这也可以水平在墙上确定故事的大小。 左侧的故事最小，而右侧的故事最大。

敏捷方法与传统方法中的估算之间的比较

每个人首先想到的问题是：“我应该使用哪种方法？” 和“哪种方法最好？” 好吧，这是一个有争议的问题，实际上没有正确的答案。 该领域有许多研究证明，这取决于许多因素，例如项目的类型。 表2列出了这些因素。

表2.敏捷方法和常规方法之间的比较矩阵

	敏捷方法	常规方法
项目规模	中小型项目	大型项目
软件生命周期	敏捷的生命周期。 例如，极限编程（XP）和Scrum	传统生命周期。 例如瀑布和螺旋
估算团队规模	通常从五点到九点。	可能少于五个。 在主题专家的情况下，它可以是一个成员。
团队合作	所有团队成员（例如产品所有者，开发团队，测试团队）的高度参与。	并非所有方法都鼓励所有团队成员的参与。
历史资料	估计方法并不要求存在历史信息。	大多数方法取决于历史信息。
估计时间	由于它基于对估计数达成共识，因此可能需要更长的时间。	与敏捷方法相比，可能花费更少的时间。
指示系统	点的复杂性。 例如，故事点的大小。	参数点。 例如，功能点分析和用例点。
估算原理	相对估计。	绝对估算。

成分更好地估计

为了使您的项目成功，创建良好的估算至关重要。 估计是计划中最重要的元素之一。 估算越好，对可交付成果的控制就越好，浪费的成本也就越少。 那么，如何衡量您的估计是否正确？ 比较估计值与实际值之间的差异。 根据定义，一个好的估计值是在75％的时间内达到实际结果的25％以内（Conte，Dunsmore和Shen 1986）。
无论您选择采用哪种估算技术，都有一些绝对可以使它变得更好的因素。

• 估计技术意识。 您需要熟悉所有估算方法，才能知道哪种方法最适合您的项目。
• 使用小任务单位。 您将任务分解成较小的部分越多，您对完成任务需要多长时间的了解就越多。 通常，任务的估计完成时间应在实际完成时间的两天内。
• 团队合作。 让您的团队参与评估可以消除任务的任何模糊性。 它有助于交换信息和专业知识，从而达到更好的估计。 它还增加了估算和任务的所有权。
• 提出正确的问题。 每个任务都包含歧义。 您需要提出正确的问题，然后尝试寻找答案，以消除这种歧义。 将假设放在一边，以便对任务的边界和风险达成共识。
• 记录您的实际努力。 从先前的估计中学习绝对是一个附加值。 您需要保留实际估计的记录以供历史参考。

结论

要成为更好的估算器，您需要了解和探索不同的估算技术。 重要的是要知道可用的选项以及哪个选项可以满足项目的需求。 本文提供了在敏捷方法和常规方法下的估计技术的完整列表。 它只给您足够的信息来理解基础知识并熟悉每种技术。 比较敏捷方法和传统方法的矩阵将帮助您决定使用哪种方法。 有了一般建议和技术概述，您将是一个更好的估算者。

翻译自: https://www.ibm.com/developerworks/library/d-estimation-agile-or-conventional-trs/index.html