关于 Scrum 和真正的敏捷性

Scrum 是一种迭代式软件开发框架，自称是敏捷开发，以 Scrum 联盟发布的流程为基础。其流程图如下：

我们中的许多人都看到了软件开发团队中的认证 Scrum Master 所留下的灾难，他们在很大程度上将敏捷作为一个流行语，来提供一些简单无趣的软件编写流程。

敏捷宣言的出发点是 "个人和互动"，而不是 "流程和工具"。Scrum 是一种流程，而且是一种严格定义的流程。在实施 Scrum 的过程中，开发流程往往比团队更受重视。如果要从本节中得到什么启示，请记住 "人重于流程 "这句话。如果你选择实施 Scrum，就必须愿意适应和改变其流程，以应对变化。

敏捷的全部意义在于敏捷；我们希望迅速适应不断变化的需求。我们要的是灵活性，而不是限制我们适应快速变化需求的严格定义的流程。

填写考勤表、采购订单以及处理官僚主义的管理流程无助于将软件交到客户手中，因此，如果不能将软件交到客户手中，就必须尽可能地简化流程。

考勤表是一种完全浪费的完美想法。它们只是用来监控开发人员的工作表现，尽管有些管理层会假装它们具有某种神奇的敏捷优势。当然，无论从哪个角度看，它们都不会帮助你做出更好的软件估算；敏捷环境应寻求使用预测而非预估。

我见过一些 Scrum 指导员，他们无休止地重复着这样一句话：没有一个作战计划能在与敌人的接触中幸存下来；与此同时，他们还在执行僵化的预测计划。

在现实世界中，准确预测是一个矛盾体。你不可能对不确定的事情进行准确预测，而且几乎在所有情况下，开发人员都不会对他们正在处理的系统有足够的了解。此外，他们也不知道自己每天的工作效率，因此无法准确预测。

我甚至遇到过通过严格的纪律程序来执行这些严格预测（通常甚至不是开发人员自己做出的）的环境。

通过将问题分成小块并加以解决来降低复杂性是一种很好的做法；将庞大的程序员团队缩减为更小的团队也是一种很好的做法。

在开发人员在这些小团队（通常称为部落）中构建的系统之间，通常需要一个系统架构师来确保团队之间的一致性。

Spotify 使用这种部落架构来开发软件；事实上，我强烈推荐阅读 Henrik Kniberg 和 Anders Ivarsson 撰写的论文《Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds》。

这种系统架构师可确保所构建的所有不同服务之间的一致性。

具体到 Scrum，Scrum 是一种敏捷流程。Scrum 指南（是的，它甚至是一个商标）在一份 16 页的文件中定义了 Scrum 的规则。

然而，敏捷包含许多不同的流程和许多其他方法论；敏捷是一个非常广泛的知识库。

Scrum Master 喜欢把敏捷当作是在一个开发团队的孤立环境中进行的。这与事实相去甚远；整个组织结构都与 Scrum 息息相关。

极限编程（XP）是一个非常宽泛的过程，人们对这些过程之间的相互作用有了大致的了解。如果对这些流程挑三拣四，最终只能得到一个无效的流程；这就是 Scrum 举步维艰的原因。

需求会改变，包括在 Sprint 中期改变。当 Scrum Master 坚持在 Sprint 开始后不做任何更改时，团队就无法有效地应对真正的变化。

在敏捷机制下进行开发时，我们必须记住，我们的软件必须有足够的弹性，以应对不断变化的需求（导致不断变化的软件设计）。你的软件架构必须能够应对变化带来的压力。因此，开发人员也必须了解并参与实现软件弹性所需的技术流程，以应对变化的步伐。

不能灵活应对变化的公司不如那些能够灵活应对变化的公司有效；因此，它们在商业世界中具有明显的优势。在选择公司时，公司的敏捷性不仅关系到你的工作质量，而且对你的工作保障也至关重要。

我在这里要传达的信息很简单：在实施流程时，要认真对待技术实践，切记不要盲目追随猥琐的流程，否则会损害整个企业的利益。

开发人员不应该被当成孩子。如果他们不会写代码或写的代码不好，就不能继续受雇于开发人员。

从本质上讲，为了管理风险，最好先查看积压工作，利用历史进度来预测项目的进展情况。管理者的职责应该是扫除阻碍开发人员开展工作的障碍。

最后，如果你的团队里有一位对软件开发（以及敏捷开发）理解很差的 Scrum Master，那么你要强烈提醒他们，人必须高于流程，真正的敏捷性需要代码能够承受变化带来的压力。

Scrum Master 有时会认为，敏捷意味着没有前期设计。这是不对的，敏捷意味着没有大的前期设计。