功能点估算案例_支持和反对估算的案例，第3部分

功能点估算案例

在第1部分中 ，我讨论了数量级估计和目标。 在第2部分中 ，我说过如何滥用估计值。 在这一部分中，我将讨论估算何时有用。 这里有几种可能性：

• 我们要解决的问题有多大？
• 这个问题的风险在哪里？
• 我们可以采取一些措施来管理风险并进一步说明我们需要做什么？

当评估有助于人们理解问题的严重性时，评估会很有用。

我以前的实践产品负责人中的一位学生说：“我们使用故事的大小来确定何时向故事中涌动或暴动。” 人们处理的故事最多为5个。（他们使用斐波那契数列来确定故事的大小。）他们可能会配对或蜂拥而至8个开始的故事。即使他们有21个（或更大）的故事，他们也会对其进行蜂拥而至。几天，而不是分开讲故事。

他们使用估计来了解功能的大小和复杂性。 （我将其功能称为“功能集”，但他们喜欢将一件大事称为功能。）

您可能不喜欢这种方法。 我认为这是不与PO争执来拆分故事的好方法。 一起解决问题也很有帮助。 一起工作将知识传播到整个团队中，成为一个团队。

我的估计经验是，我很容易不理解工作的规模。 我们通过一起评估，一起工作或以某种方式与时间限制一起来灵活/精简地解决此问题。

我们第一次解决特定问题时，需要花费更长的时间。 第一次使用控制系统（嵌入式软件）时，我必须学习如何协同工作。 软件在哪里与硬件交互？ 这种产品的一般风险是什么？ 第一次我自己出版一本书，一切都花了更长的时间。 我需要按什么顺序完成哪些步骤？

我以开发人员的身份从事许多控制系统的工作。 一旦了解了一般风险，我的估计就会更好。 在我应用基于交付的计划的规则之前，它们还不够准确。 我需要交付哪些可交付成果？ （即使我每周至少交付一次，即使这是我现在知道的数据是峰值）。创建该交付项我需要多少英寸鹅卵石 ？

我将工作分解为可交付成果的次数越多，估计就越好。 块越小，我的估计就越好。 我越是分解问题，就越了解我要做的事情和所面临的风险。

我喜欢敏捷和精益的一件事是坚持小块价值。 我的块越小，我的估计就越准确。

估算值可以帮助人们了解风险。

您会注意到我在上一节中谈到了很多风险。 存在一般的项目风险，例如推动项目发展的因素是什么？ （请参阅“ 管理它！”或“ 预测不可预测” ，或者我几年前写的系列文章《 估计未知》 。）当我们知道推动项目发展的因素时，我们会优化不同的工作。 那就是项目视图。

我们在许多可交付成果中都有潜在的风险。 我们有一般的风险：人们生病，他们需要说话，他们有多重任务。 但是，每个可交付成果都有其自身的风险。

在软件学习，创新之前，我已经说过。 您之前可能已经做过类似该项目的工作，所以您具有领域专业知识。 但是，您可能尚未在此处完成此新操作。

当我估计时，我开始思考我需要做什么，如何解决这个问题。 然后，我开始思考在解决这些问题时可能遇到的问题。

除非我有英寸鹅卵石，否则我无法解决问题。 我是个大人物。 我看到了整个问题，甚至可能看到了整个解决方案，并且跳过了脑海中的某些步骤。 我估计自上而下是一个开始。 除非创建英寸鹅卵石，否则我可能会掩盖一些风险，因为我从上而下开始。

你可能不像我。 您可能会估计自下而上。 您可能会看到所有详细信息。 考虑问题时，您可能不会错过任何解决问题的步骤。 （我想知道像您这样的人：您一开始看到的是大图景，还是为您发展？）

我遇见了一些由内而外估计的人。 他们告诉我他们看到了大局的一部分和小步的一部分。 他们在两个部分上进行迭代，直到看到并可以估计整个过程为止。

我教过许多估算研讨会。 我的大多数参与者都是自上而下的人。 他们看到了想要的结果，然后设想了达到目标的步骤。 我遇到了一些自下而上的人。 我遇到了两个由内而外的人。 我不知道这是正常分布，还是仅是参加我的研讨会的人员。

估算值可以帮助人们了解可能的第一步。

