团队是否应该采用分离的工作节奏？

最近，Twitter 上掀起了一场有关团队是否应该采取分离工作节奏的讨论，比如，工作计划和学习改进是否可以采用不同的节奏。分离的工作节奏可以让团队找到适合自己的工作方式，具有更大的灵活性和自主性，也会带来更好的产出。

第一条推文来自 Matt Barcomb：

Barcomb：如果你已经有成型的 MVP（最小化可行产品）或者知道如何安排工作优先级，那么就没必要进行 Sprint 计划（或者是制定 Sprint 目标）。

Ron Jeffries 引用 Barcomb 的推文，说：

Jeffries：如果你想提高可预测性、缩短产品生命周期或加强沟通……那么分离的工作节奏或者说计划性的东西才会体现它们的作用……

在后续的讨论中，Barcomb 建议让团队采用分离的工作节奏，而 Jeffries 一直在质疑：

Barcomb：一般来说，我们会推荐计划和改进这两个部分使用同一个节奏。不过，我还是建议要把它们分开来实施。

Jeffries：为什么要分开？定期进行计划，并在同一时间评审完成进度不是很好吗？

Barcomb：让我感到很疑惑的地方，就是当团队需要一个自省通道时，却感觉（或者被告知）他们不能这么做，因为那不是 Scrum。

Jeffries：为什么有人需要不一样的工作节奏？是因为它比 Sprint 慢？到底是为什么？

接下来，John Cutler 加入了讨论。他给出了几个为什么需要分离工作节奏的理由：

Culter：

客户反馈闭环

交付闭环

集成闭环

分解工作

自省闭环

目标设定闭环

如果能够以一种节奏做完这些事情或许会更好，但通常不是这样的。它们有些是即时性的，有些需要长一点时间，有些则短一些。

Matt Heuser 也发了推文，例举了一个采用分离工作节奏的公司的例子：

Heusser：我可以以一家位于印第安纳州的公司为例，他们就成功采用了分离的工作节奏。我可以在下次的 Agile&Beyond 大会上分享。

InfoQ 采访了 Matt Barcomb、John Cutler 和 Matt Heusser，讨论了分离工作节奏以及它会为我们带来哪些好处。

InfoQ：计划和改进采用同一个节奏有哪些优势和不足？

Matt Barcomb：首先要说明的是，问题不在于是否要让计划和改进采用同一个节奏，而在于是否允许团队把它们分开实施。我经常看到团队因为“Scrum”而只采用了一个节奏。

不允许分离节奏的劣势在于，它会降低团队的自主性，导致不好的产出。所以，如果能反其道而行之，它就会变成优势。

在现实当中，我也看到一些例子，因为团队无法实施分离的工作节奏，导致下列情况的发生：

1. 做了太多的计划，有些只是“Sprint 层面”的任务。
2. 糟糕的计划和产出。
3. 没有适当控制好改进速度，团队无法应对所有的变更。
4. 忘记了改进想法，延误了必要的改进。
5. 没有考虑周全各种角色和各个级别的改进。

当然，除了上述这些，还有其他的一些因素。而且，即使只采用了一种节奏，我们仍然有办法解决上述的一些问题。不过，分离工作节奏可以让团队有机会找到更适合他们的工作方式，通常情况下，这样会帮助他们达成更好的目标。

John Cutler：团队经常以便利为理由将计划和改进耦合在一起，他们倾向于在一次会议中把所有的事情都做完。另外，自省通常是围绕着“成功”的计划而进行。通过这种节奏的耦合，团队可以确保他们所了解到的内容是“最新”的。

当然，这里也存在一些潜在的不足。比如，团队在这一过程中能够理解到的变更是很有限的。经常性的自省变成了日常的杂务，同时也在消耗着团队的精力，导致他们逐渐失去热情。与此同时，两周一次的计划会降低它的实际作用。“一篮子解决问题”的方式无法让团队更好地满足特定需求。

Matt Heusser：耦合的好处就是简单，而且可以实现实实在在的改进。有太多的公司忙于生产业务，没有太多时间用在计划和改进上。即使有，他们也不会把得出的结论应用到下一个项目当中。我曾经工作过的一个公司沉迷于两义性（ambiguity）的评审风格，项目经理手里拿着一个检查清单，说：“从现在开始，所有的项目都需要进行两义性的评审！”但我从来没见过有哪个团队在使用这种方式。而有了 Sprint 的概念，你就有了明确的开始时间和明确的结束时间，并考虑接下来该做些什么。

