我该如何与适得其反的Scrum团队打交道？

#1 楼

您可能听过很多有关失败软件项目的统计信息，并得出这样的结论：失败不是技术性的。可以通过数百种技术解决方案来解决技术问题，但是使用Scrum解决工作环境中的问题是行不通的。

我的建议是，完全不要将其视为技术问题。这与Scrum无关，与日常站立，冲刺，回顾或其他类似的事情无关。您需要与您的团队保持联系，并找到一种使他们以及您和您的上司满意的有效工作方式。

如果他们认为日常工作是个坏主意，则不应告诉他们做日常工作，并尝试将您的推理方法运用到其中。自己想一想每日提供给您的东西。向您的团队检查他们是否也重视这些优势。找出他们为什么不分享您的理解-就像理解他们的观点一样，而不是说服他们任何事情。然后检查日常工作是否真的对您的团队有所帮助，或者您是否可以通过其他机制实现更多目标。 Scrum大师的有趣之处在于他们是团队的仆人-您可以完全废除Scrum来为他们提供最好的服务。

总而言之，不要再专注于Scrum了，而要回到敏捷的基础知识上来。 。您可能想从敏捷宣言一开始就开始：通过流程和工具重视个人和交互。

#2 楼

以我的经验，被幻灭的团队需要先进行有效的回顾。因此，在我看来，回顾是敏捷过程中唯一必不可少的部分。在回顾会议中，其他所有事情都可能发生变化。

在有效的回顾会议中，您不仅会抱怨自己的问题，还至少选择其中一个问题并找出可能的解决方案，然后尝试下一次迭代的解决方案。在下一次回顾中，您将讨论该解决方案是如何工作或不工作，并在必要时进行进一步调整，或者选择另一个问题来解决。

当团队成员看到他们有权处理时，影响他们的过程中的实际变化，他们将变得更愿意参与。

追溯过程就是为什么如果您拜访一家敏捷性良好的公司中的所有团队，他们的做法都有些不同。我们有一些团队进行看板工作，一些团队进行XP工作，一些团队仅在星期一（星期三）星期五做站立训练。

如果您的团队不喜欢您如何处理宿醉，请集思广益。仅仅通过不断地回顾和尝试解决方案，我已经赢得了非常勉强的开发人员。

#3 楼

好吧，让我们开始吧-问题的大部分与您有关-您听到了，但您不听。您的团队正在清楚地告诉您问题所在。您需要解决这些问题，而不是责怪您的团队。

计划


对他们来说，计划只是浪费时间，因为我们只是将溢出转移到新的Sprint，无论如何都无法完成工作，所以为什么要打扰呢。


正确。如果您始终未能为任务分配正确的时间量，并且始终低估了它们，则会产生非常不利的影响：


开发人员会感到自己一直在承受压力。
“我无法及时完成任何事情”。
由于此过程无法正常进行，因此他们理所当然地认为这是浪费时间。

解决方案：结合使用以下各项来修正您的估计：


故事点（时间和风险的结合）。
不允许任务进入大于55 SP的冲刺
比较估计
基于证据的计划

作为此基础，您绝对需要跟踪时间实际上需要完成之前的任务，包括测试，编写文档，编写测试，最终用户培训，集成工作，部署。等。

一旦完成了给定任务的总时间，就可以将预期时间基于之前的任务。

如果赋予他们的任务感觉更多，请询问每个成员比选择以前的任务复杂或容易，请据此调整已分配任务的数量。

如果您以前没有使用过SP，我的建议是从1h真正诚实的工作开始=以5SP为准则。请记住，在通常的开发环境中，您每天可能会得到其中的6个，因此每天最多30SP。切勿允许花费超过2天才能完成的任务。根据我的经验，理想情况下，您每天应该有2个任务。

如果您没有正确地进行计划，则Scrum的其余活动将看起来很浪费时间（包括计划）。

回顾性



只能感觉到他们想说“停止做Scrum”。一个人这样做，但其他人则保持沉默，我每次都必须处理。


让我想起Daily beatings will continue until morale improves!和过去的两项工作。如果您没有消除障碍，那么这是对的，那是浪费时间。它们是正确的。

