Scrum:太多还是不够？

Question

我的公司最近开始使用Scrum；我们已经做了两个sprints。我们仍在学习，但我们已经暴露并修复了开发过程中的一些问题。所以总的来说，我认为这对我们是有好处的。

在阅读许多来自福音派、犬儒主义者和介于两者之间的人的关于Scrum的互联网思考时，三个共同的、有些矛盾的主题对我来说很突出：

1. Scrum实现失败，因为没有足够密切地跟踪Scrum的过程。
2. Scrum实现失败，因为组织没有使Scrum适应自己的Scrum过程，这并不重要；只有敏捷宣言中的值才重要。

这些例子可以在对这些SO问题的回答中看到：

• Have you had a bad experience with Scrum or Sprinting?
• Is Scrum evil?
• Is Agile Development Dead?

我必须承认，我们还没有遵循Scrum的所有准则:我们还没有在sprint结束时发布，我们的Scrum Master不希望我们在sprint接近结束时将任务从sprint积压中转移出来，这样他就可以看到我们的计划已经偏离了多少(这意味着burndown图表永远不会变成0)，举几个例子，紧急的客户支持问题仍然具有令人难以置信的力量来打乱每个人的计划。

我的问题是：在试图解决这些和其他问题时，是更好地尝试并更接近官方的Scrum过程，是更好地接近我们的一些前Scrum过程，还是更好地沉思Scrum的原则，尝试并提出一个完全不同的过程？

Answer 1

我要说的是，如果你不及早发布并经常发布，你就真的错过了敏捷的关键组件之一。如果您不这样做，那么您的流程就不是敏捷的，并且必然会遇到传统的计划驱动流程所存在的问题。这可能是一种暂时的情况，因为你刚刚习惯一些东西，但你需要很快(并定期)开始发布。

你总是会遇到停止展示的问题，但是你也许可以通过缩短你的sprint长度来解决这个问题。客户可能无法等待一个月，但他们可能可以等待2周来完成某些任务。那么，较短的冲刺长度可能会帮助您将一些请求推迟到下一个冲刺，从而减少它们的破坏性。您还需要向客户坦率地说，中断实际上正在导致您的速度受到影响。如果他们知道他们选择的功能被一些请求延迟了，他们可能会自愿选择等待。

我要做的另一个观察是，与几乎任何事情一样，最好在学习过程中尽可能紧密地遵循模式。一旦您很好地掌握了基本原则，您就可以看到在哪些地方可以更清楚地折弯、破坏或替换一些原则，以改进流程。在你真正得到它之前，你改变的事情可能会带来伤害或帮助--你真的不知道，因为你没有经验告诉你事情应该如何工作。除非你的Scrum大师是真正有经验的，否则你可能想要更接近定义的实践，直到你有了更多的冲刺。

Answer 2

我在Scrum上读到的几乎所有内容都说，关键之一是调整流程以适应您自己的情况。没有两个开发团队是相同的，不同的东西适用于不同的人。

Scrum背后的主要思想是：

有一个从需求到开发再回到涉众的紧密反馈循环。

这允许开发团队不断地验证他们正在构建实际需要的东西，并允许开发随着需求和期望的变化而轻松地进行调整。涉众可以在任何时候添加或删除功能，并且可以随着需求的变化调整功能的优先级。

保持软件在任何给定的sprint结束时都可以发布的状态。

这并不是说你已经发布了每个sprint，但如果客户决定他们想要最新的东西，你可以。这也帮助开发团队避免了集成地狱的情况，这种情况来自于人们离开并孤立地一次工作几个月的项目的一部分。

对开发中发生的事情保持完全透明，每个人都需要愿意做出权衡。

这是大多数项目失败的地方，也是Scrum能够真正成功的地方，如果每个人都参与这个过程的话。如此多的开发项目被设置为一个版本必须在Y日期发布X个特性，并且没有灵活性来改变这一点。这导致了半途而废的特性和布满bug的软件，因为开发人员挤在他们的清单上获得所有需要的特性。

事实是，在软件开发中会发生意想不到的事情。通过开放的沟通和愿意参与Scrum过程，客户和开发人员可以不断评估项目的当前状态，并做出明智的决策，确定项目剩余工作的优先顺序。

Answer 3

Scrum确实起作用了。并不是所有的团队都在所有的情况下，但它已经被证明是有效的。

我建议在你的商业环境允许的情况下尽可能多地拥抱教科书上的Scrum，看看它是如何工作的，然后调整它。

为什么您的Scrum管理员不想将任务从sprint backlog中移出？他不是100%拥护Scrum的原则吗？(我认为这在Scrum master中是令人担忧的)

实现Scrum的大多数问题实际上只是Scrum过程暴露出来的团队或业务中的问题，例如，如果您的sprint被不可预见的支持问题抛出，这表明您没有分配足够的资源来支持