Scrum 的 5 个错误希望以及如何解决它们

像许多经典的、永无止境的冲突一样，关于开发团队应该如何组织和自治的争论也很激烈。 目前，似乎批评者多于 Scrum 的粉丝。 最常见的三种抱怨是：

1. 这个过程可以成为工作的中心。
2. 它很容易被另一个名称与微观管理混淆。
3. 每日站会感觉就像是一个必须证明其存在合理性的会议。

在其他情况下，Scrum 的角色没有得到适当的表示。 有时，产品负责人想要在一个 sprint 中做太多事情，或者想在 sprint 中期改变优先级——一个专注于保持速度和采用他们学到的每一个新的 Scrum 仪式的 Scrum master。 在使用框架一段时间后，似乎出现了一个常见问题：“是我们还是方法论？”

Scrum 的错误希望

虽然存在许多类似上述的功能障碍，但其中大多数的简单根本原因是 Scrum 并非旨在通过仅仅遵循流程来解决组织内的潜在问题。 未能认识到这一点可能会使新团队几乎一开始就处于危险之中。

错误的希望#1：Scrum 让团队工作更快

Scrum 使用的术语在外人看来就像它会在不增加额外资源的情况下加速流程。 作为 Scrum 的新团队，很容易陷入术语中（例如，什么是 Scrum 主管？产品所有者和产品经理之间有什么区别？什么是故事点以及它们是如何分配的？）

更令人不安的是，许多人看到速度和冲刺等术语并认为是“速度”。 但是，包括 Scrum 在内的任何敏捷方法的目的都是交付成品。 最终，随着您的团队变得更有能力使用 Scrum，您将能够更快地交付新功能。 然而，速度不一定是首要目标。 这种区别应该在您的 Scrum 团队中明确表达，当您在公司内建立意识以支持 Scrum 方法时也应如此。

你卖的不是速度； 你卖的是完成。

错误的希望#2：严格遵守 Scrum 将解决公司文化问题

每个人都有不同的工作方式。 有些人喜欢开会。 其他人则使用诸如“努力工作，努力玩耍”之类的短语。 重要的是要认识到，无论您的公司重视哪种工作方式，您都接受了它的优点和缺点。 重视会议的公司可能会在日常站立会议上遇到困难。 积极进取且以速度为导向的团队将在 sprint 中遇到范围蔓延的问题。

有时很容易忽视大局，尤其是对于最近组建的团队。 重要的是交付成品，而不是遵循流程的最后一点。 与其责备方法论，不如始终寻找改进工作方式以实现目标的方法。

错误的希望#3：关键贡献者可以派代表参加会议

一旦你开始使用该方法，原始团队的参与而不是委托是至关重要的。 如果我从开发人员那里看到一个几乎普遍的抱怨，那就是 Scrum 主管和产品负责人在需要时不可用，并且他们的代表没有被授权。 没有人喜欢参加会议，期待做出决定，却被告知无法做出决定的人。

委派可能是一种常见的做法，但在 Scrum 中，您还必须授权参与者。

错误的希望#4：每日站立会迫使每个人更加专注

每日站立会议不应仅仅关注每个人在过去 24 小时内所做的事情。 优先考虑解决问题的障碍或新方法更为重要。

Scrum 需要某些角色，尤其是 Scrum 主管，要自信但又不能压倒一切。 Scrum master 创造一个积极的环境来完成产品是很重要的。

错误的希望#5：我们将在第一次尝试中成功

Scrum 涉及猜测、演绎思维和犯错。 人们很少在第一次尝试时就做对了。 Scrum 在所有方面都是迭代的：不仅在你如何达到成品方面，而且在你如何管理和操作流程方面。 Scrum 旨在降低团队采用的进入门槛，但它也需要承诺迭代并不断提高对框架的参与。

如何修复损坏的 Scrum 流程

Scrum 可以抵抗沉没成本谬误。 Scrum 的迭代特性为适应或丢弃无效流程创造了机会。 如果您的 Scrum 流程不如您预期的那么有效，请考虑以下一些建议。