再次，听听人们在说些什么。如果回顾会议期间提出的投诉没有得到解决，为什么还要打扰他们呢？

因此：


考虑六种“思考帽”技术以改善沟通。
减少在回顾会议上花费的时间，最多30分钟。
确保在回顾会议上提出的投诉在下一次会议之前得到解决。

每日简报



每日Scrum再次对他们来说只是浪费时间，因为他们没有人打扰他们谈论和计划一天。他们只是说“我昨天完成了任务X，今天将再次进行。”在大多数情况下，它们只是在开玩笑，直到我变得更加严厉为止。


类似的声音在这里有两个问题：SCRUM会议时间太长，您的计划和任务创建很糟糕。

两者都可以像召开会议一样浪费时间。

对于SCRUM长度：


最长尝试15分钟。
请大家站起来。
固定的公式：


您昨天在做什么。
您今天在计划什么。
您的团队成员（而不是您！）应该了解该任务及其对任务的影响。


如果您不去，请不要遇到障碍。解决这些问题。

这是第二个证据，表明您的计划会损害您的情况-如果您没有要报告的具体内容，通常意味着任务太大，您只能说：我在工作在上面。


将任务分解为要点。
确保任务足够小以至于花费不到一天的时间。理想情况下，IMO的任务应该持续3h左右，大约相当于13个SP，因此您在大多数情况下每天可以执行2个任务。

与团队打交道


今天，一直反对我的人告诉我不要说“他们说这是他们对本Sprint所做的承诺”，因为用他的话说，“我们从不完成Sprint。我们只从事任务并接受新任务。在下一个Sprint中完成配额。我们实际上是看板。所以不要这么说。”


他是正确的。你错了。您正在对看板进行混蛋SCRUM和/或变体。完全不是他们的错。


我理解他为什么这么说，但是他似乎并没有意识到这是事实，因为他和团队中的其他所有人都没有照顾。


我根本不理解你的意思。他们可能比以前更关心，但是责备他们不仅不会改善任何事情，而且只会使情况变得更糟。如果它是岩石底部，那么它们实际上可能会开始挖掘。


他们只是在做工作而不是处理障碍。


我在这里以为工作就是他们的全部工作。我想知道应该由谁来处理障碍。...哦，对了。 Scrum Master。这是你的工作。他们告诉你怎么了。您修复它。并非相反。

这可能就是为什么您在回顾展上有这么多问题的原因。

我如何让他们看到在这些会议中开玩笑和盘旋开玩笑会花费很多钱。公司很多钱？


停止无用的会议，他们将在watercooler周围开玩笑。如果他们使用幽默作为防御机制，您会遇到一些严重的问题！

开个玩笑-与您的团队一起工作，而不是反对。 （谁在乎公司的钱？您现在是股东吗？）

总结

您的不良计划使SCRUM的其他部分失败，每个参与其中的人惨。他们看到什么都没有改变，什么都没有解决，也没有听到他们的抱怨。

改进您的计划，您将改善流程和士气。

去做您的工作障碍，您的团队将进步更快。问问他们认为您应该如何帮助他们。

最重要的是：听取您的员工的意见。他们已经告诉过您（和我）出了什么问题。

祝你好运！

评论

---

别客气。请尽量不要自己处理。一天来，我犯了许多类似的错误：)我也很容易看到我，因为我已经加入了一些失败的SCRUM团队。尝试着重于改进团队的流程和地址关注，您会发现士气得到改善，然后您将获得很少的成功冲刺，并且只会从那里得到改善。

– Marcin Raczkowski
17年8月15日在21:59

---

抱歉，我可能有点苛刻，但有时“建议”并没有真正传达给人们。关于调整：有一句俗语：“在自己的国家很难当先知”。有时很难从内部看问题，您通常需要一些外部视角。这就是为什么他们曾经雇用Scrum顾问，现在您有Stack Overflow;）祝您好运，如果您有后续问题，请告诉我:)

– Marcin Raczkowski
17年8月15日在22:15

---

