团队不断未能达到冲刺目标

#1 楼

您首先应该问“谁在乎”？

完成冲刺的感觉很好，并且在某些公司中会导致Scrum父级产生cookie。但是最终的考验是公司是否达到了目标。

以上是有趣的。如果公司在从未完成冲刺计划的内容的情况下成功了，那么您最好使用看板：对积压进行排序，处理最重要的事情，而不必担心已定义的迭代。

定义的迭代的价值之一是推动流程改进（或以某些心态赶走表现不佳的公司）。你现在不明白这一点。因此，您可以采用改进流程（并最终完成冲刺）的其余流程，也可以决定自己喜欢自己拥有的东西。

#2 楼

我错过了什么吗？


是的！

您去了18个月-或进行回顾回顾，冲刺了36个冲刺，但以某种方式无法无法解决？管理层没有要求团队负责，然后他们的管理层也没有要求团队不负责任？

您错过了您的公司普遍无能的情况。

所以，如何解决它。您（开发人员）不再致力于太多工作。如果故事太大而您无法做到，那么您需要将故事分解成较小的块。然后，您要让人们对完成工作负责，他们所说的将要完成的事情。如果事实证明，他们只能在每个sprint中完成一个微小的功能，然后找出原因并使其变得更好（这可能需要更换开发人员）。如果事实证明他们无法弄清楚如何进行合理的工作量，则可以将其解雇。

但是在此之前，我将研究让事情持续那么长时间的管理层，并弄清楚找出为什么他们不做自己的工作。

#3 楼

我想建议您进行一些更改，并尝试使用看板而不是Scrum几个星期。



Scrum通过限制冲刺中可用的工作时间来提高生产率，而看板通过限制
来提高生产率和速度。活动的并发问题数。时间估计不再是该过程的一部分。简而言之，看板是什么？

看板还是用于提高效率的组织工作的工具。像Scrum一样，看板鼓励将工作分解为可管理的部分，并使用看板板（与Scrum板非常相似）在工作流程中可视化该工作。 Scrum限制了完成特定数量的工作（通过冲刺）的时间，而看板限制了在任何一种情况下的允许的工作量（只能进行那么多的任务，而可以完成的任务就这么多） -do列表。）

SCRUM和看板如何相同？

Scrum和看板都允许分解大型复杂任务并有效完成。两者都对持续改进，工作和流程的优化具有很高的价值。两者都非常关注高度可见的工作流程，使所有团队成员都可以随时了解WIP以及即将发生的事情。

从此链接中查看其余细节

#4 楼

我的问题基本上是：寻找开发人员素质的问题什么时候公平？


您的帖子中没有足够的信息来回答该问题。没有办法知道他们是由于能力不足而失败，还是因为他们致力于完成超出合理范围的工作而失败。

如果我是一个非常有天赋的开发人员，那么在一个有天赋的团队中开发人员，并且我们无法在两个Sprint中完成X故事（或36个！），我们没有能力吗？或者，我们只是在估计中吸吮？这取决于故事是“创建登录屏幕”还是“安全地送男人去火星”。

问题始于错误的故事和/或错误的估计

估计很难。真的很难。人类对此很吃惊，这就是为什么Scrum让我们将工作分解成不超过一两天的区块，并组装这些区块的小小组，我们确定我们可以在短时间内完成。块越大，时间间隔越长，我们的估计就越不准确。

您的商店是什么样的？他们写得好，接受标准好吗？他们每个人都足够小，可以在短短几天内完成吗？如果没有写得很好的故事（这是整个开发团队（包括产品所有者）的错），就不能期望团队进行正确的评估。

回顾性差的问题使问题更加复杂

，看来您做错了，是您没有在利用回顾。您已经走了18个月而没有解决此问题，所以团队可能没有注意到该问题，或者没有在回顾会议中解决该问题。

每个回顾会议是否至少要有一个行动项供团队使用，以便在下一个冲刺阶段做得更好。每个回顾活动是否都包括讨论上一个冲刺中的操作项，以查看它们是否已完成以及是否有效？

解决方案不是责怪，而是学习

第一步应该是停止寻找责备，而应该着手改善团队。您的团队可能并不无能，只是在评估和计划上很差。强迫团队完成冲刺，即使那意味着他们选择一个故事并提前一周完成。如果他们不能做到这一点，那么要么他们无能，要么故事太复杂。这个问题的答案应该很明显。

