估计

项目
06/09/2015

由 Mitch Lacey。所有者，Mitch Lacey 和合伙人，Inc，一家专门从事于敏锐和讨论调整和改进。

2012 年 1 月

Mitch Lacey 讨论了有关软件项目估计的困难，并提供了估计项目时使用两个敏捷软件估计技术的提示和技巧。

应用于

应用程序生命周期管理；Team Foundation Server

内容

介绍
为何估计很困难
估计技术
情景点作为度量单位
计划扑克
墙评估
估计
优先级
结束语

创造性和不可预知的估计工作不仅仅是简单的困难。选择方式执行它可以完全相同纳税。正如 Fred Brooks 所说: “对于没有采用定量方法、极少数据支持且主要由经理们的预感来证明的情况下产生的评估，难以进行有力、合理和可能对工作造成风险的辩护。”

我们请求提供我们的软件项目的估计在最前面，并尽早且不管我们的工作量提醒管理这些估计是粗糙的，我们的初始估计通常会变为承诺。

本文内容，我将演示具挑战性估计项目在最前面的原因，敏捷软件如何估计技术帮助，并且，如何使用计划扑克和情景点估计产品的积压工作。

为何估计很困难

在大多数项目中，我们请求估计在前面。若要这有问题的原因，必须检查不确定性圆锥，其中在 1981 年 Barry Boehm 向我们介绍和 Steve McConnell 于 1997年在他的书籍中重新介绍 软件项目生存向导。

不确定性圆锥体

圆锥说明，有大多数不确定性在所有项目（4x 的变体开头到 0.25x 中的范围）。此变体意味着我们评估一年项目可能实际上最终将耗去 3 到 48 个月的时间。所有项目开头是后，我们最不确定有关项目，也是我们请求提供非常精确的估计。

敏捷中，我们尝试从不确定性移到确定性尽可能在短周期内。这可以通过最大化提早了解系统及其设计来实现。为此，通过系统、完整且正在工作的情景创建单个路径。我们使用此来刷新设计和要求更早的假设，允许我们可以移动到确定性更快和更多的保密性。

估计技术

有各种有效的估计技术，包括计数、专家评定（个人和集体）、分解、类比、代理估计、计划扑克和墙估计。我们还可以使用工具如 Cocomo II。所有这些技术需要我们选择一个估计单元 — 小时、天、周、月、理想的工作日，t恤杉大小，点或以上所有。如果我们不了解该单元，则估计值没有意义。就所有这些而论，我们为什么与估计奋斗就不足为怪了。

虽然敏捷团队倾向于一些评估单位和技术风格来估计产品积压工作（情景点和计划扑克），团队应可随意使用适合其需要的任何方法。关于我的经验，表达式按照情景点来估计，使用计划扑克或墙估计，结果为最好的结果。在以下段落中，您将了解情景点作为度量单位和我希望的两个估计技术：计划扑克和墙估计。

情景点作为度量单位

Mike Cohn 很好地总结了情景点：“情景点是一个度量单位，表示用户情景、功能或其他工作的总体大小”。 ”情景点告诉我们情景有多大，相对于其他，根据大小或复杂程度。在帮助团队了解相对大小的概念时，Mike 常常会提到“中指向”。 2 点（小）狗是一只吉娃娃。 13 点（大）狗是一只丹麦大狗。考虑了这两个教程，相对于吉娃娃或丹麦大狗将极为容易地调整其犬种的大小。大概比吉娃娃大两倍的小猎犬可能是 5。大于小猎犬但小于丹麦种大狗的 Labrador，可能是 8。

在您首先了解使用情景点时，您的团队需要建立您自己的固定的比较点。为此，从选择一致同意小的产品挤压工作中（根据大小或复杂度）以及一致同意大的产品挤压工作中选择一个场景。我希望让我的小型情景成为两点式情景，原因是如果我希望情景变得更小（比如我发现了一只玩具吉娃娃），我可以办到。如果我将我最小的已知情景限制为一个点的情景，并且我还需要再小，则我遇到麻烦了。然后其他情景可以相对于这些进行大小调整。