A +++++会再次购买。在这里，我认为工作就是他们的全部工作。我想知道是谁应该处理障碍....哦，对。 Scrum Master。这是你的工作。他们告诉你怎么了。您修复它。并非相反。

–跳楼
17年8月16日在16:25

---

例如：对他们来说，计划只是浪费时间，因为我们只是将溢出转移到新的Sprint中，而无论如何都无法完成工作，所以为什么要花时间呢。这与做事完全相反。在冲刺计划中，您计划要完成的所有事情。如果您没有全部完成，则不要将所有内容都放入下一个Sprint中。您的冲刺失败。您根本无法为该Sprint交付任何东西，因为您无法正确管理它。如果我错了，有人纠正我。

– Shane
17年8月17日在19:38

---

你错了。绝对不是全有或全无。想想看，有5个人组成的团队，每个人都完成了任务，但是一个人没有完成一项任务，那又如何呢？ ...你什么都不发货？废话。从您已经完成的功能中创建构建是非常好的。但是，这是Scrum在IMO方面存在问题的领域，请记住，Scrum最初是在制造环境中引入的，因此它最适合于差异较小的任务和公司（例如，Wordpress商店，该网站为小型企业提供多个网站）。这就是为什么您有诸如Spikes之类的概念来减少不确定性的原因。

– Marcin Raczkowski
17年8月17日在20:40

---

#4 楼

敏捷的主要原则之一是回去，纠正所有错误。那不仅包括代码重构和错误修复，还包括开发过程。

那么，为什么不与您的团队开会，看看如何改善开发过程？如果那意味着没有会议或座谈会，就这样。

您还打破了敏捷宣言中的原则之一：“流程和工具上的个人和交互”。

另一方面，如果您的团队认为迭代开发不好，那么也许您做错了。如果您没有完成一次迭代中计划的所有事情，那就没关系-您始终可以将事情移到下一次迭代中。这就是为什么将事物标记为“必须包含”，“很好拥有”等的原因。只要您提供新功能，就可以很好地完成工作。


小头：在我以前和现在的公司中，我们都做过并且仍然在做站立会议。根据我的经验，他们每次都花费30分钟以上的状态报告会议，而对我而言却几乎没有提供任何信息，因此它们是在浪费大量时间。人们谈论他们的问题，老实说，我不在乎。
在我以前的公司中，他们很聪明，以站立的姿势意识到了这个问题，并在人们开始抱怨后立即制止了他们。


如果您想观看有关Scrum的非常不错的视频，请参阅“ Robert C. Martin-Scrum遗忘的土地”。

#5 楼

作为我的优先任务，我将研究那些不断发展的任务。无法达到目标会极大地令人沮丧。您投入太多吗？是否有应分类的肥胖记录？是否有您无法控制的瓶颈？您对“完成”有明确的定义吗？要求清楚吗？每个开发人员的小时数是否合理（即考虑到管理员，站立，计划，回顾，键盘中断，非项目工作）。

接下来，抛弃所有无效的项目。没有价值的过程只是个时间贼。如果不专心致志，不为团队提供价值，站起来可能会花费大量时间。最好将时间花在其他地方。如果规模太大，也许也可以考虑将其拆分。

尝试解决导致团队动力不足的问题。进行回顾，更重要的是，对输出采取行动。庆祝成功和观察失败同样重要。

最后，您可能想要评估先行评估可能损害品牌的Scrum管理员的方法。我曾在一个有毒的Scrum主管下工作，在此之前，无论您是否知道，所引发的每个问题都被添加到您的工作负载中。最终结果：问题被忽略了，每个人都很少团队合作地在自己的小区域工作。

#6 楼

在我看来，让团队有效地完成冲刺（至少要关闭故事的80％）比冲刺是最重要的事情。如果您的团队始终缺席，则表明您需要调整估算值。