一旦他们能够完成一个故事，他们就会确定地知道他们可以在冲刺中完成X个故事点。简单的数学将帮助回答他们是否可以编写更多故事。

持续改进是解决方案

一旦他们在冲刺中完成一个故事，那就是时候了看看他们能不能做两个。泡沫，冲洗，重复。当他们开始未能达到冲刺目标时，您已经发现了其估算能力的极限。返回上一个故事的故事点数，并坚持一会儿。

始终都认真对待回顾。如果他们没有完成冲刺，请找出原因并采取行动。他们有太多未知数吗？他们的技能组合是否错误？他们的估计有多好？如果他们估计一个故事是X点，那么它是否需要与价值X点的先验故事相对等量的工作？如果不是，请使用它来调整故事的重点。

#5 楼

您说您“使用回顾”。但是，在这些回顾中，团队实际上做了什么？由于您已经走了18个月，却没有一次解决流程的这一方面，所以我猜答案是：没有什么非常有用的。

对我来说，回顾是该过程中最重要的部分。抛弃或更改您想要的所有其他有关Scrum的东西（当然，在回顾过程中要经过团队的共同同意），但是要承诺定期花时间讨论该过程对每个人的工作方式，分享有效的方法和不成功的方法不起作用，并提出改善意见。不断尝试改进每个Sprint的过程，迟早会有一些效果很好的方法。

对于您来说，该过程似乎不起作用。由于未达到冲刺目标，因此谨慎地回顾为什么会这样。显然，团队为冲刺赛做了很多工作。但是为什么他们要这么做呢？


他们是否低估了工作的复杂性？
管理层是否给他们施加了压力，使他们承担的工作量超出了团队认为无法处理的事情？
他们是否有太多的中断/紧急情况使资源无法完成计划的工作？
他们是否经历过瓶颈阻碍了工作的完成（例如，等待外部设计团队的资产）？
甚至：一个或多个团队成员根本无法完成工作吗？

这些在过去的18个月中，团队在每次冲刺时都应该问自己一些问题。然后，有了答案，他们可以提出建议的流程改进，以进行下一次冲刺的试用。这些可能包括：


在下一个冲刺中减少工作量（duh！）
保守估计
告诉压力谁在敦促我们做更多工作的人摆脱困境，因为我们已经承担了超过目前所能完成的工作
更好地管理干扰并在下一个冲刺中调整工作量以适应不可避免的紧急情况
解决瓶颈或针对无法避免的问题进行计划
不要为无法完成任务的团队成员分配故事（并分别找出管理层的回应，以解决绩效欠佳的团队成员的情况，从培训和指导到解雇）。

这种对话应该在每个冲刺中发生在过去的18个月中。这不是要给团队施加压力或增加更多资源，而是要利用回顾来不断改进流程。

您可能会认为，在第15次冲刺中错过目标的情况下，团队会在回顾中讨论很多次，以至于他们决定只做一次仅为了达到一个完整的目标就可能实现的最低限度的sprint目标。到第25个未完成的sprint为止，我只需要更改一个字符串即可完成一个sprint。如果团队无法在sprint中解决问题，那么问题甚至比您所忍受的还要糟糕。

明确地说，正如这里的一些人指出的那样，sprint的目标是预测，而不是铁定的承诺，缺少目标本身并不表示做出错误的预测。一个优秀的团队可能会错过很多目标，因为他们是糟糕的预测者，而糟糕的团队可能会实现每个目标，却无法产生任何实际价值。但是，如果您连续18个月在同一方向上的预测有误，则该过程的这一部分将无法正常工作。使用回顾来确定流程，使您的预测合理地接近团队可以提供每个冲刺的实际情况。

#6 楼

“软件完成后立即完成。”


这是正确的，但是对于开发人员开始从事的每个任务，您的每个人都会做组织了解每个任务的完成定义吗？

似乎最大的问题之一是评估，但是开发人员只有在其具有明确且明确指定的“完成的定义”时才能提供现实的评估。 '。 （其中包括公司流程问题，例如用户文档，正式版本中的工作包等。）

