引入SCRUM时，您看到什么地方出了问题？

当您的公司决定用SCRUM替换当前流程时遇到的单点故障是什么？

您能举一些公司尝试引入SCRUM时出现错误的例子吗？我想听听您的轶事，经历过的事情，看到的重大失败但无法阻止。

对于缺少有关实现细节的决策以及故事的大小和细节级别的决策的文档，我听到很多担忧。

最大的问题是误解。常见的故障有：

• 只有一个团队在做Scrum，但是公司的其他成员（包括销售，管理，人力资源）仍然以旧的方式思考。例子：

  与客户的持续互动以及客户的参与非常重要。

  人力资源部必须了解，团队绩效比个人绩效更重要。KPI必须更改为该值。

  特征定义是连续的过程。项目定义将在开发过程中根据客户反馈进行发展。由于该项目的截止日期，所需的预算或结果功能集可能会更改（在利益相关者批准后）。

  变更是流程的一部分。

  估算是一个连续的过程，您不能在项目开始时就说要在5个月内完成所有功能（其中许多功能在开始时就不为人所知）。

  团队有权做出决定。团队致力于下一次冲刺期间交付的功能数量。不能要求或命令。

  冲刺是团队的安全区。一旦团队致力于某些已定义的用户案例，就不能在团队外部修改承诺。

  迁移到Scrum时，旧的组织结构的一部分没有意义。Scrum定义了三个角色：Scrum主，产品所有者，团队。还有其他角色，但是这三个角色通常足以交付应用程序。通常，没有Scrum主管，团队负责人，产品负责人和一个或多个项目经理是不明智的。项目经理和团队负责人是Scrum中的多余角色。

• 分配Scrum主机角色的Guy没有在做Scrum主机。Scrum master解决了障碍。任何干扰团队的障碍都是必须尽快解决的问题。最常见的失败是将此角色分配给开发人员，而以前没有使用Scrum的经验。这个角色部分地代替了普通的项目经理，但是Scrum管理员没有控制团队的权力，Scrum管理员不需要任何功能。Scrum负责人甚至在需求无法实现的情况下保护团队免受产品所有者的侵害。

• 分配了产品负责人角色的盖伊没有担任产品负责人。产品负责人对产品负有财务责任。这是非常具体的，对成功至关重要。该角色与分析人员，项目经理和产品经理有共同点。产品负责人收集并维护需求（通常以用户故事的形式）。他的职责是向团队提供信息并确定用户故事的优先级。他应该在团队中，因为PO和团队之间的合作是持续的。
• 将流程名称更改为Scrum，但保留大多数流程，就像以前那样。最常见的情况是您将从瀑布更改为Scrum，最重要的更改是您不再进行分析和文档编制，而是说自己是Scrum。
• 需求/用户故事缺少完成的定义-非常常见。如果您没有完成的定义（接受标准），则无法在冲刺计划期间就用户故事的复杂性做出任何假设。如果在sprint期间没有它们，则无法将用户故事标记为已完成，因为您无法对其进行验证。
• 质量被认为是可选的。Scrum的质量是头等公民。我们可以说，每个接受标准都应包含在自动化的端到端测试中。一旦开始降低质量并添加未经测试的功能，您将失去对产品的控制，因为被视为已完成的功能可能会由于回归而随时停止工作。
• 冲刺的结果应为产品可运送的增量（=工作并经过测试）。

编辑：

我要添加重要说明。使用敏捷方法时，重点是尽快为客户提供最高的业务价值。但是客户（由产品负责人代表）描述了什么是业务价值。因此，在使用Scrum时通常没有分析或文档是不正确的。如果客户要求分析或记录并将其标记为业务价值（例如，由于大规模或长期的项目，该项目将在未来几年中得到改进），您也将创建它。最基本的方法是将分析和文档包含在用户故事的接受标准中。在这种情况下的分析以书面形式记录了与产品所有者的通信。

