困在速度……
好的......所以似乎本周我有点卡在速度上。也许可以使用一个帖子，我可以从我的系统中取出这个并继续前进到其他主题。让我们更多地谈谈什么速度是什么，它不是什么，以及如何最好地使用项目团队。
传统的评估
在发现敏捷之前，我参与的大多数项目都是从一长串需求开始的。项目经理将联系每一个资源经理进行评估。这些估计将在实际的小时内完成，并用于计算项目需要多少人，以及扩展到项目需要多少成本。根据我的经验，企业几乎从不喜欢这个估算，总是亚博vip9通道要求我们做一些事情来降低成本。
作为项目经理，我会回到资源经理那里，开始谈判过程。我参加过的最极端的一次活动持续了近4个月。我们协商了范围，试着做了一些前期设计工作，对项目做了假设，最终将预算降低了50%。有趣的是，我大部分时间都在和每个经理单独谈判，他们中没有一个人真正了解其他经理是如何考虑解决问题的。他们的估计基本上不同步。
我们从事四个月的时间，以及一堆来自关键资源的宝贵时间，砍掉了一个数字（在一天结束时）原来是全面的小说。亚傅体育app现实是，我们不知道项目实际上有多大。此外，我们不知道哪些团队成员实际上是工作的，所以要有可靠的结束日期几乎不可能。我们唯一可以做的是创建一个项目计划，我们可以获得估计，并希望最好。
敏捷估计
敏捷团队确实估算项目，但使用反映该过程中固有的不确定性的机制。你可能听说过故事点和规划扑克的想法。这是最常见的敏捷估计方法之一，但不是唯一的方法。敏捷估计后面的一般想法是您首先识别小，相对理解的要求，并将其分配一个（1）的任意值。您的产品积压中的每个功能都针对良好的理解要求进行评估。我们作为一支球队要求自己，我们认为新的要求是比与我们相比更复杂的2倍，3倍或5倍吗？
第一个要求得到1的点值，下一个要求可能会得到3个点值，而第三个要求可能会获得5的点值;全部基于团队对每个特征的相对复杂性的理解。
在这一点上，我们有了以点为单位的积压的大小，但它并没有真正告诉我们任何事情。由于点数不等同于小时，我们仍然不知道项目将花费多长时间。有些团队会对最初的几个特性进行详细的评估，以大致了解每个待办事项列表项的大小，但是在我们开始构建它们之前，我们真的不知道我们能够在每个迭代中构建多少点。
这是速度进入的地方。
产品所有者优先考虑基于业务价值的特征，团队基于技术复杂性和风险来重量。亚博vip9通道集体，团队设置功能的构建顺序，并获得繁忙的写作软件。每次迭代，团队都将提供一些功能，并跟踪分配给每个项目的点值。所有点值的总和，关联的所有完成功能都是团队的速度。从根本上讲，该团队吞吐量迭代的衡量标准。
因为我们知道积压的整体大小（在故事点中）以及团队可以构建每个迭代的功能数量（在故事点中），我们能够计算项目完成后：
迭代完成=每个迭代的积压大小/点
关键概念在这里，传统估计几乎不会导致可靠的项目成本指标。只有通过在短期内建设工作软件，并测量我们的进度，我们将有必要的信息知道该项目需要多长时间。如果你没有阅读我的上一篇关于渐进估计的最后一篇文章，那么这可能是回去看看的好时机。因为我们不会知道我们可以做多少，直到我们实际开始这样做，我们可能必须插入一些检查点，在那里业务可以重新校准项目或决定拉插头。亚博vip9通道
传统的速度观点是它对正在进行估计的团队是特定的。一个团队可能会给一个特征三（3）个点，而下一个团队可能会估计五（5）的相同功能。只要估计的团队就是这样做的工作，这不是一个问题。请记住，点是相对尺寸相对复杂性的估计。实际价值无关紧要。我唯一关心的是球队对他们积压的整体大小的吞吐量。我唯一需要知道确定我的项目是否正在按计划进展。
速度正常化
也就是说，如果我有很多团队在一起工作，共同完成一个大而复杂的项目，会发生什么呢?如果一个团队称一个特性为3(3)，而下一个团队称一个相似的特性为10(10)，那么在整个计划中交流性能可能会很困难。使用较大的积分值的团队会用较小的积分值掩盖团队的性能。
为了回答这个问题，我见过很多球队将一个指向一个常见的措施单位正常化。例如，我的团队经常将一个人视为一个人的一天。我们仍在使用轻量级估算技术，我们只需使用归一化值作为对话的起点。这种方法可以级别播放领域，并加强在致力于相同主动的各个部分的团队之间的沟通。
虽然这种正常化可以有利于大规模敏捷实现，但有一些风险。
一旦我们开始将一个点等同于一个标准时间单位，我们就开始对速度进行数学计算。讨论通常以询问我们如何提高团队的开发速度开始。嗯……如果团队有4个人，每个迭代可以交付20个点，我们可以增加第5个人，将开发速度提高到25。或者，我们发现相同的4人团队在每个迭代中只交付了17个点。我们想知道那些游手好闲的人用我少了的三个能力点做了什么。
我的个人观点是，在团队中正常化速度是完全可以的。作为管理者，我们需要认识到速度测量的速度......以及它不是测量的。速度是测量吞吐量，避免抽象估计，它不是衡量生产力......当然不是在任务上花费的时间。很常见的是，看到点估计为20的情况，详细估计为25，所花费的实际时间为30，交付的功能为15.该团队可以使用这些数字来获得更加一致的估计，但是我关心经理是吞吐量，以及如何帮助团队随着时间的推移而改善。
即使在我们正常化速度的环境中，也有许多因素可以有助于团队之间的速度变化。团队规模是一个明显的考虑，但技能和经验呢？我们应该考虑团队化学......我们应该询问团队是否依赖于其他组织来完成他们的东西。也许他们遇到了减缓了他们的进步的障碍。这是贡献团队速度的所有东西。
我教练队来测量速度，所以我们可以衡量关于项目如何进步的诚实信息......然后查看其他因素来确定如何更好地使其更好。我们要做的最后一件事就是无意中激励团队操纵数字以使数据看起来不错。
评论（7）
Basim Baassiri.
Mike和我同意你的观点，只要你把一个点和一个时间单位进行比较，你就完蛋了
为了从QA透视估算，我通常会问自己只是提出评级。例如，
故事是否指定了以前从未完成的东西，或者贵公司之前没有完成？
我给了十大问题因素，并将它们全部添加到给我一个值。我可以轻松地使用此值点或使用该值作为测试故事所需的努力的指标
我希望我有意义
Mike Cottmeyer.
完美的意义。谢谢你的评论。
S.Vaidya.
请给我发电子邮件，我想和你谈谈你的文章。
里程麦克邦
你关于速度正常化必要性的论点有点站不住脚。您说，了解分散在多个团队中的复杂项目的进展非常重要。这意味着你是在用故事点来衡量项目的规模?我觉得这就是你错的地方。就项目完整性而言，最小的度量单位是特性。它们要么是完整的(在产品的可发布版本中)，要么是不完整的。为了得到一个准确的进展图，我们应该通过分解和更好地理解功能大小，而不是团队的速度，来引导我们的努力规范化功能大小。
像你所描述的这种可见性问题在拥有更长的发布周期的项目中会更加明显。这将允许更大的(因此不那么容易理解的)特性被安排到一个版本中，而不被分解。所以我建议缩短你的发行周期，作为一种工具，你可以使用它来缓和你试图通过标准化速度来解决的一些问题。
Kirsten.
好帖子，我享受了很多文章谢谢。
我也不确定正常化过程如上所述，我们尝试了类似的东西，它不起作用。一旦你说1'男人的日子，你会问这个问题（隐含地）'你能在一天内完成什么（或7个小时）。一旦点击了估算者，就会努力保持足够尺寸的摘要。
邮政（可能对我有特定的另一个问题），我们与相当多的初创公司工作，并且当在开发开始之前不可能提供有关预算和发布时间的指导时，我们致力于产品开发。我无法说'嘿，这是软件开发，它带来了风险，令人棘手估计，所以我们首先做几次冲刺怎么样？'。我很乐意使用你的方法，但我不会有任何工作。对我们来说更好（我认为这可能会为很多人响应真实）是使用历史数据来提供关于我们类似技术复杂性的给定项目的速度潜力的前瞻性指导。此外，看着我们的历史数据，我们通常更慢地开始缓慢（在吞吐量方面），因为我们在前几次冲刺期间我们被发现得多。它让我们6个冲刺击中了一些一致性，我会厌恶使用前几个Sprint作为数据点。更好的是，您可以使用历史项目上的数据来了解实现一致速度所花费的冲刺，并使用该数据来预测新项目的开始速度。
坚持发布!
Kirsten，
你所做的两点都有效，帖子同意你。关于你的第一点，帖子指出，当你绑定到标准的时间单位时，我们开始尝试在速度上进行数学。这是不可取的。它可能无法明确说明，但帖子不使用单位时间来定义点。它识别出我们这样做时存在风险。
关于第二点，如果您有有效的历史记录，您将使用点估计大小和历史表现来估计成本和持续时间。您应该绝对使用历史记录来确定数据是否可用。如果你没有历史。或者，如果历史没有以某种原因预测（全新技术，对团队的变化等），那么您将项目的规模尺寸为点，请尽量做出最好的成本和持续时间估计，并使用点来跟踪进度。如果您在预期的速度中出错，您可以早起。然后，您可以决定重新校准项目，请拉插头，或者将更多的冲刺旋转以获得一致性。如果第一个迭代不一致，那么使用您的判断如何验证项目的性能。
谢谢回复。
丹尼斯
Kirsten.
谢谢。对于Dennis的回复，我同意你对我评论的回复中所有的观点，后一点正是我们遵循的过程。坚持写!Kirsten.