在它出自选择数字来表示这些大小时，我发现斐波纳契序列可以运行更好。 Fibonacci 是先前两个数字的和。因此 1 和 2，下一个是 3。 3 和 2，下一个是 5。 5 和 3，下一个是 8，然后是 4。相对于 T 恤衫式大小调整或几何级数（4/8/16/32/64/128/256等），我更偏好斐波那契数列，因为我们人类习惯于十进制。在我们退出该范围时，即使我们表示 xs、s、m、l，XL—它会变成困惑。斐波那契数列很简单，易于理解，并能够确保足够的准确性，使我们能够进行提供目标的相对估算。您可以选择数字的不同集，但应记住要点是一致的。

情景点是相对值，未修复。在小时和点之间没有直接相关性。例如，我们不可能确定一个两点情景等于 12.2 小时，因为两点范围内的情景的实际完成时间差异非常大。同样，不能将一个团队的情景点与另一个具有任何程度的可能性的情景点进行比较。情景点，创建和特定于评估其团队，可能会由团队只了解的复杂程度，而不是绝对的。

计划扑克

在选择了度量单位并建立了缩放后，下面可以估计了。大多数敏捷团队使用规划扑克来估计情景的相对大小。它是流行的敏捷团队，因为包括多个主观评估技术的目标度量，包括类比坏人专家判断。计划扑克的关键是参与。团队的每个人需要参与，是的，每个人。功能测试人员会评估开发任务，反之亦然。功能项目经理还可以评估开发任务。这样做是为了确保您的意图数量包括尽可能多的主观估计。

从集合开始计划啤牌发牌。计划扑克牌可以使用索引牌轻松制作，通过使用纸牌作弊或购买—Visual Studio 甚至可以制作扑克牌。每张牌在情景点的选择范围（1，2，5，8，13 等）有一个数字。每个参与者处理包含可用的情景点的完整范围的“手”。

计划扑克牌示例

在分配纸牌后，游戏开始。

Scrum 主管将产品积压工作中的顶级项提供给团队。
团队讨论该情景是什么。
产品所有者阐明这些问题、假设和未知因素—和验收条件一样。
每个团队成员专用确定相对于引用情景、一系列引用情景或所有在产品积压工作的情景此情景多大。
在计数三，每个人同时显示所选择的卡片。

如果每个人都调用同一张牌，则团队可以记录估计值并移动到下一情景。

如果有宽变体（例如，显示的数字范围从 1 到 8），则团队花时间讨论该情景。若要集中讨论，需具备解释其评估推断的低投标人和高投标人。此处的对话有价值，而不是该数字，因为这是了解发生的位置，并未找到任何假设。短暂 30 秒到一分钟讨论后，团队重复步骤 4 和 5。此过程将继续，直到团队对该情景评估达成一致。

这看起来相对简单，但是了解一些基本规则十分重要。首先，如果团队没有完全达成某种协议，您不应继续进行。例如，假定团队中有一个人选择八，但其他所有人都选择五。如果会话主持人说，则足够“接近。在这个上我们转到了五个；转至，”有八个的人员？根据我的经验，创建者无论转到什么团队，但完全停止参与。以那种方式计划可能会进行得很快，但是您失去了某些极为重要的东西。此人不仅没有理解此项工作，团队还失去了一个成员的输入和看法。另外，也可以不同意。有价值的理解来自对于为何某人选择了比其他人更高的数字的讨论。如果在状态中找到自己，请参与实施者尝试“拳头到五”技术。它有效的获取沿没有疏远任何参与者移动。

由于计划的啤牌表示该点的估计，该理想情况适用于估计产品积压工作。但是该冲刺积压工作应按小时进行估计。据说，计划扑克可以且已成功用以估计 sprint 积压工作；卡片的数字、即使为小时数，而不是点。因此，简单规则–

产品积压工作估计位于点中。
Sprint 积压工作是在估计小时数。

您可以在任何项目的开始使用计划啤牌，并贯穿其生命周期作为它自己的新信息显示、优先级更改和清晰性图面。

墙评估

计划扑克是估计用户情景的一个很棒的工具，但是使用计划扑克一次估计数百上千的情景需要花费大量时间。如果具有原始积压工作填充不估计或优先顺序的数百个情景，则您将需要更快的方法来估计。

