内容


您项目的最佳估算方法是敏捷方法还是传统方法?

准确的估算可能决定项目的成败

Comments

简介

任何项目领导都需要具备的主要技能之一,就是对工作量估算具有良好的认知。精通估算非常重要,因为这会对项目交付期限带来很大影响。不准确的估算会显著影响任何项目的成本和盈利能力,还会影响所有团队成员和客户对项目领导的看法和信任。知道如何估算对所有团队成员都不可或缺,因为他们都会在估算过程中发挥一定的作用。毋庸置疑,整个团队建立这种能力至关重要。但是,我们需要认识到我们在软件行业中的估算过程中面临的挑战:几乎无法复制同一个项目,并假设所有估算结果都将保持不变。每个项目始终具有一组新的需求、风险、技术、团队成员等。估算挑战可总结为:

  • 可能太乐观或太悲观的极端估算。
  • 个人对估算是一种承诺的错误认知。
  • 拒绝适应新出现的因素可能影响估算结果。
  • 缺乏可为估算结果提供初步基础的专业技能或历史信息。
  • 项目范围或业务需求的不确定性。
  • 糟糕的风险阻碍计划。
  • 无法度量的临时活动,比如会议、假期、演示、原型设计。
  • 无法使用更新的工具和流程来跟踪估算。

为了获得此技能,每个人需要知道他们可使用哪些选项。可使用哪些不同的技术和应何时使用它们?本文将介绍各种有助于控制项目和改善决策的估算技术。本文首先会概述一些流行的传统方法,然后展示一些敏捷技术。文章最后将对敏捷开发与传统方法进行总结比较。您还将了解成为更优秀的估算人员所需的一组要素。

传统估算方法

许多项目估算结果是以过去的项目历史或主题专家 (SME) 的专业技能作为指导来建立的。在下一节中,您将学习一些专注于项目之间的相似性的方法。

历史信息

PROBE(基于代理的估算)

此技术是卡耐基梅隆大学的软件工程研究所的 Watts Humphrey 作为 PSP(个体软件过程)的一部分而创建的。它基于的理念是,如果工程师在构建某个类似他以前构建的组件的组件,那么它将花费与过去相同的工作量。PROBE 技术中,一个存储库包含之前构建的每个组件的所有详细信息。然后在需要估算一个新项目时,它会分解为与历史信息匹配的组件。然后使用一个公式来计算每个任务的估算时间。

COCOMO II

1980 年开发了构造性成本模型 (Constructive Cost Model, COCOMO)。它基于对 63 个软件开发项目的统计调查结果的分析。10 年后,引入了一个名为 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)

作为一个概念,它非常类似于用例点。功能需求 分类到 5 个类别中的一个:输出、查询、输入、内部文件和外部接口。然后基于功能的复杂性为其分配一些功能点。使用下面这个数学公式来计算估算结果。

FP = UAF × VAF

公式各部分:

  • FP:功能点
  • UAF:未调整的功能点
  • VAF:值调整因素

有关更多信息,请参阅 FPA 的基础

3 点估算

此方法使用项目评估和评审技术 (Program Evaluation and Review Technique, PERT)。PERT 技术基于 3 种估算结果来计算估算结果,将输出放在一个数学公式中来进行分析。

E = (O + 4M + P) /6

公式各部分:

  • E:估算结果
  • O:一种乐观的最佳案例场景
  • P:一种悲观的最糟案例场景
  • M:最可能的场景

有关更多信息,请参阅 PERT 技术

敏捷估算方法

传统估算方法与敏捷估算方法之间的一个核心区别在相对估算概念的使用上。在敏捷估算中,没有绝对的估算天数或小时数。相反,使用故事点。此做法背后的理由是,许多研究证明人们在估算中使用对比时结果更准确。例如,您可携带两个包,估计一个包比另一个包更重,但您不能确定每个包的实际重量。在以下各节中,您将学习敏捷估算中一些最流行的估算方法。

计划扑克 (Planning poker)

计划扑克是最流行的敏捷估算技术之一。它通过玩游戏来保证所有成员都积极参与。该游戏首先给团队的每个成员发一组扑克牌。每组扑克牌包含一个不同的数字,这些数字在很大程度上遵守斐波纳契数列:0、1、1、2、3、5、8、13、21、34 等。在图 4 中可以看到,这些数字表示故事的相对估算值。0 表示故事太繁琐,难以跟踪;20 表示故事需要分解为更小的故事。使用斐波纳契数列的目的是创造一种不确定性,鼓励讨论,尤其是对于大数字。现在返回到游戏中。团队的每个成员开始估算某个故事,然后每个人揭示包含来自他或她的立场的故事估算值的扑克牌。估算出最高和最低值的成员解释他们的参数。这些解释进而使整个团队反思推理过程,然后分享经验和假设。整个团队反复重新评估故事,直到他们达成一致意见。有关更多信息,请参阅 计划扑克

图 4. 计划扑克牌的示例
使用斐波纳契数列计划扑克牌
使用斐波纳契数列计划扑克牌

T 恤码号 (T-shirt sizing)

在此方法中,分发一组码号卡片。每个码号卡包含一个特定的码号,它们是:超小号 (XS);小号 (S);中号 (M);大号 (L) 和超大号 (XL)。这些卡片水平分布在桌子上。整个团队合作来将每个故事添加到合适的码号类别下。所有用户故事分类完后,对于每个码号,团队放置一个等效的故事点,如表 1 所示。例如:XS 是 1 个故事点,S 是 2 个故事点,M 是 4 个故事点,依此类推。此方法可确保所有故事都对应于故事点。

