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


89

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

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


19
哇。经理要么不了解速度是多少,要么认为团队懈怠。或两者。在下一次计划会议上,给70分,让团队告诉他这将引起的故障风险
史蒂文·洛

25
似乎是一个如此愚蠢的请求,我想请您问他为什么他认为这是可能的-如果您已经付出了100%,他期望您付出140%吗?如果您只将冲刺延长40%怎么办?
乔纳森·里奇

20
速度应该用来衡量完成工作的速度。如果您的速度和故事点完全正确,那就表示您无法在截止日期之前完成整个待办事项。合理的做法是接受现实,要么减少积压的工作,要么对存在的问题进行优先排序,这样您要做的就是更重要的事情。或者,您可以将截止日期更改为现实的时间。
迈克尔·肖

45
如果实现这些目标,请他将薪水提高40%,然后再增加估计值,就可以得到40%的增长。
mattnz

18
这不是像要求马拉松运动员突然在1h25m而不是2h进行马拉松一样吗?
Scroog13年

Answers:


158

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

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

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

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


28
我坚信没有“快速而肮脏的”。即使在短期内,“肮脏”总是让我慢。
布朗

1
@Paul-我认为这很好。但是其中的建议大部分只能由管理人员来遵循,而那些可以从中受益的人可能不会阅读。阅读它也不一定会改变行为。
PSR

2
而且,如果您同意并确实将速度提高40%,那么在其他人看来,您和您的团队并没有尽力而为。专业的处理方式是直接回答:“不,不能。” 关于它的另一本书参考:Robert C. Martin的“ The Clean Coder”。
pablosaraiva 2013年


1
“您的估计已经假设您在正确完成所有操作的同时会尽可能快地前进”。这可能是一个错误的假设。我们始终可以不断改进和优化。团队永远不要认为自己的稳定速度表明他们无法取得更好的进步。但是他们需要系统地查看整个过程,并寻求较小的过程改进。
柯蒂斯·里德

53

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

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

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


7
+1:这是向经理描述的好方法。您不能人为地提高速度,但是可以在每次冲刺后回头,了解可以做些什么以提高下一个冲刺的效率。
凯文(Kevin)

3
奇怪的是,消除经理的管理费用(强制会议,填写表格等)可能会轻松地给您带来5-10%的费用。但是如何说服他呢?
AviD 2013年

2
我认为您的回答代表了对速度的误解。它不是绝对度量标准,而是在项目生命周期内测得的平均值。速度点本身并不代表已完成的工作,而是复杂性的粗略衡量。它们本身也是平均值,低点任务可能需要比高点任务更多的时间。要求“更多”似乎有点没有意义,这是一个基本的误解。经理基本上是在要求固定的期限。
里卡多·格拉德威尔

3
@RicardoGladwell-当我说“请求显然是错误的”时,我承认这是对故事要点如何工作的错误理解。我只是在暗示经理真正想要的是团队提高生产力,而Scrum确实提供了实现此目标的手段。同样,对于故事要点的代表也有不同的看法-复杂性是最常见的一种。与我合作的大多数团队都使他们在工作量上有所对应。具有大量数量的简单任务不再被认为是简单的。
马修·弗林

1
您确实提到过,将速度提高“ 5-10%是一个开始”,但这似乎与经理对我概述的“提高速度”的误解相同。
里卡多·格拉德威尔

26

TL; DR

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

当速度与管理目标混淆时

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

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

评估您的政治选择

我们平均有50个故事点的速度...我被要求将其增加40%,达到70个故事点(团队成员没有增加)。

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

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

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

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

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

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


质量不是调整变量:这就是为什么我们说铁三角,而不是铁正方形。换句话说,当某人试图降低“质量”时,就会造成延误(交付时间更长),范围(功能无法正常工作,因此无法实现)……以及资源(开发人员感到沮丧而离开)。在这一分钟点之后的好答案。
克里斯(Kriss)

1
@kriss质量确实可以成为三角形的一部分。有时将其视为“范围”的一部分,或者在某些三角形中,它是实际顶点,表示其是主要约束。请参阅PMBOK星形中的蓝色三角形作为具体示例,或者有关此问题的一些详细信息,请参见项目约束模型的演变。请在PMSE上了解更多信息。
CodeGnome