团队应该接受这一点，尽管要让开发人员更加现实地对待它可能非常困难。估计-我在一个团队中工作了一年，该团队没有完成一次冲刺（始终少于冲刺的50％），总是处于估计之下，在每个计划/回顾会议中，我都是一个孤独的声音，告诉他们您的估计很糟糕， '愚蠢地过分自信，不要为造成您无法进行估算的借口停止，而是调整估算以反映现实（也许比这更外交，但这是基本观点）-当您处于这一位置时，我我完全同意您的团队的curmudgeon的观点，他说此过程是在浪费时间，因为实际上您在做KonBon，无论您用什么称呼。在某种程度上，他的观点得到了实际情况的证实。很难克服这种惯性，但是如果您不能做到这一点，那么我认为团队将永远不会非常成功。

在某些时候，您必须重新设置事情，您必须获得团队为使系统正常运转而对其估算值进行了过度补偿。一旦团队开始一致地结束故事，他们应该意识到敏捷过程主要是常识，而未能以某种方式实现则对您的生产力有害。但是，只要不认真地对待“承诺”和“冲刺目标”（当他们未能始终如一地实现它们时就会发生），那么整个事情就是假的，并且会浪费团队的生产力。

要让人们以截然不同的冲刺（在估计，计划，承诺等方面）买进是很困难的，由于两个因素，我最终在那个团队中做到了这一点。一个人只是从JIRA收集数据，然后说：“没有任何借口，数字是遥遥无期的，它们总是在一个方向上偏离，我们需要更正它，我不希望借口是复古的，我想“数量的总和” –另一个是高层管理人员带来的压力，我最终向他们解释说……“这个过程的目的是使我们的开发时间表可预测。如果我们每完成固定数量的工作，最好的sprint，独立于此，我们的董事会需要准确地反映我们所做的工作，管理层更了解我们相对于承诺的成功，而不是对实际产出的成功，就您自己而言，使预测与输出，因此看起来您正在完成工作，而不是花费每个sprint的一半做任何事情。从这个时间开始，离职人员越多，他们看到失败的机会就越多，您在追溯中的借口甚至都没有在他们的权限范围内，他们只会看到您失败ng。“

最终，我们的团队得到了牵引力，事情开始变得更加顺畅，低调和顺其自然，一旦流程真正开始工作，我们甚至开始获得更高的输出。因此，tl; dr-采取一切必要措施以相对较高的成功率开始关闭sprint。如果您不这样做，那么团队中的巡回赛将继续通过结果验证他对Scrum的抵抗力，并且最终将是对的，因为您的过程实际上只是在浪费所有人的时间。

#7 楼

作为Scrum Master，您指导并指导团队提高生产力。 Scrum框架是实现此目标的强大工具，但是Scrum框架绝对绝不能成为目标，否则您将从事货运崇拜。

看来您从事货运崇拜已有3年了，人们意识到这是一种可怕的项目管理方法。好消息是您有聪明的人，他们做对了。不幸的是，您公司中的某些人称其为Scrum，但您又有了聪明的人，他们甚至告诉您团队的工作不被称为Scrum。


规划只是浪费时间，因为我们只是将溢出内容移至新的Sprint中，而无论如何都不会完成工作，所以为什么要打扰呢。何必呢？您需要找到答案，或者更确切地说，您需要更改计划和冲刺本身，因此有必要进行计划。要么，要么停止浪费时间与无意义的Sprint计划。您可能想请公司派遣Scrum Master培训给您，因为进行出色的Sprint计划并不容易。


在回顾期间，其他人沉默寡言，我每次都要处理。


如果您在每次回顾展上都处理相同的问题，那么人们甚至不愿意（不再吗？）在回顾展上大声疾呼，那只是浪费时间。除非您或团队能够以某种方式解决回顾会议中提出的问题，否则会议只会使团队士气低落。回顾会议中提出的问题必须得到解决，下一个回顾会议也应该取得进展。


每天的Scrum再次对他们来说只是浪费时间，因为他们都没有打扰他们说话和交谈。计划一天。他们只是说：“我昨天处理任务X，今天将再次处理。”


的确，如果每个人都花几天时间从事相同的工作，那又何必浪费他们的时间呢？他们是完全正确的，“每日站立”确实是没有意义的。 Standup促进了许多任务的紧密协作，每个任务可以在半天或更短的时间内完成。如果您无法按照这种方式分解任务（由于Sprint计划中断，或者因为您的任务实际上与Scrum不合适），那么举行5分钟的每日站立会议就没有多大意义了（不超过5分钟，对吧？）。


