我的公司最近开始使用Scrum；我们已经完成了 2 次冲刺。我们仍在学习，但我们确实已经暴露并修复了开发过程中的一些问题。所以总的来说，我认为这对我们有好处。
在阅读了互联网上许多传播者、愤世嫉俗者和中间人对 Scrum 的思考时，我发现了三个共同但有些矛盾的主题：
- Scrum 实施之所以失败，是因为没有足够严格地遵循 Scrum 流程。
- Scrum 实施失败是因为组织没有使 Scrum 适应自己的环境/文化/实践。
- Scrum 的流程并不重要，重要的是。只有敏捷宣言中的价值观才重要。
这些例子可以在对这些问题的回答中看到：
- 您在 Scrum 或 Sprinting 方面有过糟糕的经历吗？ https://stackoverflow.com/questions/272253/have-you-had-a-bad-experience-with-scrum-or-sprinting
- Scrum 是邪恶的吗？ https://stackoverflow.com/questions/343162/is-scrum-evil
- 敏捷开发已经死了吗？ https://stackoverflow.com/questions/301993/is-agile-development-dead
我不得不承认，我们还没有遵循 Scrum 的所有指导原则：我们还没有在 sprint 结束时进行发布，我们的 Scrum Master 不希望我们在临近结束时将任务从 sprint 待办事项列表中移出冲刺的信息，以便他可以看到我们的计划有多少偏差（这意味着燃尽图永远不会变为 0），并且紧急的客户支持问题仍然具有令人难以置信的力量来扰乱每个人的计划，举几个例子。
我的问题是：在尝试解决这些和其他问题时，是尝试更接近官方 Scrum 流程更好，还是更接近我们的一些预 Scrum 流程更好，还是更好地思考 Scrum 原则来尝试提出完全不同的过程？
我想说，如果您不尽早且经常发布，那么您确实缺少敏捷性的关键组成部分之一。如果您不这样做，您的流程就不够敏捷，并且必然会遇到与传统的计划驱动流程相同的问题。这可能是暂时的情况，因为您刚刚习惯了一些事情，但您需要尽快（并且定期）开始释放。
你总是会遇到阻碍的问题，但你可以通过缩短冲刺长度来解决这个问题。客户可能等不了一个月，但有些事情他们可能可以等两周。那么，较短的冲刺长度可能会帮助您将一些请求推迟到下一个冲刺，从而减少它们的干扰。您还需要坦诚地告诉客户，这些干扰实际上导致了您的进度受到影响。如果他们知道他们选择的功能因某些请求而延迟，他们可能会自愿选择等待。
我想说的另一个观察是，与几乎任何事情一样，最好在学习时尽可能严格地遵循该模式。一旦你很好地掌握了基本原则，你就可以更清楚地看到哪些原则可以改变、打破或替换，以改进流程。在你真正明白之前，你改变的东西可能会伤害或帮助——你真的不知道，因为你没有经验告诉你事情应该如何运作。除非您的 Scrum 管理员确实经验丰富，否则您可能需要更接近定义的实践，直到您获得了更多的冲刺。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