墙评估旨在允许团队可以移除讨论 2 与 3 和 5 与 8 并且至少最初代替组操作依赖于相对方法与状态集。它还允许利益干系人可以提供泛型设置优先级情景的大型组，而不会获得挂断一个情景是否比另一个略有更重要。

若要执行墙估计，必须在卡片上打印您的用户情景。然后使用较大空墙收集您的团队和利益干系人（大约 14 英尺长 8-10 英尺高）；了解有关该墙的两点：

高度确定优先级。在顶层的情景更高；在底部情景保持较低的。情景的优先级可以基于 ROI、业务价值或一些像“只是很重要，我不知道为什么”一样简单的东西。
为大小保留宽带。在左侧的情景较小；在右侧的情景是更大。 (可以撤消此并从右向左滚动，如果在日本，并且其更合理。)要点是想象一条线专为水平，一条线转为垂直。团队成员和利益干系人应调用自身，因此，相对于其他情景，在何处此一个将？

团队将使用墙调整所有的情景。利益干系人将使用墙按优先级排列情景。与计划啤牌，我们使用相对大小，但是，而不是使用两个引用比较的情景，墙将成为常数。小的情景？向左移动。大情景? 向右移动。重要情景？放在高位。现在我们生活中可以没有的故事？放在低位。

虽然当情景进行估计时利益干系人不必在序列图中，当确定情景优先级时团队需要在空间中。 Scrum 主管和产品所有者必须同时参加估计和优先级活动。

现在，如果您已具备估计的积压工作，则您可以进行本练习中的优先级排序选择。如果您的产品所有者和利益干系人已经给予您优先级积压工作，则您可以估计此练习的部分。 (在估计完成之后，您的产品所有者可能需要重新访问该优先设置。毕竟，成本对优先级有很大影响。)让我们来详细地探讨一下其工作方式，首先从团队中的角色开始。

估计

为团队提供初级产品积压工作，并从评估开始。指示团队墙的最左侧应包含最小的可能情景，并且最右边应包含最大的可能情景，而不考虑数字。团队基于两个角色将情景置于某处。用于执行的优点此方法没有什么中预想的概念两个点或三个非常情景是；根据墙多大正确是相对的是，实际上是用墙原因迟早有用。

如果团队执行此操作有困难，则可以通过提供其他引用范围从 1 的情景到 8 提供更多结构墙。不要考虑创建更大引用情景；更大的任何通常将分解，因为它在优先级引发。在团队确定五个情景后，请将它们放在与其大小相关的位置的墙上（再从左至右移动）。为大于八点的情景在墙的右侧留些空间。将这些情景放在墙上，并指示团队将剩余的情景放在相对于这些引用情景的墙上，切记较小的情景在左边，较大的情景在右边。

在墙上的情景，有团队标识介于逻辑和情景大小之间。磁带在声明这些中断的情景的组之间的垂直线条。很快将具有类似于显示的墙此处墙。在第一个组中的所有内容为 2；在第二组中的所有内容为 3；在第三组中的所有内容为 5；最后一个组中的所有内容为 8。当该面多有的情景现在评估相互之间的情景时，该数字同样不重要。

墙壁估计示例 - 相对排序

既然您已估计您的情境，那么您需要让您的利益干系人加入，以便您可以为情景分配优先级。

优先级

虽然您的客户和利益干系人需要知道多大的情景帮助它们确定其优先级，它们将更侧重于查找与它们相关的情景，并确保实现这些情景。期望您的利益干系人不同意优先级，您的产品所有者将使用此信息帮助确定最终优先级。

向利益干系人解释墙。告诉他们墙上的所有卡片均反应他们想在成品中查看的功能。解释团队已估计每个情景，并且基于它是在墙上的那列他们可以确定情景的点估计。提醒大家团队成员不是按优先级的有效参与者。它们在其中观测值，获取有关行为的注释和特定情景在优先级中引发和低于的原因。如果需要它们还可以回答利益干系人的所有问题。如果团队无法自信地了解一个或多个情景的大小，因为它需要某个特定利益干系人的答案，则团队还可以询问关于那些情景的问题，如果时间允许的话。

需要利益干系人可通过在录制的列里向上或向下移动这些情景帮助确定所有这些情景的相对优先级。提醒他们情景处于墙上的位置越高，其对业务的优先级就越高。设置以下规则：