“我们从未完成Sprint。我们只是移入任务，并在下一个Sprint中接受新的
来填充配额。我们实际上是看板。
别这么说。”

我理解他为什么这么说，但他似乎没有意识到
这是怎么回事这是因为他和团队中的每个人都不在乎。


不，你绝对不明白他为什么这么说。您有障碍的根本原因-您需要解决-错误。他们不在乎，因为团队的项目管理实践很糟糕。关心做货崇拜和更努力地做货崇拜并不能阻止它成为存在的最糟糕的项目管理方法之一（在您的国防中：也是最广泛使用的方法）。


对此您该怎么办？


听听他们的关注。同样，您很幸运，因为有了聪明的人。
帮助他们解决障碍。

就是这样，真的。您将需要试验如何更改Sprint计划，每日Scrum和回顾展，以使其对团队有价值-即使您想删除Scrum标签，您仍然要召开这3次会议，它们的频率和目的相似项目管理方法论。至于您要如何进行实验（频率，内容，主持会议的人，时间，持续时间等），这非常容易：请团队。不要将您的想法强加于他们，如果有任何事情，您应该让他们将您的想法强加于您（假设他们可以就某些想法达成一致）。

如果您担心会失去控制，请事先设置一些界限，例如：


会议的标签保持不变。
会议仍在举行，会议的频率更改不得超过2倍。
您正在尝试，因此任何更改仅能持续2 sprint，之后恢复到旧模式（最佳给他们几周的时间，以避免他们想使冲刺持续时间加倍的模棱两可。）

#8 楼

我认为每个人都在《敏捷宣言》中引用了同一行。我将做同样的事情：“流程和工具上的个人和交互。”

如果您作为SCRUM的主人想要使用SCRUM来完成这项工作，则必须将它们当作一个人与另一个人进行交互来对待。 。开始集思广益如何使流程更好。也许您可以说服他们喜欢SCRUM。也许他们可以说服您使用其他过程。让我们找出答案吧！

听起来团队已经认识到当前的系统无法完成任务。您能鼓励他们相信它能胜任吗？您提到了一些示例。如果您将Sprint填满，以至于它始终泄漏...请停止。是您的SCRUM团队。帮助他们停止过度投入。推迟管理以获得一些喘息的空间。使用SCRUM的好处。用它向管理人员展示数据，他们正在努力地努力，以至于他们失去了流程中的价值。如果管理层希望将SCRUM作为一个过程，请让他们帮助建立修复它所需的空间和能量。作为SCRUM的主人，您的任务是解决问题，使团队高效。

另一种有用的方法是在旧流程中产生一个新流程。继续以相同的无用方式运行SCRUM，但是请警惕时间表的一小部分，然后说：“在我们的时间表的这一部分中，我们将弄清楚如何正确使用工具。”不要在那里过量使用。使用您的指标。专注于在那里的所有会议。只是“ SCRUM”项目的其余部分，可以作为盾牌，使您和您的团队在保持管理层满意的同时“通过开发并帮助其他人来发现开发软件的更好方法”。随着时间的流逝，您会希望将越来越多的有价值的任务放入此存储桶中，而旧存储桶将慢慢消失。很快，您将拥有一个蓬勃发展的软件开发环境，没有人会更明智。

或混合搭配。我开发了一个反乱序程序。客户希望能够在此过程中的任何时候添加新任务，并让我们立即对其采取行动。 （这实际上是一个理智的请求：他们的工作非常不稳定，经常需要快速的支持……这就是我们的报酬）。当然，我们必须弄清楚如何处理他们的“当您在冲刺中答应X时为什么不做X”问题。我们的解决方案实际上是建立一个两步过程。长期任务已放入SCRUM中，以进行适当的优先级排序。短期任务置于自制流程中，该流程着重于客户端与开发人员之间的紧密交互。据了解，欢迎客户使用此短期流程来推动我们，但他们知道这样做会推动Sprint的时间表，并且禁止他们添加请求，而不能同时听取并解决他们造成的计划问题。结果？有效。大多数任务都按应有的方式放在了SCRUM流程中，紧急情况与它们无缝地交互。态度是“如果您想成为客户，请排队观看SCRUM的故事。如果您想成为合作伙伴，请随时下来与我们合作，使我们的产品正常工作！“