多数人都认为估算时间会导致估算过高会引起问题也就不足为奇了。完成任务所需的条件是最难的。

但是，大多数开发人员倾向于在给定的时间段内合理地（尽管很乐观）处理他们可以投入的工作量。

问题经常是开发人员在处理不完整的信息时，尤其是在他们被迫提出所有答案的压力下，难以在任务和所需的总工作量之间建立关系提前完成一项非常艰巨的任务。

这自然导致时间估计与现实脱节，并且他们忽略了构建过程和用户​​文档之类的内容。

脱节往往从一开始就开始描述任务的时间；而且通常由非技术人员来编写需求列表，而又不知道需要多少工作量。

有时高级管理人员会指定任务，而完全忽略公司流程问题。对于高级管理人员来说，定义测试，创建正式发布的版本或更新用户文档之类的事情只是神奇而无需时间和精力就可以了。必需。

有时项目会在开发人员甚至没有写一行代码之前就失败了，因为某个地方某人不能正确地完成他们的工作。

如果开发团队没有参与达成一致的要求或捕获接受标准，那么这就是管理失败-因为这意味着对代码和技术问题了解不足的人将业务委托给一套不完整的要求，并且使项目容易产生误解，范围蔓延，镀金等。

如果开发团队参与了捕获并达成一致的要求，那么这可能是团队的失败，他们负责澄清细节（以及接受标准），即“交付物是什么样的？什么时候完成的？”）。开发团队还负责在遇到其他阻塞问题或需求不现实时说“不”。

因此，如果开发人员参与了需求的捕获：


团队是否有机会与产品经理坐下来澄清要求/完成的定义？
团队是否提出足够的问题以澄清隐含/假定的要求？这些问题多久能令人满意地得到回答？
团队在提供估算值之前是否要求接受标准（完成的定义）？
通常为每个任务捕获接受标准的程度如何？它是一个含糊不清，细节稀疏的文档，还是描述了有形的功能，并用措辞表明开发人员可以明确地将其转换为测试？

机会是团队的生产力不是问题；您的团队可能正在竭尽全力进行开发。您真正的问题可能是以下一项或多项：


需求不完整且含糊不清。需求/任务首先太大。
开发团队与高层管理人员之间的沟通不良。
在将任务交给团队之前缺乏明确定义的验收标准。
验收测试的规范不完整或含糊/含糊不清。 （即完成的定义）
分配给定义/同意接受标准的时间不足。
开发人员没有考虑测试现有基准代码或修复现有错误的时间
开发人员没有测试现有基准代码但是在提供需求估算之前，并未将这些错误称为“阻塞问题”。
管理层看到了这些问题/错误，并决定在编写新代码之前不需要修复这些错误。
即使在会议，分心，电子邮件等方面可能占用了20％（或类似的时间）的时间，开发人员也面临着占其时间100％的压力。
估计同意以面值计，没有人调整错误或意外事件的余地（例如“我们决定这需要5天，因此我们期望它在8天内完成”）。
每个人（开发人员和管理人员）都将估计值视为单个数字，而不是现实的“范围”数字-即


最佳案例估计
现实估计
最坏情况的估计值




...列表可能比这更长。

您需要进行一些“事实调查”，并弄清楚为什么这些估算始终与现实脱节。现有的基准软件是否不好？它缺少单元测试范围吗？您的开发人员是否避免与管理层沟通？管理层是否避免与开发人员进行交流？在“完成的定义”方面，管理层的期望与开发人员的期望之间是否存在脱节？

#7 楼

我建议重新启动团队的建议是，每个团队，每个冲刺选择尽可能小的故事，并完成一个故事，并且仅完成一个故事！

我同意其他海报，无论哪个团队没有能力，或者他们正在尝试做太多事情。

从最小的东西，最精简的故事开始，并完成一个冲刺。让团队完成冲刺并取得成功，这将帮助他们了解如何确定时间和工作承诺的优先级。随着时间的流逝，团队将能够从事越来越多的工作，直到达到最高生产力。

#8 楼

您应该根据过去的表现来收集数据并建立信心水平。

http://www.leadagile.com/2013/07/agile-health-metrics-for-predictability/