在10多年的XP和Scrum竞赛中，我注意到的最大问题是，当团队还没有“敏捷”敏捷，决定“灵活敏捷”并开始自定义敏捷，删除某些部分等时，清楚地了解每个部分的功能及其存在的原因。

我已经看到，当团队开始按书着手做事时，团队在scrum方面比在改变他们还未“得到”的团队更成功。

那就是当您得到诸如“第一次冲刺，我们将满足所有要求，第二次冲刺所有设计，等等，最后一次冲刺所有测试”之类的事情时。也称为瀑布。甚至是一些简单的事情，例如“不管怎样，这个独立的业务如何？”。

与Shuhari（http://c2.com/cgi/wiki?ShuHaRi）有关。

最大的问题总是买进。如果没有任何团队或关键人员（项目管理，质量保证，开发等）参与进来，那么失败几乎可以肯定。

另一个相关的问题实际上是使每个参与人员都知道实际的scrum是什么，什么不是。

我看到过这样的环境，在这些环境中，项目管理实际上已将其视为直接向开发人员进行更改的票证，并期望明天完成，因为我们正在使用新的伟大流程。在这种情况下或其他尝试实施Scrum的尝试失败并且口中有苦味的人。这些人有时还会尝试破坏项目。

我看到的另一个问题是站立会议。您将始终得到一个想要在标准会议上坐下来的人。...“我的背板很烂”或其他任何东西。似乎永远是同一个人，完全不知道站立的目的是什么，也不会为政治或他在那个周末所做的事情而闭嘴。我发现站起来的会议是有效沟通的关键。重要的是不要让任何人毒害这些会议。

尝试对我们实际上是在同一冲刺中开发的代码进行所有分析。

不久前，我们转移到了Scrum，坦率地说，运行它的管理层将每个Scrum视为一个2周的瀑布过程。如此严格遵守scrum规则本身就是一个过程！

这是我发现的问题，所有敏捷方法都应具有灵活性，以便以适合您的方式有效地工作。不是流程所禁止的方式。例如，我们有2周的Scrum，一个团队表示他们觉得2周不足以完成良好的工作（不包括Scrum演示结束和最初的需求审查导致的停机时间），所以他们想转到3周。震惊恐怖！管理层拒绝了，因为他们认为每个scrum 2周是理想的，并且现在已记录在质量程序中。

Scrum是敏捷方法中最不敏捷的，这也许就是为什么它如此流行的原因-它更容易卖给老手。您应该删除不喜欢的东西，但我认为不会发生这种情况。我的建议是选择一种更灵活，规则更少的规则，然后添加您需要的规则。因此，我更喜欢Crystal。

最终，只记得半醒的敏捷宣言。

最大的问题是您的客户也需要接受SCRUM流程并变得敏捷。大多数客户希望在项目开始时就听到以下内容：

• 多少钱
• 看起来如何
• 什么时候完成

这听起来很合理，但与敏捷绝对不兼容。您需要向客户解释为什么敏捷对他有好处，而不是瀑布。

我第一次去SCRUM时遇到两个大问题：

1）我们实际上没有产品负责人。我们的老板必须扮演这个角色，因为没有人应该是产品负责人。这种事情使事情陷入困境，因为他并不总是真正知道答案。

2）我们不擅长考虑外部因素。我们最初的sprint涉及到完全自动化测试的启动和运行，并且我们反复遇到使所用模拟器自动化的麻烦。不知何故，我们从来没有更好地意识到这将要发生。

我在项目中面临的主要问题是，在我们估计了下一个冲刺之后才进行需求收集。我们根据验收标准进行估算。在需求收集期间，我们发现经过微调的交流电要大得多，因此最初估计为8小时的任务现在实际上是24小时！那么我可以更改我的sprint积压订单并修改估算值并减少故事吗？不，先生！敏捷要求您不能更改sprint积压！那就是我的TL所说的。因此，我也不应该按照最初的验收标准进行编码，因为我将其估计为8个小时！神！没有！你不能那样做！那不是敏捷，是吧！