表 1. T 恤码号与故事点的映射关系
T 恤码号 故事点
XS 1
S 2
M 4
L 6
XL 10

类似地,其他方法鼓励使用更有创意且有趣的大小方法。例如,使用狗的重量,其中吉娃娃是最轻的,大丹狗是最重的。另一种方法使用动物体形,其中老鼠是最小的,大象是最大的。

估算大量故事

如果您需要快速估算大量故事,该怎么办?在这种情况下,使用相对质量估算。该方法生成一种快速方式来分类和估算大量积压的故事。要使用此方法,您需要每个故事都有一张卡。对于桌面上的一组故事卡,调解人挑选一张卡片并问团队,“这个故事被视为大、中还是小?”依赖于团队的答案,将该卡片放在桌面上的特定位置。如果它很大,则放在桌面上的左侧。如果它很小,则放在桌面上的右侧。如果它是中型的,则放在桌面上的中央。转到下一张卡片,问同样的问题并相对于之前的故事卡来放置新故事卡。这个过程持续到所有故事都排列在桌面上。

另一种旨在快速估算大量积压故事的类似方法称为 墙估算。此方法使用一面很大的空墙来排列故事。顶部的故事表示最高优先级,而底部的故事表示较低优先级。也可以在墙上水平排列来确定故事大小。左侧的故事最小,而右侧的故事最大。

敏捷方法与传统方法中的估算结果的比较

大家首先想到的一些问题是,“我应该使用哪种方法?” 和 “哪种方法最好?”这是一个值得商榷的问题,实际上没有正确的答案。本领域有许多研究证明,正确答案依赖于许多因素,比如项目的类型。这些因素如表 2 所示。

表 2. 敏捷方法与传统方法之间的对比矩阵
敏捷方法传统方法
项目大小中小型项目 大型项目
软件生命周期敏捷生命周期。例如,极限编程 (XP) 和 scrum 传统生命周期。例如,瀑布和螺旋式
估算团队大小通常在 5 到 9 之间。 可以小于 5。在主题专家情况中,它可能是一个成员。
团队协作 所有团队成员(比如产品所有者、开发团队、测试团队)积极参与。 不是所有方法都鼓励所有团队成员参与。
历史信息估算方法没有强制要求存在历史信息。 大部分方法都依赖于历史信息。
估算时间可能花更长时间,因为它是以对估算结果达成共识为基础的。 可能比敏捷方法所花时间更短。
点值系统 点值的复杂性。例如,故事点大小。 参数点。例如,功能点分析和用例点。
估算原则相对估算。 绝对估算。

更有效的估算的要素

建立良好的估算结果,对促进项目成功不可或缺。估算是计划的最重要元素之一。估算结果越好,对交付结果的控制就越好,浪费的成本就越少。那么您如何度量估算结果好不好?比较估算值与之际值之间的差异。根据定义,良好的估算值 75% 的时间在实际结果的 25% 以内(Conte、Dunsmore 和 Shen,1986)。
无论您选择采用哪种估算技术,都有一些要素肯定能让结果更好。

  • 对估算技术的认知。您需要熟悉所有估算方法,才能知道哪种方法最适合您的项目。
  • 使用小任务单元。您将任务分解为越小的部分,您越能了解完成任务需要多长时间。通常,任务的估算完成时间应在实际完成时间的 2 天内。
  • 团队合作。让整个团队参与估算,可消除对任务的任何模糊理解。它有助于交换信息和专业技能,进而获得更好的估算结果。它还会改善估算结果和任务的所有权。
  • 询问正确的问题。每个任务都包含模糊性。您需要询问正确的问题,然后尝试找到答案,以消除模糊性。抛开假设,以便对任务边界和风险达成共识。
  • 记录您的实际工作。从以前的估算结果中学习无疑会带来增值。您需要记录实际的估算结果以作为历史参考数据。

结束语

要成为更优秀的估算人员,需要理解和探索不同的估算技术。一定要知道可用的选项,以及哪个选项满足您项目的需求。本文提供了敏捷和传统方法中的丰富的估算技术。文中提供了充分的信息来帮助您理解基础知识和熟悉每种技术。比较敏捷与传统方法的矩阵有助于您决定使用哪种方法。借助一般建议和技术概述,您将会成为更优秀的估算人员。

致谢

感谢 Amr Yassin、Michael Schenk 和 Sally Fikry 审阅本文并提供反馈。很高兴与他们共事。


相关主题

  • 使用 COCOMO II 估算软件成本,Barry Boehm 等(Prentice Hall PTR,2000 年)
  • 传统和敏捷方法中的工作量估算模型分析,Manjula, R. 和 R. Thirumalai Selvi
  • “软件开发项目中的传统和敏捷成本估算成功因素分析”,Mansor、Zulkefli、Saadiah Yahya 和 Noor Habibah Hj Arshad。(International Journal of New Computer Architectures and their Applications (IJNCAA) 1.4 (2011):942-952)
  • 敏捷和传统软件开发方法之间的比较,Awad 和 M. A.,(西澳大学,2005 年)
  • 敏捷估算和规划,Cohn 和 Mike。(Pearson Education,2005 年)

评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=DevOps, Rational
ArticleID=1012621
ArticleTitle=您项目的最佳估算方法是敏捷方法还是传统方法?
publish-date=08052015