最简单的示例是持续不断的冲刺，例如每两周一次。估计团队将在两周内完成多少故事点。然后，在两周的冲刺结束之后，查看实际上完成了多少故事点。随着时间的推移，您可能会看到估计15点，但只能完成10点。在这种简单情况下，您可以开始进行速度调整，因此每个冲刺仅计划10点。或者您计划完成66％的估计工作。

通过建立具有标准偏差的置信度，您可以告诉管理层：根据当前的项目目标，我们预计只有5％的信心可以在3天内完成周，但我们有95％的信心会在5周内完成。

#9 楼

敏捷和Scrum背后的想法是建立一个紧密的反馈循环，以便您可以评估过程。您必须要问“那是在哪里分解的？”，因为它似乎已经完全分解了。


计划您要做什么并列出清单


这应该包括从积压的项目中选择需要完成的项目。在将任何内容放入冲刺的待办事项列表之前，团队需要同意他们完全理解它，并大致估计完成冲刺所需的时间少于冲刺。
理想情况下，积压订单由优先级（对企业而言），您可以按优先级顺序排列。
如果积压中的项目太大，请将其分解成较小的块。然后将这些块分解成可以在一天或更短时间内完成的单个任务。
不要指望这种计划会容易或快速。


在定义的时间内执行列表中的项目（冲刺）
查看一下您完成了


完成了哪些故事？
如果没有完成任何故事，那么构成故事的任务完成了吗？
如果没有完成任何任务，那么完成什么上周一每个人都在做什么？上个星期二？等等-在这一点上，是时候进行自我反省了。



对问题进行故障排除（分析反馈并进行调整）


完成的事情要花多长时间？
是什么导致任务无法完成？
团队成员是否将故事（功能）分解为可以在1天之内完成的任务？减？如果不是，请执行此操作并将其纳入待办事项列表。
在冲刺期间对任务列表或任务列表中的项目进行了哪些更改？这是未完成的原因吗？如果是这样，请勿更改列表或功能。将更改的功能扔到待办事项列表上，直到稳定为止。
如何将某些项目的大小和范围缩小为可以在sprint中完成的项目？选择一些小东西，例如日志记录改进，简单的错误修复，错别字，以完成一些工作，以便团队评估他们可以做什么。如果您无法执行此操作，请停止冲刺并重新计划。


返回第一步，直到发布...

是否存在文档障碍，耦合问题，依赖关系，沟通问题，需求中没有足够的信息？...什么？开发人员是否花时间尝试学习新技术？他们是否在设计上花费了大量时间？在冲刺任务列表中是否包含学习之类的东西？团队是否已采取措施纠正问题。团队是否没有做出回应，而管理层只是简单地决定了解决方案和行动方针？

鉴于时间跨度长，系统地出现了问题，而不仅仅是开发人员。在某个时间点（一年过去之前），团队中的某个人（包括Scrum管理员）应该问，我们能完成多少（无论多么小）？

#10 楼

在您的情况下，回顾为时已晚。
您是否举行每日站立会议并真正从人们那里获得他们在过去24小时内所做的工作的状态？
Scrum主管是否使用这些会议来衡量每个会议？开发人员的进度是否违反了他们的目标？
您需要使用Scrum方法中的一部分来监控进度。它应该使您对人们的行为有很好的了解。
他们分心了吗？花太多时间在咖啡上，或在SE / SO上帮助其他人，或阅读新闻，或进行无法解释的检查？还是他们真是低头，全力以赴，过度投入？每日视图应该给您一个好主意。这也将有助于使开发人员专注于手头的任务，因此他们不必承认自己昨天没有做任何事情。
当然，如果他们在整个sprint中报告了稳定的进展并且仍然不按时交付最后，他们在撒谎，也许是时候了一个新的开发人员。

#11 楼

估计完成复杂任务（例如编程代码）所需的工作量和时间很困难。正如Joel Spolsky所说：


软件开发人员真的不喜欢制定时间表。通常情况下，他们试图逃脱。 “要做完就做！”他们说，他们希望这样勇敢，有趣的人会减少老板的笑声，而在随之而来的欢乐中，时间表会被遗忘。为了操作。正如乔尔（Joel）所建议的那样，尝试使用基于证据的计划，它将产生具有相关概率的时间估计，该估计可能与任何类型的风险相关。

#12 楼

Scrum做一些事情。