完善您的期望

无论是缩短上市时间、创造引人注目的产品，还是帮助团队协作，成功都需要投入和时间。 对于新团队来说，一个合理的里程碑是在每个 sprint 之后，您是否可以将工作的、可测试的代码引入您的生产环境。

高级团队可以通过按需构建、测试和部署的能力来衡量成功。 您是否能够检测和量化用户对新功能的反应？ 更广泛的组织是否准备好支持团队对产品所做的更改？

授权您的参与者

重要的是要离线指导团队成员如何增加他们对团队的价值。 如果他们被要求做出决定，请通过指导他们何时以及如何让其他团队成员参与来增强他们的信心。 经理需要准备好清除障碍并在需要时支持团队。

主动解决问题

Scrum 的设计初衷不是让您的公司焕然一新。 如果您没有解决问题，那么您很可能会在产品开发过程中发现这些问题。 Scrum 主管可以引入旨在为团队成员创建积极的方式来构建他们的反馈以减少冲突感的框架。

一个这样的例子是“我希望，我想知道，如果”框架。 在团队讨论或回顾期间，团队成员可以通过使用这三个短语之一打开他们的陈述来提供反馈。 例如，他们可以说：“我希望站立会议能够更多地关注我那天可能需要注意的障碍。” 您也可以使用自己的开场白，例如“我喜欢……”。

另一个在会议期间有用的结构化反馈解决方案是来自 Holocracy 的 Triage 方法，由 Brian Robertson 创建并被 Zappos 等公司使用。 例如，参与者建立一个“紧张”议程来讨论。 每个参与者都通过说“我有压力”来描述他们的问题，然后列出解决问题所需的人员和资源。 通过鼓励参与者直接将问题视为“紧张局势”，Holocracy 使参与者能够自由交流，而不会造成冲突气氛。

使用回顾来解决问题并迭代过程

在许多公司，回顾没有得到应有的重视。 这主要是因为许多人担心回顾会是旧争论、冲突和不满的场所。 团队制定反映团队价值观和公司文化的基本规则至关重要。

同样重要的是需要避免投资于静态流程。 曾经有效的东西可能不会永远有效。 许多团队都在为参与者的流失而苦苦挣扎。 这在许多公司中很常见，因为参与者被重新分配到其他团队、获得晋升或完全离开公司。 随着团队组成的演变，重要的是不要一直致力于 Scrum 中的一切都是迭代的。 错误会发生，但希望它们在您迭代时会是短暂的。

当校长在场时，Scrum 工作得最好

作为团队中的一员，您必须承诺在场并随时待命。 产品开发可能是贵公司为改善其长期增长而可以采取的最关键的过程。 因此，作为新产品开发的主要途径，Scrum 过程得到应有的重视是很重要的。 在许多环境中，开发团队的工作通常与推动公司目标的决策和讨论脱节。 Scrum 是不同的。 Scrum 是决策、方向和开发作为一个单一过程结合在一起的地方。 在 Scrum 方法论中举行的会议中，派遣代表或将团队成员排除在外是非常重要的过程。

摘要：您可以修复损坏的 Scrum 流程

由于它的迭代性质，Scrum 有助于保护业务不会走得太远，并致力于可能最终成为一个坏主意或实施不善的流程。 坚持这一原则有助于从过去的错误中解脱出来，并迭代改进 Scrum 流程。

重要的是要关注您拥有的个人和团队。 团队成员发生变化。 所有项目都不一样。 严格遵守流程并不总能产生最佳结果。 您在流程之外对团队成员的投资与您在流程中的行为方式同样重要。

Scrum 可以很灵活。 如果某些东西不起作用，请考虑在敏捷内部和外部合并来自其他框架的元素。 识别并采用对抗性讨论的结构化沟通方式。

Scrum 通过使团队能够构建完整的产品来响应不断变化的客户需求，从而有利于长期投资回报。 Scrum 可能是最好的方法，它可以让你避免过度致力于糟糕的想法，同时为伟大的想法提供一些进一步发展的空间。