成本，价值与投资：该项目将花费多少？ 第2部分

这篇文章是《 成本，价值与投资》的续篇：该项目的成本是多少，第1部分

我们已经确定您需要知道这个项目要花多少钱。 我假设您还有一个小项目。

如果您必须估算一个项目，请阅读从估算未知：日期或预算，第1部分开始的系列。 或者，您可以获取有关Estimation的随笔 。 我正在修复它，因此它读起来就像一本真正的书。 我在那里有更多有关估算的提示。

对于一个程序，每个团队都是为自己的排名待办事项执行此操作的：

• 处理待办事项列表和路线图上的所有项目，并使用您现在使用的任何相对规模估算方法进行估算。 您需要使用相对大小调整，因为您需要估算待办事项上的所有内容。
• 提示：如果待办事项/路线图中的每个项目都在小组工作日或更短的时间内，这很容易。 您走得越远，不确定性就越大，估计就越困难。 这就是为什么这是小费。
• 遍历整个积压工作，并在进行过程中进行估算。 不用担心功能有多大。 保持大特点计数 。 如果此功能大于两个或三个工作日，则确定为一个团队。 如果是这样，请保留这些功能的数量。 功能越大，估计中的不确定性就越大。
• 将您的相对点估算值相加。 加总一些大功能。 现在，您有了一个相对估计值，该估计值基于您之前的速度对您来说意味着一些。 您还具有许多大型功能，这将降低对该估计值的置信度。
• 您是否有50个功能，其中只有五个很大？ 也许您对自己的估计有75％的信心。 另一方面，也许您的所有功能都很大。 我可能对估计只有5-10％的信心。 为什么？ 因为团队尚未完成任何工作，并且您不知道您的工作将花费多长时间。

具有实践社区的技术计划

作为软件程序团队，聚在一起，并对总预算进行评估。 为什么是程序团队？ 因为程序团队是跨职能团队，其职责是完成软件产品 。 不只是软件团队，还包括技术程序团队中的每个人。

注意：团队必须信任Sally，Joe，Henry和Tom才能代表他们参加软件程序团队。 如果团队不这样做，那么没有人会对任何估算充满信心。 估计是总的SWAG。

计划团队的代表知道他们的估计分别意味着什么。 现在，无论它们是什么意思，他们都将它们“添加”在一起。 您知道我们为什么将其称为预测吗？ Sally，Joe，Henry和Tom拥有功能团队，服务团队或组件团队吗？ 在过渡到敏捷时，他们是否需要增加实验时间？ 他们是否需要获得管理层的信任 ？ 或者，他们已经有经验丰富的敏捷功能团队了吗？

团队经验越丰富，敏捷度越高。 团队是功能团队越多，估计就越好。 如果您不熟悉敏捷，或者有功能团队，或者拥有混合计划（敏捷和非敏捷团队），那么您会发现估算值相差甚远。

是时候让软件程序经理说：“我们有一个初始的量级预测。 但是我们还没有进行任何工作来检验这个估计，所以我们不知道我们的估计有多准确。 目前，我们的信心在我们的估计中约为5-10％（或其他水平）。 我们花了大约一天的时间进行估算，因为我们可以花时间进行交付，而不是进行估算。 我们需要做一两个星期的工作，提供一个可行的框架，然后我们才能进一步告诉您我们的预测。 在进行过程中，我们可以更好地预测。 记住，在瀑布的日子里，我们花了一个月的时间估算，但我们错了。 这样，您将在我们工作的同时看到产品。”

您希望尽可能多地使用“预测”一词，因为人们理解预测一词。 他们一直都在听天气预报。 他们知道天气预报。 但是，当他们听到工作量的估计值时，他们认为您是正确的，即使您使用置信度数字，他们也会认为您是正确的。 使用单词预测。

当心这些程序估计陷阱

估算程序时，有很多潜在的陷阱。 以下是一些常见问题：

• 积压的主题很多。 您甚至还没有上过史诗，更不用说故事了。 我看不到如何做出预测。 就像我说的那样：“我可以乘飞机从波士顿到中国。 我可以。 需要花时间。” 我需要更多数据：一年中的哪个时间？ 周中，周末？ 否则，我只能提供一个大概的数字，而不是真实的估计。
• 更糟糕的是，积压的任务很多，所以您不知道故事的价值。 “修复单选按钮”并不能告诉我一个故事的价值。 也许我们可以取消按钮而不是对其进行修复。
• 估计的人不是从事这项工作的人，因此估计中充满估计偏差。 仅仅因为工作看起来容易或辛苦并不意味着就可以。
• 估算成为目标。 这永远行不通，但是经理们一直都这样做。 “当然，我的团队可以在第一季度末完成这项工作。”
• 您的程序上的人是多任务的，因此估算是错误的。 您是否已阅读由于多任务导致的延迟成本 ？
• 经理们认为他们可以根据估算结果预测团队规模。 这是将工作分割成一个问题的错误认识，即更多的人使工作变得更容易。 更多的人使通信负担加重。

估计程序更加困难，因为庞大会使一切变得更困难。 管理计划问题的更好方法是确定在项目组合中是否值得资助。 然后，以敏捷的方式工作。 准备好更改积压订单，团队和团队之间的工作顺序。

作为项目经理，当人们要求估算时，您将扮演两个角色。 您想问您的赞助者以下问题：

• 在我们停止之前，您想投资多少？ 您准备好在我们构建程序时观看该程序的增长了吗？
• 这个项目或计划的价值是什么？

您想向团队和产品负责人提出以下问题：

• 请制作行走骨架（产品中具有功能的骨架）并在其上构建
• 请提供一些小功能，以便我们每天都能看到产品的发展

赞助商看得见的产品越多，他们对整体评估的兴趣就越小。 他们可能会要求提供更具体的估算值（何时可以使用此特定功能），这很容易回答。

交付有效的软件可以建立信任。 信任消除了许多估计需求。 如果您的经理或客户以前从未与项目或计划团队信任过，他们将开始要求估算。 您的工作是每天交付可运行的软件，因此他们不再询问。

翻译自: https://www.javacodegeeks.com/2014/09/cost-value-investment-how-much-will-this-project-cost-part-2.html