当人们想到可以提供价值的第一件东西，并且考虑如何缩小第一件东西（寸鹅卵石或敏捷故事）时，他们可以更轻松地看到第一个可交付成果。 他们可以讨论可交付的进度（与产品负责人保持敏捷，并与项目经理或产品经理讨论更传统的生命周期）。

我发现对可交付进度的讨论非常有帮助。 许多年前，我是量规检查系统（装配线上的机器视觉）的首席开发人员。 我问客户他想先看什么。 “您能看到足够的量规，以便给我们一些关于它是否是一个好的量规的答案吗？” 是他的答案。

请注意，他说的是“足够”，而不是“完美的检查”。 我们在几天内做了概念验证。 在实验室中，在正确的照明条件下，我们有一种效果很好的算法。 您可能会认为这是一个发现项目。 基于该交付成果，我们获得了该项目其余部分的合同。 如果我没记错的话，我们花了近6个月的时间才交付了最终系统。

对于那个项目，我担任项目经理和现在称为产品所有者的角色。 我们有该项目的发布标准，所以我知道我们的去向。 在展示了我们每两周完成的演示之后，我每两周与客户一起定义可交付成果。 （这是分阶段交付，而不是敏捷。我们每星期进行一次为期一周的时间盒演示，并向客户进行演示。）

这是在我们拥有项目计划软件之前的日子。 我为客户绘制了PERT图，显示了日期范围和预期的可交付成果。

几年前，我曾担任项目经理。 她是甘特王后。 她可以使甘特图做任何事情。 我对她敬畏。

但是，她的项目总是迟到了很多个月。 她将与团队合作。 他们会认为这是一个为期六个月的项目。 她会将任务分别进行了两周，三周和四周的时间，交给了甘特。 那是我了解估算单位的问题的时候。 “如果以周为单位进行测量，那么您将有数周的时间。” 和我一样，她的人民都是自上而下的思想家。 他们掩盖了使产品正常工作所需的一些步骤。

我解释了如何使用黄色便笺纸进行基于交付的计划。 人们可以制定任务并查看他们的交叉点和必须交付的内容。 她和团队意识到他们没有一个为期六个月的项目。 他们有一个至少一年的项目，那就是要求没有变化。

当他们开始考虑估算位时，而不是总估算并应用了忽悠系数，他们意识到必须花更多的时间进行估算，并且估算是有用的。 对于他们来说，估计时间就是探索时间。 （是的，我曾建议他们做些尖刺 。他们不喜欢这个主意。每个项目都有自己的文化。）

您的估算如何为您提供帮助？

也许您的估计会以我未提及的某些特定方式为您提供帮助。 如果是这样，那太好了。

我在使用估算值时遇到的问题是，很难正确估计它们。 看到Pawel Brodzinski的帖子， 估算？ 很复杂……在

在预测不可预测中 ，我有一张图表，说明了我的估计如何工作。 请参阅《幂律分布：估计示例》。 （在那本书中，对于如何获得合理的估算以及如果您的估算有误，该怎么办，我也有很多建议。）

在与客户的评估中，随着时间的流逝，我不再购买估算的锥体。 我不能使其适用于敏捷或增量方法。 根据我的经验，我的估计值偏离了数百％，或者我非常接近。 当客户看到第一个可交付成果时，我们发现我付出了多少。 （在Bossavit的软件工程妖精中 ，（或在leanpub上，他说估算的锥度永远是不正确的。）

对我来说，可交付成果是理解估算的关键。 如果通过估算，您了解更多可交付成果，那么估算时间可能会有用。

由于我使用敏捷和精益的方法，因此对我而言，估计时间不一定有用。 获得排名积压的订单，了解我是否对项目有约束并进行交付，这一点更为重要。 当我交付时，我们发现：需求的变化，我们已经做了足够的事情。 我的交付内容包含反馈。 得到的反馈越多，我越能帮助客户了解实际需要什么和不需要什么。 （我经常在需求发生变化的项目中工作。也许您没有。）

我意识到我需要第4部分，专门讨论估计值以及如何决定是否要使用估计值。 足够这篇文章。

翻译自: https://www.javacodegeeks.com/2016/06/case-estimates-part-3.html

功能点估算案例