疲软的 Scrum

我最近听说不少项目都遇到了一种混乱的情况。情况是这样的：

• 他们想要使用敏捷流程，并选择了 Scrum
• 他们采用了 Scrum 实践，甚至可能还采用了其原则
• 一段时间后，由于代码库一团糟，进展缓慢

发生这种情况的原因是，他们没有足够重视软件的内部质量。如果你犯了这个错误，你很快就会发现你的生产力下降了，因为添加新功能比你想象的要困难得多。你背负了沉重的技术债务，你的 Scrum 已经变得步履蹒跚。（如果你参加过真正的 Scrum，你就会知道这是一件坏事。）

我之所以提到 Scrum，是因为当我们看到这个问题时，Scrum 似乎是团队遵循的指定流程中特别常见的一种。对许多人来说，Scrum 加剧了这种情况，因为 Scrum 是一种以项目管理技术为中心的流程，并且故意省略了任何技术实践，这与（例如）极限编程形成了对比。

为 Scrum 辩护，重要的是要指出，仅仅因为它没有在其范围内包含技术活动，并不应该让人们得出结论，认为它不认为这些活动很重要。每当我听杰出的 Scrum 实践者讲话时，他们总是强调，你必须有良好的技术实践才能使 Scrum 项目取得成功。他们没有规定应该采用哪些技术实践，但你的确需要它们。毕竟，项目总是会因为糟糕的内部质量而陷入困境，在 Scrum 的旗帜下出现大量问题，可能更多是由于 Scrum 目前非常流行，而不是 Scrum 本身的任何特殊原因。流行和语义扩散往往是相伴而生的。

那么该如何解决呢？

Scrum 社区需要加倍努力，确保人们理解强大的技术实践的重要性。当然，任何类型的项目评审都应该包括检查存在哪些技术实践。如果你参与或与这样的项目有关联，如果技术方面被忽视了，就要大声疾呼。

如果你正在考虑引入 Scrum，请确保你充分关注技术实践。我们倾向于应用许多来自极限编程的实践，而且它们非常适合。极限编程的实践者经常开玩笑说，Scrum 只是没有技术实践的极限编程，而技术实践才是使其发挥作用的关键。撇开嘲讽不谈，极限编程的实践是一个很好的起点，而且肯定比什么都不做要好得多。

我总是喜欢指出，成功或失败的不是方法论，而是团队。采用一种流程可以帮助团队提升水平，但最终重要的是团队，并且团队有责任做对他们有效的事情。我相信，许多疲软的 Scrum 项目的运行将会损害 Scrum 的声誉，也可能会损害更广泛的敏捷声誉。但由于我认为语义扩散是不可避免的，所以我并不感到过分担忧。失败的团队无论采用什么方法论都可能会失败，而成功的团队将会在好的想法的基础上建立他们的实践，而 Scrum 社区的职责就是广泛传播这些好的想法。

许多人将精益视为下一个重要的敏捷事物。但精益越流行，它就越会遇到 Scrum 现在面临的同类问题。这并不意味着精益（或 Scrum）毫无价值，它只是提醒我们，个体和互动比流程和工具更有价值。