#9 楼

我之所以这样说，是因为我真的知道。您在高层管理中存在一个问题，即过度安排，无法设置优先级，不愿意添加更多项目但不推迟发布日期。

我曾经说过，没有一种方法可以起作用像这样，但是既然我看过看板，我说可以，但这只是因为看板不必在意。过量使用时，它继续起作用。它不会更快地带来结果，但不允许将队列中的备份放在任何人身上，因此管理问题在于管理。反馈报告显示过载，这是正确的。

#10 楼

由于Scrum Master的这种更改及其运行
show


的方式，哦，好吧，这可能是您的问题。 Scrum主管不在那里进行表演，他不是项目负责人。他在那里确保所有利益相关者都在沟通并且操作透明。

我想知道团队的来历。在Scrum（包括不可避免的Scrum管理员）落在他们身上之前，难道是他们或多或少地具有自主权？为什么首先引入Scrum？应该解决什么问题？

Scrum应该提供指导，您的团队正在明确表示他们没有以任何方式感到有用。他们不在乎指导，他们认为这是不适当的时间浪费。显然，至少有一个决策者认为他们无论如何都要受到指导。 WHO？为什么？他们有观点吗？

#11 楼

这是一个问题，不仅限于软件。

在任何工作环境中，都会有不同个性和能力的人。即使Scrum是一种完美的方法，由于其个性和能力，仍然会有人们反对它。

开发人员以合理的方式处理困难的任务。为了做到这一点，每个开发人员都将有自己的方式来处理这类事情，这些事情可能表现为对Scrum之类的厌恶。如果所有开发人员都以完全相同的方式从头开始接受培训，则使用一种模式可能会容易得多，但否则需要在开发人员或管理方面进行调整。

此外，独立的思想家（开发人员和其他专家）通常不喜欢被告知如何做事，因为那是他们的工作，意见冲突很容易发生。对于逻辑思维者来说，Scrum似乎是没有意义的仪式，他们通常会针对每个问题进行分析并采取相应的行动。

以下内容似乎在暗示问题的根源，而不是问题所在。绝对不止如此。我只能（出于经验）假设开发人员尝试过但遭到阻止。我见过很多次，开发人员想要修复某些东西，但是系统的东西（管理，公司政策等）使它几乎不可能，因此他们放弃了。他们是真的不在乎，还是不只是在乎做一些他们认为无济于事的事情（可能是经验不足）。


我理解他为什么这么说，但是他不这样做似乎没有意识到
是这样的，因为他和团队中的其他所有人都不在乎
。他们只是做事而不是处理障碍。他们
抱怨有障碍，但是对他们什么也没做。还有
，当我试图帮助他们时，他们只会耸耸肩。

他们曾经很讨厌，但在过去的两年中，他们的
意愿或多或少地下降了。底部。

我该如何让他们看到在这些会议中开玩笑和打来回去花了公司很多钱？


如果有人强迫别人做某事，那就是由人们强迫方法说服他们的利益。尽管我真的不相信强迫人们做事，但我还是建议在任何情况下都应该听取大家的意见，并开发出一种适合当前环境的方法。

#12 楼

Scrum并非没有缺点。我当然可以为自己说话，但是我认为开发人员讨厌它是有充分理由的。我的诚实观点是绝对不能尝试。

要了解原因，请阅读每个Scrum管理员应该了解的Scrum知识。它不是我写的，但是所有的一切都代表了我的经验，我只能总结为纯粹的恐怖。

我的情况尤其是在第5点遭受了痛苦。基本上，scrum对待了我作为一个孩子和一个失败者。现在，我是一个足智多谋的联合开发人员，可以帮助我的同事们……难怪我更喜欢！

