在Scrum环境中，速度的大幅增加是否现实？

我的经理最近确实在推动使用速度作为生产率的目标和衡量标准。我们目前正在以50个故事点的平均速度进行工作。我的经理希望我们将其提高40％，达到70个故事点（团队成员不增加）。如果我们没有实现这一增长，他希望我们提供完整的细分说明原因。

以速度衡量团队绩效并将其用作目标的整个想法对我来说似乎是错误的，但是我发现很难解释为什么。有什么帮助吗？为什么这不是衡量和激励生产力的正确方法？

好吧，将速度提高40％非常简单-只需在所有估算值中增加40％以上的点，并完成相同数量的工作即可。

既然如此，那么将速度用作目标是错误的，这显然会鼓励夸大估计，这是显而易见的。

一个不太能回答问题的答案是，您的估计已经假定您在正确完成所有操作的同时会尽可能快。真正将生产率提高40％的唯一方法是加班或不正确地做所有事情。两者都在短期内加快了速度，但从长远来看却减慢了速度。在这种情况下，长期工作时间不是很长，一个月在外面。最佳的长期策略是永远不要超过可持续发展的步伐。

Peopleware雄辩地谈论了试图迫使程序员提高生产率的问题，这是经常被引用的经典著作。但是总的来说，要改变正在走上正轨的经理的想法并非易事。您的项目可能会遇到麻烦-这肯定是一个危险信号。

正如评论所指出的那样，该请求显然是错误的。但是他想要不断提高生产率并不是真的错误。通常，这就是管理者为之努力（并得到评估）的原因。

就是说，经理们一直在寻求提高绩效，而Scrum和Agile就是要适应能力。速度是衡量您当前可持续步伐的量度，但您不应固步自封。Scrum提供了一个评估和更改在您的过程中哪些有效，哪些无效的地方：回顾。如果您利用此优势并调整流程，则生产率（以及速度）可能会提高。

那么，您是否正在（回顾）寻找提高团队效率的方法？您的Sprint中是否有经常消耗大量精力的东西？可以解决吗？它可能不会给您40％的增长，但是5-10％是一个开始，不是吗？您应该在每个冲刺中寻找瓶颈并加以解决。最终，您可能会接近他为您设定的目标。

TL; DR

速度对于估计进度表或生成计划值非常有用，并且对于评估过程瓶颈或团队能力的变化也可能是有意义的侦查控制。但是，这不是衡量生产率的有效方法。

当速度与管理目标混淆时

“速度”是一个范围，表示团队在一定历史时期内的平均能力。它是对过去性能的统计分析，然后可以用于预测未来工作负载容量或周期时间的概率估计。这与“计划目标”形成鲜明对比，后者是一种管理目标，可为计划目的设定时间表或目标。

经验丰富的敏捷项目经理知道正确使用速度是要确定团队是否具有满足管理定义的计划目标的可持续能力。有时候答案是肯定的，每个人都很高兴。有时答案是否定的，这时铁三角迫使有关范围，成本，时间和质量的业务决策。

评估您的政治选择

我们平均有50个故事点的速度...我被要求将其增加40％，达到70个故事点（团队成员没有增加）。

假设您的估算做法是合理的，并且您的速度是相当稳定的，那么您的经理将不会因不根据历史业绩而调整估算规模或设置管理目标而感到高兴。正如您正确指出的那样，这从根本上讲是一个容量问题。

容量限制可能与您团队中的人数有关，也可能是您组织过程的限制。当然，增加人员并不一定总能增加实际的项目能力。有关此常见误解的更多信息，请参见布鲁克斯定律。

您面临的问题是政治上的。从职位的语调来看，听起来您的经理希望看到生产率的提高而又不对团队的基础能力进行任何实际的改变。因此，解决方案也是政治性的，本质上是教育性的。

如果您是Scrum商店，请让您的Scrum Master通过适当的框架渠道解决此问题。积压整理和Sprint回顾通常是解决此特定问题的理想检查和适应机会。

如果您不是Scrum商店，则必须确定组织内部有什么适当的方法来解决您的问题。如果您与经理相处融洽，您甚至可以借给他一份“ 敏捷评估和规划”副本，供你们两个人在午餐时讨论。

如果所有其他方法都失败了，请整理一下简历，并尽最大努力直到该项目破裂，为死亡做准备。68％的IT项目失败；除非管理目标牢固地建立在组织能力的基础上，否则您可能会成为其中之一。

我不了解您的经理在Scrum团队中扮演哪个角色？他是教练吗？他是产品负责人吗？

如果他像教练这样的人（例如从事开发工作）在团队内部，您可能会问他为什么他低估了自己的生产力，因为其他团队成员似乎并非如此。如果他认为自己可以每次迭代多承担30个故事点，那就让他展示一下。

更可能的是：他在团队之外，也许是产品负责人？如果是这样，他应该理解做出这样愚蠢的请求，他只是停止了敏捷。

一个基本规则是，产品负责人确定目标，而团队确定可以迭代完成的目标。不这样做会导致经典且众所周知的铁圈：资源，速度，特征。选择两个！您不能一次选择三个（请记住：质量不是调整变量，试图通过低质量偷工减料会使情况变得更糟）。