这是我与敏捷专家的讨论。概括地说,我们不同意的是PMBOK是有效的敏捷资源。它起源于瀑布模型,并且与敏捷正交。它主要兼容,但是仍然存在一些问题。将质量视为调整变量是一个。正如我所看到的(而且我并不孤单)使用(尝试使用)质量作为调整变量破坏了整个敏捷过程。但这应该是一个问题。
克里斯,2014年


21

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

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

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

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

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

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

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


15

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

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

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

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


1
“诚实和忠实的估计”可能是问题所在。
JeffO

@JeffO -莫非,这就是为什么我建议做的情况下,以证明估计..当他们尝试这样做,他们就会要么意识到他们夸大他们的估计,或者他们真的不具备的能力
hanzolo

9

听起来您面临两个问题。

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

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

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


3
不幸的是,这是一个严肃的要求,我的说法是:我认为没有理由无法实现这一目标(但不会告诉您如何!)。因此,这意味着他不相信他们正在努力工作或没有应有的能力。然后,当我休假时情况变得更糟,产品负责人告诉团队,如果他们没有达到目标,将会受到严重影响。因此,我现在也有一个非常关心的团队(我真正相信自己是一支出色的团队),也可以为此担心。
2013年

4
+1表示“摆脱道奇”。有时,这是唯一的方法(尽管越少越好)。
迈克尔

9

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

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

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

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


5
换句话说,将您的双手举到空中,哀号,并保持健康。这种态度永远解决不了问题。有更好的方法来处理这种情况。
MrFox 2013年

不。哭泣或投掷是戏剧性的动作。这可以忽略。我提议的是最后通atum。这个经理要么走,要么团队走。没有戏剧性,只有冷酷的商业逻辑。他不适合这份工作,这是高层管理人员的职责。但是,如果允许的话,他们的首选方法是忽略这种情况。这就是为什么您需要放弃该选择。
MSalters

@nathanhayfield典型?我认为该团队将由一系列个性和人物组成。懒惰的人应该单独解决,而不是对团队一揽子要求。
James Khoury

1
@MSalters很多人在不同的业务层次上都不了解某些事情。正确的方法是减轻冲突并教育每个被侵犯的人。也许这位经理不了解敏捷,但他们可能还有其他赎回能力(可能更重要)。作为专业人士,您应该在每种情况下发挥最大作用,并与每种类型的人格一起工作-因为这从长远来看实际上是建设性的且有帮助的。按照您的建议进行操作无法扩展。
MrFox 2013年

3
@MrFox:直接经理应该了解日程安排;实际上,它们是对此直接负责的层。团队成员应该是主题专家,而高层管理人员离此行动还很远。所以这个经理,在他的位置作出有关安排的权利要求,证明他不明白什么也许是他最重要的任务。如果就业市场紧张,找一个更好的经理可能会很麻烦。但是今天你可以找到更好的人。
MSalters 2013年

6

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

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

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

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

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

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


3

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

让我们来看一个场景。

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

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

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


2

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

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

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

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


1

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

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

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

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

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

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

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


好吧,我认为这种类型取决于您所订阅的管理模型。教练组长:公认的专家,会弄脏自己的手,教别人如何做得好,但通常还是“上师”。领导主管:“专家”,他知道一切(或认为他知道),并且只下达命令并告诉人们要做什么。代表团的领导:可能不是专家,不能相信他们的专业知识并提供帮助。支持性领导:小组的啦啦队长帮助他们建立,激励人心,说服团队可以做到并帮助他们实现目标。
柯蒂斯·里德

0

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

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


据我所知,这已经在另一个答案中得到了解释:“该范围表示团队在某个历史时期内的平均能力。它是对过去表现的统计分析,然后可以用来预测未来工作量的概率估计容量或周期时间...”
gnat 2013年

@gnat的一部分是的,尽管这个答案没有说明使用速度作为虚荣度指标,这仍然很重要,因为对于许多管理人员而言,它们是根据代理号码来完成愚蠢的事情。OP表示他认为这是错误的,但无法解释。我觉得“虚荣度量”一词(来自精益创业公司)提供了很好的解释。
Stefan Billiet

-1

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

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

第二(前提:不夸张,只关注团队速度),

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

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

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

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

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

正在销售...

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

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

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

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

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.