不知你的Scrum问题在哪？看Ron Jeffries怎么说

疫情后每天都会在网上读一些博客，有几位的文章我是每发必读的，Ron Jeffries就是其中之一。今天Ron发了一篇题为 “Gotta Be Good” 的博文，解释了Scrum为何在一些团队有雷声大雨点小的问题，揭示了Scrum的成功依赖于Scrum仪式外的团队实践和能力。他“频繁多做” 的建议给开发人员和敏捷团队指出了在敏捷环境下的成长之路。今天花了些时间把其中核心内容翻译了一下，分享给大家，希望对正在摸索适合自己敏捷模式的软件人有所启发。

下面是Jeffries文章的节译：

Scrum，可以说是当今最流行、逼死人节奏的软件开发模式，除非你更认可更致命的 SAFe。它要求团队每个“Sprint” 都交付一个工作的增量软件功能，间隔是一至两周，如果你真的很差劲，那四周也凑合。

这是个循环重复的迭代过程：计划，做，发布，……

产品是增量构建的，如：构建功能 A，然后是 A+B，然后是 A+B+C，诸如此类。

你每一周或两周都要加一些 A 和 B 和 C。

我应该没说过这是件容易的事，万一说过，我现在立马道歉。因为这真的不容易，我们需要做不少困难的事，如：

-让设计从简单逐步演变，使之越来越强；

-不间断地测试所有软件，因为设计的变化有破坏力；

-添加微小的切片一样的功能，因为真的很难在一两周内完成一个大功能；

-每周多次甚至每天多次的系统构建必须常态化，这样才能确保每周结束时交付工作的功能。

我肯定可以把这份清单做得更详细，但这些已经够难了，这不容易！不容易！

设计的不断优化需要我们能够做好重构，我们不可能每两周重写一次设计，而是自然地对其进行变异、增加、扩展，并保持它是一个“好”的设计。这不容易！

要做到这一点，我们必须知道什么是好的设计，以及如何将烂设计改好。这不容易！

做到程序随时可测并保证其正确，测试必须自动化，因为没有人希望整栋建筑都挤满了敲击钥匙（键盘）的人来测试代码，所以必须提供必要的测试以及运行的pipeline，这不容易！

我们必须弄清楚如何将大功能分解成一系列有意义的部分，以显示每周的进展，这需要具备非常强的设计感，以及以简单的小步骤处理复杂事物的能力，这不容易！

做到每天多次构建系统，我们需要有强大的工具和熟练使用它们的能力，同时必须持续专注如何让构建/测试周期快上加快，这不容易！

显然我们的团队应该具备必要的知识和技能来完成上述工作，还有十倍或百倍以上的其他工作等着我们，所以每个开发人员都需要具备其中一些技能。

每个开发人员都能够构建带有测试的软件，让测试与系统的能力一致。

每个开发人员都能够从一个小设计开始，不断演变，让它成为一个好的设计。这也意味着每个开发人员需要知道什么是好的设计，以及什么让设计变得不那么好。

每个开发人员都需要知道如何平稳地更改设计，避免大量的重写导致项目停滞不前，他们需要知道如何做好重构。

至少团队需要一些开发人员需要具备专业领域的技能，包括 CI/CD 管道、配置 IDE 和其他工具、找出构建无法在某台机器上运行的原因等等。

团队大多数开发人员需要能够将产品经理和客户给出的模糊且经常相互矛盾的想法转化为有意义的功能，然后将这些功能切得足够小，使它们能够被顺利构建，保证团队每周都可以交付新的功能。

这真的不容易！对于我们这些多年来一直这样做的人来说，这都不是一件容易的事，我们只是学会了如何能让事情变得容易些，其实最重要的技巧就是频繁地做这些事情，这样做可以达到两个效果。

首先，如果你经常做某事，几乎可以保证它会成为你的擅长。如果能做到专注，你会发现一些有用的东西，一些没用的东西，最终你会让线进入针眼。

其次，如果我们经常做某事，往往会因为做这件事的间隔短，事情会变得更容易。如果你和我在各自独立分支上工作一两周，然后再去合并，合并时可能会出现冲突，甚至是很严重的冲突。

如果我们在团队定这样一条规则，遇到合并冲突的人必须修复它，那么我所要做的就是在你做之前先合并（就像“跑得比你快，而不是比熊快。”）。当然你也知道这个策略，所以你想在我之前合并。

由于我们肯定有这样一条规则，不能发布有测试问题的版本，因此每次测试运行时我们都会争着去合并。很快每隔几分钟就会有一次合并。哇，我们发明了Trunk-Based Development，很少再遇到合并冲突了。

所以，虽然这不容易，但做得越多就越容易，而且会做得越好。

我多年来一直在写关于如何更擅长做这些事情的文章，这些文章揭示了我们可以通过相对简单的小步骤不断向上走，最终征服一座高的山峰。

这不容易！但通过学习和实践它们会变得更容易，学习和实践可以是非常有意思的事。