如果他不想改变当前的目标，那么通过为团队招募更多的人也许可以使生产率提高40％？也许投资一些团队成员进行一些高级培训？团队也可以通过不断的改进来提高速度，但是当然不能通过任意决定。

试图改变团队的速度就像改变房间的大小一样。可以完成，但是基本上您需要更改房间。

您是否没有Scrum Master或周围对Scrum有基本了解的其他人可以向他解释呢？

在这种情况下，经理在从团队中获得了诚实和忠实的估计后就转向了错​​误的方向。经理应该求助于利益相关者，让他们知道他们的要求无法在要求的时间内完成。然后，经理/分析师应优先考虑必须包括哪些功能，以及哪些功能可以等待（即使只有几个星期）。如果利益相关者不合理，则可能需要高层管理人员参与，这通常可能具有挑战性，并且需要进行其他一系列讨论。

如果我是你的鞋子我会拿出一个详细的案例，为什么项目IS打算只要估计服用。还要尝试找出低回报的项目。找到那些没有多大价值并需要大量编程工作的项目，并为从sprint中删除这些项目提供理由。还提出一种迭代方法，该方法在“ Y”日期交付“ X”并确保可行，然后提出后续迭代，以获取剩余的物料。

基本上，有人需要告诉利益相关者他们在截止日期之前可以期望得到什么，并且它包括了他们的大部分要求。并且在以下版本中，它们将具有剩余的项。如果客户不合理，那么就需要高层管理人员介入，经理应该能够做到这一点。

但是，如果客户超额承诺，并且直到现在还没有人说出来，那将是一场艰苦的战斗。不幸的是，这并非罕见。

听起来您面临两个问题。

关于测量速度的困扰您的部分可能是测量是成本。您真正想要提高的是价值。不幸的是，众所周知，衡量软件的价值既困难又主观。但是，即使是不完美和主观的指标也可能有用。真正的问题可能不是您的团队需要编写更多的代码，而是故事需要更有价值。

另一个问题是，根据您的帐户，您的经理希望生产率提高40％。您的问题中没有提到此请求的上下文。如果希望您的团队有所改善，这可能是一个善良的态度。或者，这可能不是一个很微妙的迹象，表明您的经理认为您的团队表现不佳。

编辑：根据您的评论，情况看起来很糟。听起来您的公司正在为解雇您和您的团队（也许您的经理）奠定基础。我建议你找另一份工作。

开除他。就是说，翻过他的头，解释说他失去了团队的所有信任，并解释说他对公司没有价值。说明具有这种无能的管理者比以下团队更容易被替换。

没有足够的理由忍受这样的经理，但这并不意味着开发人员应该辞职。业务本身并不一定有问题，仅此一个人。解决该问题。

为了避免任何高层管理人员的困扰，请明确说明这不是可以原谅的错误。这预示着，负责的经理有没有球队他管理的理解。这不适合解决问题，在当前的劳动力市场中也不需要这样做。经理人很像体育教练一样可以更换。业主不解雇球队。

现在，这看起来可能会适得其反。但是请考虑：如果高层管理人员与您的经理一视同仁，那么您无论如何都会处于亏损状态。因此，如果仅考虑尚未处于亏损状态的情况，则结果可能会更加积极。真正的风险是高层管理人员只会解雇整个团队，包括经理。只有您可以估计这种风险。显然，您需要输出，否则他们不会要求更多，但价格是多少？

我的经验是，鉴于团队，问题域或技术堆栈都没有变化，提高团队的实际速度非常非常困难。

在我能够实现增长的地方，存在以下问题：

• 清理技术债务；确保所有内容都运行正确的版本（不一定是最新版本！），代码结构合理，系统中没有冗余（重复的代码，未使用的代码等）。

• 改善做法；在可能的情况下配对（是的，我发现它会提高速度），花时间积极地重构（同上！），并且对范围和焦点无情

• 寻找和/或购买最适合工作的工具（例如，用于.NET的ReSharper值得在黄金上占一席之地，对于Ruby开发来说，Airbrake和Splunk值得一看）

我同意这里的其他人的看法，他们说您的经理要求任意提高速度是一个危险信号。我会寻找另一项工作作为高度优先事项。

您的经理要求（或告诉）您的团队加班。尽管消除瓶颈并提高效率可以在某种程度上提高您的速度，但要获得这种提高（40％），唯一的方法是延长工作时间，因为您需要在该时间段内投入更多的工作量。

让我们来看一个场景。

进行为期两周的互动，可以说是10天。乌托邦一天要工作8个小时，故事要点被抽象为一个工作日。因此，从顶部开始，您的速度将是8。但是，根据个人的看法，人们每天可能会在6个好小时内收到电子邮件，会议，洗手间等信息。因此，现在每个开发人员只有6个小时。因此，您的基准值为6。假设您希望人们加班，现在每天工作10个小时。因此，这将是每个显影剂10个速度点。

