目录
介绍
这篇文章可以帮助雇主更好地了解团队成员的个人和职能部门的工作方式。当产品或项目工作开始时，您将跟踪一段时间内完成了多少故事点。您可以使用它来改进未来的计划。要实现此目标，您可以做很多事情，但是要做多少取决于您在工作中所处的位置，要花费多少时间进行估算本身以及需要进行多少比较。
最近，我和一位高级质量检查负责人打了有趣的电话。他向我伸出援手。他想更好地了解他的员工作为一个职能部门和个人的表现。首先，我怀疑他想变得积极主动，并建立了某种数字预警系统，他可以将其与其他地方的常识和定性输入进行交叉引用。
正如我们所说的，他最初一直使用“速度”一词。但是，很明显，他的意思是速度比典型的迭代Scrum /敏捷意义更宽松。对于他想要实现的目标而言，这并没有真正起作用。
这就是我的意思：
核心指标以迭代方式实现基准进度
到底什么是速度？
速度本身首先是团队的输出指标，而不是个人的指标。它是在经过的时间单位内完成的故事点的度量。
它提供了有关产品开发团队是否有效运作的可见性——作为生成新功能的系统。在这种情况下，新功能是期望客户最看重的，因此我们仅进行跟踪。这不是一种提高效率的措施，不应对此感到困惑。传统上，这种方法来自软件开发环境，但是可以应用在需要大量复杂性和思想的地方。知识工作。
这些故事要点是生成相对于目标或目标日期的估算值的主要“原始材料”。一旦您有以下感觉：
- 您为谁而构建，为什么
- 您要构建的内容，即定义的实际故事
- 您已经用故事点估计了故事
当产品或项目工作开始时，您将跟踪一段时间内完成了多少故事点。您可以使用它来改进未来的计划。通常，它以预定时间长度的“冲刺”工作，作为计划和跟踪进度的一种方式。例如，以流行的敏捷风格称为Scrum，这些通常会持续1-4周。
实际速度
让我们以2周为例。新组建的团队已开始研究新产品或项目。为绝对的“必须具备”功能定义并估算了项目的积压。
在这一点上，如果您要完全透明，那么您将不知道团队实际将走多快。您还可以协商“必须具备”的确切内容，以帮助减少所需的时间（更少的工作，更快的完成）。理想情况下，您还将所有人都同意所有人都可以接受的质量标准，这也将对进度产生影响（较高的标尺平均每个功能花费更多时间）。因此，您最初实现的速度/冲刺为0，并且您对预期速度将有一个猜测。
您（与团队）同意在第一次冲刺中完成哪些故事。2周后，您与团队坐下，将实际发生的情况与希望发生的情况进行比较。在早期阶段，这是一项新的尝试，总体上可能会有很多学习成果。但除其他外，您可以将团队完成的故事点加起来。这是您第一个意识到的速度。
预期速度
经过3次冲刺后，您应该开始看到某种趋势出现，即平均速度。有时候值得给团队带来疑问的好处，因为一旦他们将集体的头脑集中在需要做什么上，他们可能会加快步伐。
通常，此数字将与您希望达到的日期的预期速度明显不同。如果您计算“必须拥有”初始版本所需的总故事点，然后将其除以到目前为止的已实现速度。为了简化思考过程，假设它将保持不变。
这使您了解达到该最终日期需要多少工作冲刺。通常，正在发生的事情与预期的事情之间会有差距。最好尽早知道这一点。实际上，这种透明性是敏捷的优势之一。如果您看到交付的内容，那么很难掩盖现实。此外，您还会看到实现了最初估计的认知努力的故事点。
警告：这种类型的分析可能会引起一些健康的疑虑和讨论。这是有意的。使用此绩效数据，您可以在此阶段重新确定优先级，更改资源级别，更改范围或您认为可能对团队有所帮助的其他任何内容。
为了达到业务目标，期望速度是您希望保持的理想速度。通常，在更传统的环境中，这将以目标发布日期来表示。但是，也可以采用其他形式，具体取决于对整个企业而言实际重要的内容。
实际速度和预期速度之间的核心区别在于它们的时间方向。前者测量最近的速度趋势。后者更多地是业务需求，被翻译成数字。期望速度是“与目标日期有关系”的实用方法。这是一项将长期期望转换为定期检查的预警系统的指标。与您实现的速度相比，您会知道您的团队是否进展太慢而无法约会。
周期
周期时间来自精益背景。它是衡量构建一个输出单元需要多长时间的度量。实际上，它是从生产过程的开始到结束所经过的时间的度量。
=时间（流程结束）-时间（流程开始）
它不仅包括团队花费的实际时间，还包括流程各步骤之间的所有等待时间。
与故事点不同，度量单位是时间。这可能是周期时间的最大优势。时间可以进行算术运算，如均值和标准差之类的统计数据，甚至可以在各种汇总中（例如，质量检查小组成员之间）进行比较。它也不太主观，因为不需要预先估算。它只是连续测量。它使您了解正在发生的事情。以及您的过程有多健康。
现在不利的一面。周期时间隐含地假设：
- 输出单位相当标准、统一，因此大小相似
- 汇总后，工作类型之间没有区别。例如，构建新功能和修复已经构建的功能中的错误所花费的时间不会花费相同的时间。
- 没有目标。它只衡量效率而不是有效果
在两种情况下，周期时间作为衡量指标在软件中的效果很好：
- 例如，如果不估算故事，但全部分解为每个故事的最大预期长度为2天。
- 在进行维护开发时，需要进行常规过程监控，以便可以调查极端情况，但是时间压力往往是问题所在且因人而异，而不是整个团队
节拍时间
节拍时间的运作与周期时间类似。但是，它没有量化已发生的事情，而是用于量化期望，以便可以对其进行持续监控。
简而言之，节拍时间 衡量的是完成生产过程以满足客户需求所需的最低预期速度。计算公式为：
=净生产时间/客户所需的总产量
如果想看一眼，这里有一些数字示例 。
无论如何，节拍时间有很多真正有用的属性。它用数字表示期望值，指的是每个项目应花费多少时间才能达到目标产出。例如，如果节拍时间为10分钟，则应每10分钟推出另一个单元。如果速度更快，那就太好了！如果不是，则需要进行故障排除并改善生产过程、资源或环境。
“客户所需的总产出”可以仅以单位（例如，故事数）进行度量。这样，您不需要估计，并且估计不会引入主观偏见。
像预期的速度一样，它为团队提供了一些帮助以长期目标（具有商业意义）为基础的业务关系。在此刻。
这难道不是有点抽象和自我参照吗？
是的。它是的。
敏捷框架中进度的主要衡量标准是“工作软件”。或更概括地说，已完成的工作。它被演示给所有人查看和评论，并且应该以一种通用的方式进行，以便任何人都可以参与（即，不仅是拥有计算机科学博士学位的人）。任何人都应该能够看到这些新功能。
就是说，并非一切都是软件。并非所有软件都具有用户界面。因此，应用此功能会有点困难，尤其是在新产品的早期。
在这种情况下，您可以使用这些指标来监视有效性和效率。您可以对自己和团队负责。您有一个与利益相关者进行讨论的数字框架，可以在任何给定的时刻检查该框架，在这种情况下，您不需要每次有人想要更新时就“与团队一起检查”。和上面的高级质量检查经理一样，您可以将其用作主动的预警系统。如果许多努力中的一项正在走下坡路，而您却监督了其中许多工作，那么您自然会想要某种方式来知道某些事情即将发生。
这就是菜单。选择哪一个？
这取决于您的工作位置，要花费多少时间进行估算本身以及需要进行多少比较。
您在哪里努力
在项目的早期，您有很多未知数。他们往往是相互依存的。例如，为了给出日期估算，您需要就所要构建的内容以及其构建方式达成共识。这可能取决于您要实现的市场细分或主要业务目标，也可能需要协商。如果您对其中任何一项进行调整，其余所有内容也会受到影响。
在这一点上，如果您将技术估算与故事点相结合，以完成细粒度的任务，则整个事情将面临更多不确定性。延迟故事点估计可能会更好。只需使用循环时间，直到您获得更清晰的画面即可。这样，您可以最大化团队的时间来完成实际工作，而不是在高度不确定性以及业务和技术复杂性的情况下进行估计。
一旦您拥有一支稳定的团队、远见和大致稳定的范围，就可能需要对较大的史诗进行一些估算和优先级排序。在此之后，进行细分（进入故事）并评估最高优先级的史诗或两部史诗。如果您的初始范围很大，那么您将花费大量时间来估算您尚未真正理解的内容（这是在初始版本中进行仔细而精确的选择的另一个原因 ）。
您想花费多少时间进行估算和监控
这是关于完成工作与监视工作所花费的时间比例的更普遍的问题。估计是一种工具，可以帮助您监视和衡量工作。理想情况下，最好进行一些估算，以便您可以从战术上安排工作。特别是，在考虑所产生的业务价值并将其与完成价值所需的工作量进行比较时，它是最有用的。
但是估计一年的工作量，尤其是如果在整个过程中都没有向客户发布产品的话，那就太疯狂了。理想情况下，您的发布应该严格，并从单个客户以及整个市场获得反馈。
您需要做多少比较
就像在打开此博客文章的示例中一样，如果您想衡量和比较个人或团队的效率，那么循环时间很容易比较。这是因为在所有情况下“分母”都是相同的：经过的时间：
- 您可以比较各个团队成员的周期时间，如果他们在做类似的工作（例如质量检查），例如QA。
- 此外，您还可以计算平均值以在团队之间进行比较，例如，不同团队之间的质量检查。
- 周期时间的标准偏差也有助于找出真正异常的情况，以便您进行诊断和故障排除（如果不好）或重复（如果很好）
下一步
希望这可以给您足够的入门知识。下一步是选择与您最相关的内容，并弄清楚如何从公司内部系统收集原始数据。理想情况下，这是自动完成并使用软件在后台完成的，因此您的团队无需手动输入数据，尤其是花费的时间。
重要要点
- 速度是基于团队的输出指标，可跟踪随着时间推移完成的故事点。
- 估算可以提高责任感和优先级，但是要花费时间并且容易产生偏差。
- 保持面向客户的发布较小，因为这将提高您的准确性并估计差异。
