#1 楼
好吧，将速度提高40％非常简单-只需在所有估算值中增加40％的点，并做相同数量的工作即可。速度作为目标是错误的，只是鼓励夸大估计。一个不太能回答问题的答案是，您的估计已经假定您在正确地完成所有操作的同时要尽可能快。真正提高生产力40％的唯一方法是加班或不正确地做所有事情。两者都在短期内加快了速度，但从长远来看却减慢了速度。在这种情况下，长期工作时间不是很长，一个月在外面。最佳的长期策略是永远不要超过您的可持续发展步伐。但是总的来说，要改变正在走上正轨的经理的想法绝非易事。您的项目可能会遇到麻烦-这肯定是一个危险信号。
评论
我坚信没有“快速而肮脏的”。即使在短期内，“肮脏”总是让我慢。
–布朗博士
2013年9月16日20:45
@Paul-我认为这很好。但是其中的建议大部分只能由管理人员遵循，而那些可以从中受益的人可能不会读。阅读它也不一定会改变行为。
–psr
13年9月16日在21:41
而且，如果您同意并确实将速度提高40％，那么在其他人看来，您和您的团队并没有尽力而为。专业的处理方法是直接回答：“不，不能。”关于它的另一本书参考：Robert C. Martin的“ The Clean Coder”。
–pablosaraiva
2013年9月17日在22:26
axosoft.com/blog/wp-content/uploads/2012/08/…
– KeithS
2013年9月18日14:15在
“您的估计已经假设您在正确完成所有操作时会尽可能快地前进”这可能是一个错误的假设。我们总是可以继续改进和优化。团队永远不要认为自己的稳定速度表明他们无法取得更好的进步。但是他们需要系统地查看整个过程，并寻求较小的过程改进。
–柯蒂斯·里德（Curtis Reed）
18年2月20日在19:30
#2 楼
正如评论所指出的那样，该请求显然是错误的。但是他想要不断提高生产率并不是真的错误。通常，这就是经理要努力（并对其进行评估）的原因。速度是衡量您当前可持续脚步的量度，但您不应固步自封。 Scrum有一个评估和更改在您的过程中哪些有效和哪些无效的地方：回顾。如果您利用此优势并调整流程，则生产率（可能还有速度）应该会提高。您的Sprint中是否有经常消耗大量精力的东西？可以解决吗？它可能不会给您40％的增长，但是5-10％是一个开始，不是吗？您应该在每个冲刺中寻找瓶颈并加以解决。最终，您可能会接近他为您设定的目标。评论
+1：这是向经理描述的好方法。您不能人为地提高速度，但是可以在每次冲刺之后回头，了解可以做些什么以提高下一个冲刺的效率。
–凯文
2013年9月16日在21:44
奇怪的是，消除经理的管理费用（强迫会议，填写表格等）很可能会给您带来5-10％的负担。但是如何说服他呢？
–AVID
2013年9月17日上午10:17
我认为您的回答代表了对速度的误解。它不是绝对指标，而是在项目生命周期内测得的平均值。速度点本身并不代表已完成的工作，而是复杂性的粗略衡量。它们本身也是平均值，低点任务可能需要比高点任务更多的时间。要求“更多”似乎没有什么意义，这是一个基本的误解。经理基本上是在要求固定的期限。
–里卡多·格拉德威尔
2013年9月17日在11:22
@RicardoGladwell-当我说“请求明显错误”时，我承认这是对故事要点如何工作的错误理解。我只是在暗示经理真正想要的是团队提高生产力，而Scrum确实提供了实现此目标的手段。同样，对于故事点代表什么也有不同的看法-复杂性是最常见的一种。与我合作的大多数团队都使他们在工作量上有所对应。具有大量数量的简单任务不再被认为是简单的。
–马修·弗林（Matthew Flynn）
2013年9月17日上午11:32
您确实提到速度增加“ 5-10％是一个开始”，但这似乎与经理人对我概述的“增加速度”的误解相同。
–里卡多·格拉德威尔
2013年9月17日下午12:55
#3 楼
TL; DR速度对于估计进度表或生成计划值非常有用，并且对于评估过程瓶颈或团队能力的变化也可以是有意义的侦查控制。但是，这不是衡量生产率的有效方法。期。它是对过去性能的统计分析，然后可以用于预测未来工作负载容量或周期时间的概率估计。这与“计划目标”形成鲜明对比，后者是一个为计划目的设定时间表或目标的管理目标。一个团队具有实现管理层定义的调度目标的可持续能力。有时答案是肯定的，每个人都很高兴。有时答案是否定的，这时铁三角迫使有关范围，成本，时间和质量的业务决策。
评估您的政治选择
的平均速度为50个故事点...我被要求将其增加40％，达到70个故事点（团队成员人数没有增加）。
假设您的估计做法是合理的，并且您的速度合理稳定，您的经理不会因不根据历史业绩而调整估计规模或设置管理目标而感到高兴。正如您正确指出的那样，从根本上讲这是一个能力问题。当然，增加人员并不一定总能增加实际的项目能力。有关此常见误解的更多信息，请参见布鲁克斯定律。
您面临的问题是政治上的。从职位的语调来看，听起来您的经理希望看到生产率的提高而又不对团队的基础能力进行任何实际的改变。因此，解决方案也是政治性的，并且本质上是具有教育意义的。积压整理和Sprint回顾通常是解决此特定问题的理想检查和适应机会。
如果您不是Scrum商店，则必须确定解决问题的适当方法您的组织。如果您与经理相处融洽，您甚至可以借给他一份“敏捷评估和规划”副本，供你们两个人在午餐时讨论。梳理您的简历，并尽自己的专业，直到项目破裂。 68％的IT项目失败；除非管理目标牢固地建立在组织能力的基础上，否则您可能会成为其中之一。
评论
质量不是调整变量：这就是为什么我们说铁三角，而不是铁正方形。换句话说，当某人试图降低“质量”时，就会造成延误（交付时间更长），范围（功能无法正常工作，因此无法实现）……以及资源（开发人员感到沮丧而离开）。在这一分钟点之后的好答案。
– kriss
2014年5月5日在12:14
@kriss质量确实可以成为三角形的一部分。有时将其视为“范围”的一部分，或者在某些三角形中，它是实际顶点，表示其是主要约束。有关具体问题，请参见PMBOK星形中的蓝色三角形作为具体示例，或者查看“项目约束模型”的演变。请在PMSE上了解更多信息。
– CodeGnome
2014年5月5日下午14:13
这是我与敏捷专家的讨论。概括地说，我们不同意的是PMBOK是有效的敏捷资源。它起源于瀑布模型，并且与敏捷正交。它主要兼容，但是仍然存在一些问题。将质量视为调整变量是一个。正如我所看到的（而且我并不孤单）使用（尝试使用）质量作为调整变量破坏了整个敏捷过程。但这应该是一个问题。
– kriss
2014年5月6日在9:24
问题发布在这里pm.stackexchange.com/questions/11489/…
– kriss
2014年5月6日上午10:07
#4 楼
我不了解您的经理在Scrum团队中扮演什么角色？他是教练吗？他是产品负责人吗？如果他像教练这样的团队成员（他从事开发任务），您可能会问他为什么他低估了自己的生产力，因为这似乎并没有其他团队成员的情况。如果他认为自己可以每次迭代增加30个故事点，那就让他展示一下。如果是这样，他应该理解做出这样愚蠢的请求，他只是停止了敏捷。
一个基本规则是，产品负责人确定目标，而团队确定可以在迭代中完成的事情。不这样做会导致经典且众所周知的铁圈：资源，速度，特征。选择两个！您不能一次选择三个（记住：质量不是调整变量，试图通过低质量来偷工减料会使情况变得更糟）。
如果他不想改变当前的目标，也许通过为团队招募更多的人员可以使生产率提高40％？也许投资一些团队成员进行一些高级培训？团队也可以通过不断的改进来提高速度，但是肯定不能通过任意决定。
试图改变团队的速度就像改变房间的大小一样。可以做到，但是基本上您需要改变房间。
您不是有一些Scrum Master或其他对Scrum有基本了解的人可以向他解释吗？ />
#5 楼
在这种情况下，经理在从团队中获得了诚实和忠实的估计后就转向了错误的方向。经理应该求助于利益相关者，让他们知道他们的要求不能在要求的时间内完成。然后，经理/分析师应优先考虑必须包括哪些功能，以及哪些功能可以等待（即使只有几个星期）。如果利益相关者不合理，则可能需要更高级别的经理参与，这通常可能具有挑战性，并且需要进行其他一系列讨论。如果我坐在你的怀抱里，我会挺身而出并详细说明了为何该项目需要花费估计的时间。还要尝试找出低回报的项目。找到那些没有多大价值并需要大量编程工作的项目，并为从sprint中删除这些项目提供理由。还提出一种迭代方法，该方法在“ Y”日期交付“ X”并确保可行，然后提出后续迭代，以获取剩余的物料。
基本上，有人需要告诉利益相关者在截止日期之前可以期望得到什么，并且它包括他们的大部分要求。并且在以下版本中，它们将具有剩余的项。如果客户不合理，那么就需要高层管理人员介入，经理应该能够做到这一点。
但是，如果客户超出了承诺，并且直到现在还没有人说出来，那将是一场艰苦的战斗。不幸的是，这并非罕见。
评论
“诚实和忠实的估计”可能是问题所在。
– JeffO
2013年9月17日12:24在
@JeffO-可能是的，这就是为什么我建议提出理由以证明估计值是正确的。
– hanzolo
2013年9月17日15:48在
#6 楼
听起来您面临两个问题。关于测量速度的部分困扰您，可能是测量是成本。您真正想要提高的是价值。不幸的是，众所周知，衡量软件的价值既困难又主观。但是，即使是不完美和主观的指标也可能有用。真正的问题可能不是您的团队需要编写更多的代码，而是故事需要更有价值。
另一个问题是，根据您的帐户，经理期望生产率提高40％。您的问题中没有提到此请求的上下文。如果希望您的团队不断改进，这可能是一个善良的态度。或者，这可能不是一个非常微妙的迹象，表明您的经理认为您的团队表现不佳。
编辑：根据您的评论，情况看起来很糟糕。听起来您的公司正在为解雇您和您的团队（也许也是您的经理）奠定基础。我建议你找另一份工作。
评论
不幸的是，这是一个严重的要求，我的说法是：我认为没有理由不能实现这一目标（但不会告诉您如何！）。因此，这意味着他不相信他们正在努力工作或没有应有的能力。然后，当我休假时情况变得更糟，产品负责人告诉团队，如果他们没有达到目标，将会受到严重影响。因此，我现在也有一个非常关心的团队（我真正相信自己是一支出色的团队）也需要担心。
– P2l
13年9月16日在21:43
+1表示“摆脱道奇”。有时，这是唯一的方法（尽管越少越好）。
–迈克尔
2013年9月16日在22:22
#7 楼
开除他。就是说，翻过他的头，解释说他失去了团队的所有信任，并解释说他对公司没有价值。说明具有这种无能的管理人员比下面的团队更容易更换。 。业务本身并不一定存在任何问题，仅此一个人即可。解决该问题。并且要避免高层管理人员受到任何干扰，请明确指出这不是可以原谅的错误。这表明负责的经理不了解他所管理的团队。这不适合解决问题，在当前的劳动力市场中也不需要这样做。经理人很像体育教练一样可以更换。所有者不解雇团队。
现在，这看起来像是可以适得其反的策略。但是请考虑：如果高层管理人员与您的经理一视同仁，那么您已经处于亏损状态。因此，如果仅考虑尚未处于亏损状态的情况，则结果可能会更加积极。真正的风险是高层管理人员只会解雇包括经理在内的整个团队。只有您可以估计这种风险。显然，您需要输出，否则他们不会要求更多，但价格是多少？
评论
换句话说，将您的手举到空中，哀号，并保持健康。这种态度永远解决不了问题。有更好的方法来处理这种情况。
–MrFox
2013年9月17日18:06
不。哭泣或投掷是戏剧性的动作。这可以忽略。我建议的是最后通atum。这个经理要么走，要么团队走。没有戏剧性，只有冷酷的商业逻辑。他不适合这份工作，这是高层管理人员的职责。但是，如果允许的话，他们的首选方法是忽略这种情况。这就是为什么您需要放弃该选择。
– MSalters
2013年9月17日23:03
@nathanhayfield典型？我认为该团队将由一系列个性和人物组成。懒惰的人应该单独解决，而不是对团队一揽子要求。
–詹姆斯·科里（James Khoury）
2013年9月18日下午3:09
@MSalters很多人在不同的业务层次上都不了解某些事情。正确的方法是减轻冲突并教育每个被侵犯的人。也许这位经理不了解敏捷，但他们可能还有其他赎回素质（可能更重要）。作为专业人士，您应该在每种情况下都发挥最大作用，并与每种类型的人格一起工作-因为这从长远来看实际上是建设性的且有帮助的。按照您的建议进行操作无法扩展。
–MrFox
13 Sep 18 '13：20
@MrFox：直接经理应该了解日程安排；实际上，它们是对此直接负责的层。团队成员应该是主题专家，而高层管理人员离此行动还很远。因此，这位经理在要求时间表的情况下证明，他不理解什么可能是他最重要的任务。如果就业市场紧张，找一个更好的经理可能会很麻烦。但是今天你可以找到更好的人。
– MSalters
2013年9月18日13:33
#8 楼
我的经验是，鉴于团队，问题领域或技术堆栈都没有变化，提高团队的实际速度一直非常非常困难。这是一个问题：清理技术债务；确保一切都在运行正确的版本（不一定是最新版本！），代码合理，并且在系统中没有冗余（重复的代码，未使用的代码等）。尽可能进行配对（是的，我发现这会提高速度），花时间积极地进行重构（同上！），并且对范围和重点毫不留情。 ReSharper for .NET值得在黄金，Airbrake和Splunk进行Ruby开发等方面发挥作用。 。我会优先考虑其他工作。
#9 楼
您的经理要求（或告诉）您的团队加班。虽然消除瓶颈并提高效率可以在某种程度上提高您的速度，但要获得这种提高（40％）的唯一方法是延长工作时间，因为您需要在该时间段内投入更多的工作量。让我们假设一个场景。
进行为期两周的交流，可以说10天。乌托邦一天要工作8个小时，故事要点被抽象为一个工作日。因此，从顶部开始，您的速度将是8。但是，根据人们的看法，人们每天可能会在6个好小时内收到电子邮件，会议，上厕所等信息。因此，现在每个开发人员只有6个小时。因此，您的基准值为6。假设您希望人们加班，现在每天工作10个小时。因此，每位开发人员将获得10个速度点。病了几天也许是因为工作量过高或您的团队投入了额外的时间而造成的。
但是，如果您的年龄稳定在50岁，那么要达到70岁就需要额外的时间。
#10 楼
速度的问题在于它是因变量，是开发过程的测量输出。要求将速度提高40％就像是试图大喊大叫，让汽车更快地开始工作。通过向引擎中供应更多的燃料和空气或使汽车更快，以及找到一条交通较少的路线来提高速度。如果正确地进行测量，那么多工作小时并不会提高速度，例如每个开发工时点数。仅当您每天测量点，然后重新定义中间测量中的“天”时，它才有效。
速度的提高需要改进开发过程中的自变量。更快的计算机和编译器，更高效的构建系统，更好的设计流程，更强大的开发人员，更好的工作空间，超级傻瓜动机。 40％的改进将需要非常重大的改变。
问问您的经理是否考虑将您的团队安排在一个共同工作室的封闭办公室中，购买该团队的全新开发硬件，或雇用几个真正的高级开发人员来指导团队会得到他40％的收益。如果没有足够的资源来改进您的开发过程中的投入，那几乎可以排除对改进的真诚兴趣。这样就可以对经理进行反向工程，以找出真正激励他的因素，而这正是整个“另一线程”的主题。
#11 楼
好吧，我对其他答案认真对待老板的要求感到惊讶。要求将生产率提高40％的人对软件开发一无所知。我仍然很喜欢阅读Phil Phil的以下主题：
进入IT管理有两条基本途径。您可以通过流血，汗水和眼泪来学习
贸易，并根据您从来之不易的技术知识和成功经验中获得的信誉逐步踏上阶梯。
项目。另外，您也可以不穿西装，打领带，学习用语，然后畅谈通向
顶部的方式。
两条路线似乎同样有效。处理后一个品种
肯定会引起片刻的沮丧和怀疑……甚至绝望
……其中一些已在这些故事中得到记录。当一个人在权力职位上遇到技术上的无能时，会感到悲伤和沮丧，并用同样的笔触对所有的经理人进行讨价还价。菲尔建议不要这样做。大多数经理
会努力工作并为公司做出良好的贡献，即使您只遵循一些简单的准则，即使是贫穷的经理也可以达到所需标准的培训。帮助您的经理
以使所有人受益的方式履行职责是您团队的责任之一。 br />也许您会爱上他们，只是因为他们对工作场所的喜剧做出了无意的贡献。
建议不要变得“悲伤而沮丧”是尽你所能。不要在技术问题上与技术上无能的老板打架。他只会将其视为人身攻击。
评论
好吧，我认为这种类型取决于您所订阅的管理模型。教练组长：公认的专家，会弄脏自己的手，教别人如何做得好，但通常还是“上师”。领导主管：“专家”，他知道所有事情（或认为他知道），并且只下达命令并告诉人们要做什么。代表团的领导：可能不是专家，他们不相信自己的专业知识并提供帮助。支持性领导：小组的啦啦队长帮助他们建立，激励人心，说服团队可以做到并帮助他们实现目标。
–柯蒂斯·里德（Curtis Reed）
18年2月20日在19:47
#12 楼
您的经理误解了速度的使用。它不是指标，也不是目标。其目的是校准每个冲刺的团队工作量。如果考虑一下，您的速度就会从最佳猜测中得出，并在每次冲刺后重新测量。通常，随着时间的流逝，它应该变得有些稳定。但这并不能改变以下事实：它是团队实际工作的副产品：为客户创造价值。
之所以将其用作目标和/或指标是错误的，是因为这会使它成为虚荣指标。它在纸上看起来不错，但绝对不能反映您的产品是否满足了客户的需求。那就是最重要的（我希望）。
评论
据我所知，这已经在另一个答案中得到了解释：“该范围表示团队在某个历史时期内的平均能力。它是对过去表现的统计分析，然后可以用来预测未来工作量的概率估计容量或周期时间...”
– gna
2013年9月17日上午11:33
@gnat部分支持，是的，尽管该回答并未说明将速度用作虚荣度量标准，这一点仍然很重要，因为对于许多管理人员而言，它们是基于代理服务器编号来执行愚蠢的事情。 OP表示他认为这是错误的，但无法解释。我认为，“虚荣度指标”一词（来自精益创业公司）提供了很好的解释。
– Stefan Billiet
2013年9月18日在7:57
#13 楼
关于我的经验，直截了当。首先，您可以夸大估计，但这并不意味着您要做更多。膨胀，只专注于团队速度），
尝试找到团队内部的技能。他们在努力做到最好吗？您是否需要系统架构师来做出有关构建应用程序和复杂事物的艰难决定？团队如何投入精力？他们正在花时间研究问题的解决方案，重构，制定业务决策或什么？
他们是否感到自在，专注并被估计？他们接下来会做什么？
这不是“我被逼到极限了……”更像是整个团队的一个问题：“我们在极限吗？”和“我们如何突破极限？” ...
我有领导的高性能团队（用于首次建设和/或迁移）...团队的动力是成功的关键。 ..并计划如何将应用程序的基础变得至关重要。有时，我或一个团队会担任系统架构师的角色，并决定“事情”的去向和去向。
有时候，当我看到我的队友效率下降时，我试图打破并邀请他们出去喝一杯啤酒或他们喜欢的东西。这样可以解决所有冲突，并在第二天再次将它们重新集中起来。投资回报率。
专注于对客户最重要的事情。理论上最有利可图的任务。
如果您的问题与出售开发工作有关，那么您认为出售开发工作的投资回报率是多少，而直接将故事点转换为“价格”。如果您可以证明您的团队的投资回报率很高，那么谁会质疑您？同样，如果每个团队都找到了自己的“舒适程度”，则每个团队都有其限制，如果他们不能完成所有任务，则逐月尝试稍微增加一点（这可能是限制）。
显示任务的历史记录，利润（如果可用），您使用过的故事点，并显示生产率不是团队的努力是团队确定的计算结果，复杂性，也许是完成事情的时间
评论
哇。经理要么不了解速度是多少，要么认为团队懈怠。或两者。在下一次计划会议上，给70分，让团队告诉他将导致失败的风险似乎是一个如此愚蠢的请求，我想请您问他为什么他认为这是可能的-如果您已经付出了100％，他期望您付出140％吗？如果您只将冲刺延长40％怎么办？
速度应该用来衡量完成工作的速度。如果您的速度和故事点完全正确，那就表示您无法在截止日期之前完成整个待办事项。合理的做法是接受现实，要么减少积压的工作，要么对存在的问题进行优先排序，以便完成的工作更为重要。或者您可以将截止日期更改为切合实际的内容。
如果实现这些目标，请他将薪水提高40％，然后再增加估计值，就可以使工资增加40％。
这不是像要求马拉松运动员突然在1h25m而不是2h进行马拉松比赛吗？