您的速度总是会波动的，也许是很低的，因为您在迭代过程中不得不处理许多错误，可能是缺少要求，或者有人病了几天。可能是因为工作量过高或您的团队投入了额外的时间而造成的。

但是，如果您的人数稳定在50，要真正达到70，则需要额外的时间。

速度的问题在于，它是因变量，是开发过程的测量输出。要求将速度提高40％就像是试图大喊大叫，使汽车更快地开始工作。通过向引擎中注入更多的燃料和空气或使汽车速度更快，以及找到交通较少的路线来提高速度。

如果正确地进行测量，那么增加工作时间并不会提高速度，例如每个开发者小时的功能点数。仅当您每天测量点，然后重新定义中间测量中的“天”时，它才有效。这仅提供了速度的幻觉。

速度的提高需要改进开发过程中的自变量；更快的计算机和编译器，更高效的构建系统，更好的设计流程，更强大的开发人员，更好的工作区，超级傻瓜动机。40％的改进将需要非常重大的改变。

询问您的经理是否会考虑将您的团队安排在一个共同工作室的封闭办公室中，购买团队的全新开发人员硬件，还是雇用几个真正的高级开发人员来指导团队，是否可以让他获得40％的收入。如果没有可用的资源来改进您的开发过程中的投入，那么这几乎排除了对改进的真诚兴趣。这样就可以对经理进行反向工程，以找出真正激励他的因素，而这正是整个“另一线程”的主题。

好吧，我对其他答案认真对待老板的要求感到惊讶。要求将生产率提高40％的人对软件开发一无所知。

我仍然喜欢阅读Phil Factor的相关主题：

进入IT管理有两条基本途径。您可以通过鲜血，汗水和眼泪来学习您的贸易，并根据从来之不易的技术知识和成功的项目中获得的信誉逐步提高自己的实力。或者，您可以穿上西装并打领带，学习术语，然后轻松地谈论自己的出路。

两条路线似乎同样有效。与后一种动物打交道肯定会引起片刻的沮丧和怀疑，甚至使人绝望……这些故事中也有记载。

但是，当一个人在职权上遇到技术上的无能时，很容易会感到悲伤和沮丧，并用同样的笔刷对所有管理者进行讨价还价。菲尔建议不要这样做。如果您仅遵循一些简单的准则，大多数经理会努力工作并为公司做出良好的贡献，甚至可以培训贫穷的经理达到所需的标准。帮助经理以使所有人受益的方式运作是团队责任的一部分。

最终，如果您不能培训他们，使他们得到晋升或避免他们，也许您可​​以学会爱他们，只是因为他们对工作场所的丰富喜剧做出了意想不到的贡献。

建议不要变得“悲伤和沮丧”，这是最好的选择。不要在技术问题上与技术上无能的老板打架。他只会将其视为人身攻击。

您的经理误解了速度的使用。它不是指标，也不是目标。其目的是校准每个冲刺的团队工作量。
如果考虑一下，您的速度就会从最佳猜测中得出，您可以在每次冲刺后重新测量。通常，随着时间的流逝，它应该变得有些稳定。但这并不能改变以下事实：它是团队实际工作的副产品：为客户创造价值。

将其用作目标和/或度量标准是错误的原因是，这会使它成为虚荣度量标准。它在纸上看起来不错，但绝对不能反映您的产品是否满足了客户的需求。那就是最重要的（我希望）。

关于我的经验，直截了当。

首先，您可以增加估算值，但这并不意味着您要做更多。

第二（前提：不夸张，只关注团队速度），

尝试找到团队内部的技能。他们在努力做到最好吗？您是否需要系统架构师来做出有关构建应用程序和复杂事物的艰难决策？团队如何投入精力？他们花时间研究问题的解决方案，重构，制定业务决策或做什么？

他们是否感到自在，专注和估计？他们接下来要做什么？

这不是“我被逼上极限”……更像是整个团队的问题“我们在极限上吗？” 和“我们如何突破极限？” ...

我有领导的高性能团队（用于首次构建和/或迁移）...团队的动力是成功的关键...并且规划应用程序的基础将是必不可少的。有时，我或团队成员担任系统架构师的角色，并决定“事物”的去向和去向。

有时候，当我看到我的团队正在失去效率时，我会尝试打破并邀请他们出去喝一杯啤酒或他们喜欢的东西。这样可以解决所有冲突，并在第二天再次关注它们。

正在销售...

如果很难解释不能增加速度的原因，请使用ROI。

Scrum专注于对客户最重要的事情。理论上最有利可图的任务。

如果您的问题与出售开发工作有关，那么您认为出售开发工作的投资回报率是多少，而不是直接将故事点转换为“价格”。如果您可以证明您的团队的投资回报率很高，那么谁会质疑您？同样，如果每个团队都找到了自己的“舒适程度”，则每个团队都有其限制，如果他们不能完成所有任务，则逐月尝试略微增加，这是（可能）限制。

显示任务的历史记录，利润（如果有），您使用过的故事点，并表明生产率不是团队的努力是团队确定的一种计算方法，用于评估复杂性以及获得某项东西的时间做完了