敏捷 价值衡量
我的一些客户在转向敏捷方法时一直在其项目治理方面苦苦挣扎。 过去，他们根据要求要求提供估计和成本，然后跟踪这些估计和成本的差异。
治理人员不记录假设。 他们只记录估计值和实际值。 他们希望通过遵守日期和成本的估算来“衡量”项目的成功，而不是根据项目何时创造哪种价值来“衡量”项目的成功。
项目和程序中的人员花费大量时间来创建这些估计。 然后，假设发生变化，需求发生变化，市场发生变化，信息几乎没有价值。 人们花在生成这些信息上的时间是浪费。 原始计划不再有用。 计划很有用，因为计划活动可以帮助人们发现风险。 参见我关于“ 平衡创新，承诺和反馈循环：总结”的系列文章。
但是，治理人员会根据其原始估算（日期和成本）与实际情况的匹配程度来判断项目和计划。
这种测量与敏捷原则是对立的。 更糟糕的是，估算工作量是看不见的。 我们可以用敏捷的方法看到它，因为我们花在前期估计上的时间越多，我们交付第一批价值增量所花费的时间就越长。 我们的估算值可能更准确，但真正的问题是：这有关系吗？
投资，成本，价值具有不同的含义
在计划投资时，我还会考虑“回报”的前景。 这就是为什么我认为延迟成本对思考如何安排哪种工作有帮助的原因。 我想首先交付最有价值的作品。
敏捷方法使我们能够做到这一点。 它们使我们能够在完成工作后将其资本化 ，因此我们可以识别收入并更改我们管理内部资金的方式。
当我考虑成本时，我会考虑现在或不久之后使用的资金。 我可能根本不希望看到货币回报。 当我买书时，我打算享受它或从中学习一些东西。 我不希望这本书像购买软件产品一样成为投资。 我希望学习如何使用该产品，然后在某些方面会更有效。
软件产品不同于其他类型的产品。 软件（和其他高科技产品）使我们在多个维度上都更有能力-它们使我们能够完成原本无法完成的工作。 那生产力的事。
软件产品至少通过以下方式提供价值：
作为生产者，我可以销售产品（或者，在采用敏捷方法的情况下，可以销售功能或可以发布的最小的东西）。 作为用户，我提高了生产率。
这意味着，如果您可以（足够快地发布产品并足够快地确认收入），则产品成本不一定是相关的。 这意味着小故事，并且尽可能接近连续交付。 这意味着交付速度越快，您就可以更快地认识到价值并减少投资。
您在交付连续体上的哪里？
首先，看一下释放频率图像的可能性。 如果您生产的是纯软件产品，则位于最左边。
现在，看看您在交付的连续体中的位置。
可交付成果越小，发布速度就越快，您计划更多块的计划就越频繁，并且可以更轻松地利用这些工作。
如果您的交付物较大，则会发现您花了更多时间进行规划。 而且，您将不得不计划更大的事情。
这很重要，因为您花费在规划上的时间越多，其他人（包括管理人员）就越会“将”您“保留”在您的估计之内。 他们将这些估计数转化为承诺。
停止这种治理的方法是将功能集分解为小故事，并至少每天一次将它们交付。 越多越好。
衡量交付价值和延迟成本
请记住，进度的主要衡量标准是工作软件（请参阅《敏捷宣言》的原理）。 无法进行中。 没有计划的工作。 没有估算和成本。 工作软件。
您能以多快的速度进入工作软件？ （我的意思是完全工作，而不是cru琐或未完成的工作。）那是循环时间。
这项工作有多有价值？ 您能从这项工作中确认收入吗？
您如何评价下一组工作？ 我建议延迟成本，而不是任何形式的估算。
如果要评估您的项目的人每天都在使用工作软件，那么治理还不够吗？
使用加强敏捷方法的措施
我意识到，许多处于转型之中的组织在将“敏捷治理”与更多“传统治理”整合在一起时遇到了麻烦。 我建议每个人都采取“敏捷治理”措施。 这些措施将加强更小，更频繁的交付成果。
项目或计划的重点不是达到估计。 关键是为客户提供价值。 为什么不使用能为客户带来更快价值的措施？
翻译自: //02/cost-value-measurements-agile-approaches.html
敏捷 价值衡量