首先，它鼓励确定优先级。工作的提供者必须首先说出他们想做的事情，而不是说“所有事情都同等重要”。其次，即使不是所有的事情都完成了，它也会产生可用的产品。这就是在每次迭代结束时都具有“潜在可运输产品”的意义。第三，它提供了更紧密的反馈循环。通过坚持在冲刺结束时“完成”事情，可以避免“ 90％的功能已经完成，但仅完成了一半”的问题；在争取截止日期时，您可以将需要做的事情放在一边，这样看来您快要达到截止日期了，或者您可以伪造它。通过定义完成并坚持要做的事情，您会知道某事是否比以前看起来难，而不是后来看起来。 。对事物进行远距离规划是一种库存形式：在无法出售给客户或客户无法立即使用的资源上花费的资本。这样的库存可能会腐烂（计划在脚下更改，新信息使其过时），与需求不符（结果是我们不需要分布式网络，因为使用它的东西是不值得的），并降低了装运商品的价值（如果在过去的一年中，您有一半的时间花在了明年及以后的计划上，那么如果您为现在准备的东西工作，则本可以得到两倍的发货量）。如果您可以使计划更接近执行而不会造成损失（麻烦！），则可以减少库存。

这不是解决这些问题的唯一方法。您似乎在使用scrum，它为开发人员在每个时间段内提供工作流，并定期添加要执行的新工作并检查进度。

这是使用Scrum式模式的有用方法。它使工作保持顺畅，使计划与生产保持紧密联系，提供一些反馈循环，等等。它甚至具有的优势在于，它不会扭曲开发和测试以匹配系统（如果最好在工作完成的前提下进行最好的测试） ，试图在相同的sprint中完成工作并进行测试将迫使sprint的后端不涉及新的开发！）

无法将他们将要执行的操作完全放入sprint中没有证据表明您的开发人员做得不好。这意味着他们并没有从头开始遵循SCRUM，而是使用框架的某些部分。

如果他们将对每个sprint的投入减半（或四分之一），但其他所有内容保持不变，那么他们将完成比每次冲刺更多的努力！您将产生相同数量的代码。显然，“冲刺失败”不是重要的部分，因为那只是内部流程的细节。公司的目标是把狗屎做好，把狗屎做好。除非您的目标是某种ISO流程认证，否则不要遵循某些特定的流程。

该流程的存在取决于所完成工作的目标。

另一方面一方面，因为他们没有遵循SCRUM规则，所以您不会获得相同的反馈。您应该检查结果，以查看所产生的缺陷类型是否是SCRUM设计要处理的缺陷；有没有像僵尸一样永远存在的故事，直到深夜被杀死？是否有看起来似乎容易的故事，它们爆炸了，并且回顾起来不值得进行全部工作？产品在您需要/想要运输的时候确实可以运输吗？

#13 楼

如果您尚未定义“完成”的模样，那么“完成后立即完成软件”是失败的秘诀。

大多数工程师将尝试提供最佳解决方案，但是这很容易导致镀金，尤其是对于经验不足的工程师而言。管理的唯一职责是准确定义目标位置并保持工程师朝该方向前进。工程师将经常尝试进行侧弯以改进功能，并且由管理层决定侧弯是否会长期加快速度，或者是否只是在进行改进以提高性能。

敏捷开发的重点是，每一项新工作都应与满足该冲刺要求的性能一样好，并且没有更好的选择！是的，这是我可以在StackOverflow中添加的最大重点-仍然不够重点。如果您发现人们在此刻添加了不需要的东西，那么他们需要接受有关如何正确进行敏捷开发的培训。

#14 楼

哦，是的，我们确实使用回顾。


哦，很好，所以您知道您的团队为什么会失败吗？您已经有36次机会讨论什么有效和哪些无效，因此Scrum管理员应该完全了解如何解决问题，对吧？

我很直觉，根据您的描述，您的公司已经陷入“ SCRUM使我们富有生产力”的念头。事实是，SCRUM无法提高您的生产力。而是，它是一种工具，可以帮助您提高自身的生产率，从而识别出经常被管理层和开发人员所忽视的发展现实。

Scrum管理员将什么识别为团队的潜在问题？他们是否不断分配两倍的工作量？如果是这样，Scrum主管应该轻柔地建议他们减少工作量，因为Scrum主管可以查看团队的工作速度。