我现在有了一个新的（非scrum的）老板，可以四处走动并与人们交谈，并且我为此感到非常感谢！之所以可行，部分原因是我们还拥有一个聊天室（我们使用最多的聊天室）供开发人员之间进行交流。如果有人在讨论议程，我们会把它放在那儿。会议仅用于开发人员的临时讨论，而不是为自己设置人为的每日截止日期。

#13 楼

您已经得到了很多很好的答案。这里还有其他几点可能会有所帮助：

改变方法论很困难

在工作区中这是一个巨大的挑战，因为您正在“

您很正确地得出结论，您的团队需要花更多的时间进行计划，而不是花更少的时间，这是正确的。计划是您当前所处的时间不多，需要改进的地方。问题是，您不能仅仅通过制定新规则来达到目标​​。在成为新的帮助之前，新规则是新的负担。而且，如果它们不能立即提供巨大的价值，那么您将得到回避而不是合作。

我强烈建议Roy Osherove在这个主题上。他简要介绍了如何在您的公司中计划和实施变更，并在本视频中深入探讨了该主题。

Osherove的基本观察认为，以下所有挑战都需要见面：


个人动机：为什么某人应该关心以特定的方式行事？个人能力：他们会照字面行吗？社会动机：这种行为是否有同伴压力推动？ ：我周围的人是否支持我的行为并在需要帮助时帮助我解决？结构动机：良好/不良行为是否有奖励/惩罚？结构能力：物理环境是否支持这种行为？


您需要学习分解任务

您的团队认为“我昨天完成了任务X，今天将再次完成任务”，他们似乎是对的，感觉任务会被推迟一周。

这里真正有用的是学习如何将任务分解为几个小部分。您正在寻找的是以下问题的答案：“好，您正在处理任务X，但是今天您正在处理任务X的具体内容是什么？”

一些答案可能是：


我正在学习此类旧代码。
我正在修复错误，其症状是（症状）。


如果这是一个持续不断的错误，并且需要一段时间：“今天我要尝试的是...（计划）”


我需要更改此界面。
我正在编写测试。
我正在集成未经测试的代码。

...等等，依此类推。能够观察一天或一周内实际可以完成的工作，这是Agile的一大优势。但是，这意味着您实际上需要查看单个工作日的解决方案，而不是某些随时准备就绪的单片式TaskX。

完成与交付

一个常见问题（对于敏捷，以及一般的工作场所规划）是，截止日期往往来自管理层，而不是开发人员。该截止日期可能与实际要完成的工作背道而驰-特别是，它可能希望尽快交付。

问题是，“尽快交付”是一个非常混乱的过程。它鼓励偷工减料；编码“快速而肮脏”；忽略准则；不要自己清理。它鼓励一种“尝试一下，看它是否有效。如果可以，交付，如果不可以，请尝试其他方法”的心态，并且这样说，您就能明白为什么没人能预测任何事情需要多长时间。 >
如果您有条不紊地进行工作，如果您对计划和测试等进行严格的检查，那么您已经建立了许多路标和安全网。这可能会花费更长的时间-您花了很多时间来处理无法促进立即交付的事情，并且您可能还不太擅长这种工作流-但它的波动性会大大降低。 br />
因此，要问自己一件事：开发人员是否根据他们实际看到的需求设置了冲刺目标？还是管理人员设定了最后期限，让开发人员尝试将其承诺安排在类似sprint的时间表中？

如果开发人员没有足够的时间来计划或按照规定工作可靠的计划，也就难怪他们无法做出有用的估算。 :)

#14 楼

这可能是一种不受欢迎的意见，但您可能对此无能为力。

我可以想象，在团队存在和领导者不断涌动的这些年中，对团队真正不满意的人， 剩下。剩下的就是那些可能会抱怨的人，但对实际投入精力来改善这种情况并不感兴趣。他们只想花费8个小时的黑客代码，而不会被任何人打扰，只能在一天结束时回家。您在这里拥有的东西似乎是严重的动机问题。解决该问题不是Scrum管理员的工作。这是谁来付钱给那些人的问题。

如果确实如此，那么只有真正的选择是摆脱当前的团队，并从头开始。也许留下您认为是团队中最优秀的一两个人，然后开除或将其余人员转移到其他团队。您至少应该与上司讨论这种可能性。