关闭。这个问题不满足Stack Overflow guidelines .它目前不接受答案。
想改善这个问题吗？更新问题，使其成为 on-topic对于堆栈溢出。
3年前关闭。
Improve this question
我的公司最近开始使用 Scrum；我们已经完成了 2 个冲刺。我们仍在学习，但我们肯定已经暴露并修复了我们开发过程中的一些问题。所以总的来说，我认为这对我们有好处。
在阅读网络传道者、愤世嫉俗者和中间人对 Scrum 的许多思考时，我发现三个常见且有些矛盾的主题:
在对这些 SO 问题的回答中可以看到这些示例:
我必须承认，我们还没有遵循 Scrum 的所有指导方针:我们还没有在 sprint 结束时进行发布，我们的 Scrum Master 不希望我们在接近结束时将任务从 sprint backlog 中移出sprint 以便他可以看到我们的计划有多少偏离(这意味着燃尽图永远不会变为 0)，并且紧急的客户支持问题仍然具有令人难以置信的力量来扰乱每个人的计划，举几个例子。
我的问题是:在尝试解决这些和其他问题时，是尝试更接近官方的 Scrum 流程，还是更接近我们的一些前 Scrum 流程，还是更好地思考 Scrum 的原则以尝试提出完全不同的过程？
最佳答案
我会说，如果您不及早和经常发布，您就真的错过了敏捷性的关键组成部分之一。如果您不这样做，您的流程就不够敏捷，并且必然会遇到与传统的、计划驱动的流程相同的问题。这可能是一种暂时的情况，因为您刚刚习惯了事物，但您需要尽快(并定期)开始发布。
你总是会遇到表演障碍的问题，但你可以通过缩短冲刺长度来帮助解决这个问题。客户可能无法等待一个月，但对于某些事情，他们可能能够等待 2 周。那么，较短的冲刺长度可能会帮助您将某些请求推迟到下一个冲刺，从而减少它们的破坏性。您还需要提前告知客户中断实际上会导致您的步伐受到影响。如果他们知道他们选择的功能被某些请求延迟了，他们可能会自愿选择等待。
我要提出的另一个观察是，与几乎任何事情一样，最好在学习时尽可能地遵循模式开始。一旦您很好地掌握了基本原理，您就可以更清楚地看到可以弯曲、破坏或替换某些原理的哪些地方，以改进流程。在你真正明白之前，你改变的事情可能会伤害或帮助——你真的不知道，因为你没有经验告诉你事情应该如何运作。除非你的 Scrum 大师真的很有经验，否则你可能想要更接近定义的实践，直到你有更多的冲刺。
关于project-management - Scrum:太多还是不够？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/413553/