在什么时候可以找到问题所在开发人员的质量吗？



应该立即确定开发人员质量的问题所在。这不是SCRUM创建的新问题。这是企业的现实。与传统方法相比，SCRUM应该为您提供有关团队成员能力的更多信息。您应该知道问题是“软件开发人员不够好”还是“管理期望不切实际”，其程度要比传统方法更好。现在是时候让管理层做最擅长的事情了：找出合适的人选，以便公司赚钱。如果您不知道问题出在哪里，那么请想象一下，如果没有所有这些回顾，要说出来将是多么困难！

如果您认为员工可能足够好（这意味着聘用并不是管理层的错误），那么我的建议是开始在框外思考。如果工作尚未完成，请考虑为开发人员更改工作的形状。我发现达到冲刺完成截止日期的最简单方法之一就是调整“完成”标准，以便无论结果如何完成，您都会对结果感到满意。这样完成就成为一种重言式。

这使管理，尤其是SCRUM管理员承担了责任。诀窍是编写任务，这些任务如果完成，将非常有价值，但如果不完整，它们仍然可以为公司提供足够的附加值，值得他们付出薪水。 18个月后，我希望您的回顾会教给您一些知识。如果还没有，那么您应该以失败的故事的明确意图写这些故事，以发掘您公司中的错误并予以揭露。考虑到公司对开发团队的挫败感，这将为公司提供大量有价值的数据。正如您所问，问题确实可能是开发人员。或问题可能是您至今尚不了解的公司思维方式的病态！

如果确实是公司而不是开发人员而不是开发人员，那么您从这些不完整的信息中收集的信息故事的确可能比您从成功的故事中收集的产品更有价值！可能是拯救您整个公司的信息！这对我来说似乎是非常有价值的信息，您可以使用SCRUM作为帮助您收集信息的工具。

#15 楼

“什么时候看开发人员的素质公平？”

一直都是。显然，有些人比其他人更有生产力，您不需要雇主作为借口来衡量他们的表现。

棘手的是您如何做到这一点。我的建议是雇用一些经验丰富的承包商，与您的烫发团队一起处理烫发人员估计的同一组任务，并查看它们是否具有较高的工作速度。

这将为您提供很好的比较在当前市场上没有将您锁定为长期雇用的人。

这也可能使烫发小伙有点烦恼。

此外，如果他们抱怨承包商为了提高速度而跳过质量等，这将引发关于业务价值在哪里的对话。长期可维护性或短期产品已发货。

如果是长期的东西，那么它将迫使您量化它，并根据需要将其放到sprint中！

#16 楼

已经有几个很好的答案。特别是，错误的估计，过度的投入和/或计划外的工作经常会导致滑移。

但是我很好奇为什么“ [您的]开发人员选择他们想要包含在其中的功能”每个冲刺”。开发人员通常应首先处理具有最高优先级的功能-优先级是业务决策，即应由产品所有者作为业务利益相关者的代理来进行。
（存在例外情况特别是，高风险功能通常会更早地工作。在某些情况下，面向用户的功能可能取决于其他功能，例如“在实现X之前，我们确实需要添加数据库”。）

另一方面，估算值是技术决策，不应由商人做出（或猜测）。您什么也没说-我提出这一点只是因为，根据我的经验，当开发人员选择要处理的内容时，商务人士通常会尝试决定需要多长时间。 >
听起来您的程序运作异常。我建议至少暂时不要引进开发顾问，因为这可能会对士气产生负面影响。但是听起来您的组织可以在项目管理方面使用一些帮助。从那开始，我将聘请一位经验丰富的敏捷教练-如果不是中长期合作，那么至少要进行评估或“健康检查”。一个好的教练会告诉您，如果您有表现不佳的开发人员，但至少以这种方式，整个团队（而不仅仅是开发人员）都受到审查。


另一个观察结果：根据我的经验，如果您不遵循良好的开发流程，很难使Scrum作为项目管理方法成功。您正在执行自动化的单元测试吗？甚至更好的自动化验收测试？您的开发人员是否在配对，或者您至少执行频繁的代码审查和/或演练？您正在练习某种形式的持续集成吗？