在 Customize Your Agile Approach: Select Your Agile Approach That Fits Your Context 这篇文章中，Johanna Rothman 探讨了如何自定义敏捷方法，并设计出一种集交付、计划和反馈为一体的工作节奏，可以用在实际的产品、项目或团队中：

每个团队都是不一样的，所以每个团队都需要有自己的敏捷方法。有些团队可以使用现成的框架，如 Scrum、XP 或 Kanban。不过，从我的经验来看，大多数团队需要根据实际情况自定义敏捷……或许你所处的环境可能需要集计划、演示和发布为一体的工作节奏。但你的团队可能会发现这样的节奏其实不会奏效。

InfoQ：在什么情况下你们会建议采用分离的工作节奏？

Cutler：我建议在团队遇到信息流瓶颈或感觉到能量不匹配时采用分离的工作节奏。比如，想象一下两周一次的 Sprint 到达尾声的时候，事情已经偏离了正轨，但没有人能确切地说出问题的“根源”是什么，因为有用的信息已经缺失了。而此时，我们的看板已经达到了 EIP（进行中的实验）限制。很多在进行中的持续改进都是有意义的，但我们却还没准备好去完成之前作出的承若。

在这种情况下，我们或许可以尝试进行节奏分离。我们可以缩短 Sprint 时间，也可以看情况进行进行 15 分钟的自省，或者每两周进行一次短时间的自省，每个月进行一次深度自省。

Barcomb：我会建议给团队足够的自由度，让他们自由进行节奏分离。我听到有些人说，刚开始采用敏捷方法的团队应该耦合他们的工作节奏（也就是“进行 Scrum”），因为分离的节奏对于一些新敏捷团队来说是一种无法掌握的“高级”技术。

就个人而言，我觉得不是这样的。在与新的敏捷团队一起工作时，我并不会特意去鼓励或者阻止他们使用耦合的节奏。我觉得我们应该帮助团队去发现适合他们的工作方式以及怎样的工作节奏有助于这些工作方式。我不觉得这是什么神秘的高级技术。有些团队已经在这么做了，然后有人跑过来告诉他们说“那不是敏捷”。说实话，分离节奏不会比小孩的日常杂务难多少。

Heusser：如果改进工作已经在进行中，而且团队擅长设计实验，那么就没有必要与计划保持同样的节奏——它完全可以根据实际需要即时进行。在我看来，实时的决策对技能有更多的要求。所以，我会建议使用多种计划时间窗口，Sprint 只是其中的一种。就像棒球赛那样，我们可以进行单次、一局、一场、一个赛季或一整年的计划。

我的策略是在计划和改进出现混乱时才增加 Sprint，然后在走上正轨或者具备了可预测的交付流程时再把它们去掉。我之前在一个印第安纳州之外的公司工作，在我之前，Matt Barcomb 也在那里。他们获得了长久稳定的成功。我们当时所做的就是即时 (Just In Time）的自省。如果有需要讨论的事情，我们就在看板上放上粉色的卡片，如果集齐五张卡片，我们就进行一次自省。我们放一张红色卡片在粉色卡片的前面，用来安排自省。

InfoQ：分离的工作节奏会给我们带来什么好处？

Heusser：在该做事情的时候就去做，而不是死板地照着某种计划安排来，这样才会带来更好的产出。当然，这也要求更复杂的技能——做出决策总是比遵循指示要困难得多。

Barcomb：分离的工作节奏最终会带来适应性和自主性。如果团队认为耦合的节奏更适合他们，那么就这样去做，没什么问题！如果他们没有其他更好的方式，完全可以试着这么做！但不能强制他们总是使用同一种的方式，因为这种方式在某个时候可能变得毫无意义，他们应该有权利决定以何种方式来达成目标。

Cutler：分离的节奏适用于多元化的认知、团队的工作风格、信息流、处理信息的能力和复杂工作的可变性。认为人类可以在同一种节奏中处理不同类型的工作，这样的想法有点幼稚。不过，如果有人说所有事情都可以即时进行，我也会站出来反对，因为这种观点太过自以为是了。试想一下，如果有些团队成员在周末时紧闭大脑不想进行任何思考，那该怎么办？

查看英文原文： Should Teams Decouple Cadences?