敏捷产品是双轨开发而非双轨制

长话短说：

如果你以前听说过“双轨开发”这个术语，本文将解释它的来源和含义。以下是要点

• 开发工作侧重于可预测的结果和可保证的质量

• 探索工作侧重于快速学习和快速验证

• 探索和发展被可视化为两条轨道，因为这是两种工作，两种思维

• 探索是产品开发的必要组成部分。同样地用敏捷和精益原则来实践它

• 如果我们正确地进行发现，我们就会大大改变并扼杀很多想法

• 虽然产品经理、设计师和高级工程师可以领导和协调探索，但他们必须尽可能让整个团队参与探索任务。让整个团队都能看到探索的工作和进展。

• 即使在交付后度量和学习也是不能停滞的。

现在，如果有人问您这篇文章是关于什么的，你无需阅读接下来的 1,500 个字即可回答他们。

没有人真正将其命名为双轨

几年前，我和朋友 Marty Cargan 一同授课。这实际上只是我的和他的东西在三天的课程中组合在一起。但是，在我的教学部分中，我提出了一个模型，我通常在谈论敏捷思维和产品思维如何在同一流程中协同工作时展示该模型。该模型看起来有点像这样：

我手绘了自己的模型版本，所以它看起来并不完全像这样。但是，Marty 问我这个模型是从哪里来的。我打开了 Desiree Sy(发音为 See)的原始论文《调整可用性调查以实现敏捷的以用户为中心的设计》。

Desiree 在她 2007 年的文章描述了一种常见模式，许多在敏捷开发中进行严格设计和验证工作的人已经达到了这种模式。因为，这确实是这些东西发挥作用的唯一方式。当时，Desiree 正在与 Alias(现在是 Autodesk 公司)合作，她和同事们的合作非常顺利。他们正在做当时大多数人认为介于超级困难和不可能之间的事情。但是，对他们来说，这似乎很自然。这并不容易，但它确实有效。

Marty 问我“这个模型叫什么名字？”

“它其实没有名字。”我说。“这就是它的运用方法。”

“怎么称呼它？”Marty 问道。

我们扫描了论文，发现了这样一段话：

如果我提取重要的部分，是这样说的

“……我们通过设计和开发与开发人员密切合作。双轨看似分开，但实际上，设计师每天都需要与开发人员进行沟通。”

就这样。Marty 开始在对产品经理的教学中使用这个术语。由于我经常为同一群人教学，所以我也开始使用这个术语。渐渐地，其他人也开始使用这个词。

现在我需要告诉你我讨厌这个词，原因如下。

这是双轨，而不是决斗轨道

人们就是不愿意读书。读到这里真是一个奇迹。恭喜。

但人们确实喜欢图片。双轨制的图景似乎为不同的人提供了不同的工作——比如产品经理和设计师弄清楚要构建什么，然后由开发人员来实施构建。在最糟糕的情况下，你可以理解为开发人员需要等待数周才能拿到产品经理和设计师的不知所谓的设计结果。事情不应该是这样的。如果整个团队是要对产品的成功负责，而不仅仅是构建产品，那么整个团队都需要理解并同时为这两种工作做出贡献。

我想要一个不同的术语和不同的图片。但是，我现在没有更好的术语或图片。不过我会尝试再画几张图来补充这张图。

在这两个类型的工作中，开发工作是绕不过去的

开发工作

如果你以前从事过敏捷开发，就会知道团队会经常谈论速度。但他们所说的速度是开发速度。团队对自己的可预测性感到苦恼。在 Sprint 开始时，他们会估计速度，并在结束时测量速度。理想情况下，他们的预测是准确的。

当你交付高质量的产品时，质量非常重要。如果我们将软件投入生产，质量、可扩展性、性能、本地化和许多其他问题都很重要。因此，已完成的开发工作应该经由构建、测试和他人的评审，来打理所有这些问题。敏捷团队会谈论很多关于“潜在可交付的软件”的话题，这实际上意味着产品可能还没有构建到足够可交付的程度，但一旦条件满足，质量就足够高，他们可以自信地交付它。

开发工作侧重于可预测的结果和可保证的质量

探索工作

软件开发以及所有产品开发的悲剧之一是我们构建的大部分内容都没有成功。它没有带来我们所期望的好处。所以，这是一个问题。但是，即使在此之前，也需要一些时间来充分了解我们正在解决的问题，以便就我们应该构建什么做出正确的决策。我们利用探索工作来完成这一切。回答问题，测试想法，并尽可能避免浪费时间过度投资于我们本来就不应该构建的所谓优质产品。

我们希望尽可能快速、廉价且安全地学习。因此，速度在发现过程中也很重要——但这是指学习速度。

探索工作侧重于快速学习和验证

因为目标是学习，而不是工作软件，所以发现学习循环看起来有点像这样：

它首先描述：

• 我们所相信的是我们正在解决的问题以及为谁解决的问题

• 我们为解决这个问题而构建的解决方案

• 我们如何度量成功

这是我们的赌注，我们的最佳猜测，我们的信念，我们的假设。对于那些相信自己正在构建正确事物的人来说，所有这些都是令人不安的话语。但事实是，我们总是打赌我们会获得价值。这个赌注包含了很多假设、风险，也许还有一些问题。为了集中学习，我们将选择最让我们害怕的假设、风险或问题，并确定一个实验或学习方法。然后就去做吧。然后利用我们所学到的知识来改变所有关于问题和解决方案的固有信念。

遗憾的是，最耗时且最昂贵的学习方法之一是构建潜在的可交付软件。所以我们不会这么做——除非我们真的想不出任何其他的学习方法，或者我们确信我们的赌注是好的。请记住，我们并不是打赌说我们能够按时建成它。我们打赌人们遇到了我们正在解决的问题，并且会很乐意尝试、使用和采用我们的解决方案。

要测试你的想法，最昂贵的方法是构建生产质量的软件

这就是学习循环的运作方式。关于它，您应该了解一些事情。

我们尽可能快地完成这一切。如果可能的话，在几个小时内。有时可能需要几天时间。但是，我们希望这不需要几周的时间。因此，许多探索学习循环应该适合典型的两周冲刺。

探索工作常常会导致创意被扼杀。在每次测试结束时，你都需要做出决定：构建它、终止它还是继续学习。是的，我在这里真正想说的是发现工作可以而且应该导致扼杀想法。并非一切都会向前发展。这可能会让一些人感到非常不舒服。

我们对探索周期进行时间限制。为了防止探索成本的流失，我们会将测试或实验的时间限制在几个小时到几天之间。

我们无法预测接下来需要学习什么——这并不容易。当我们学到一些真正有价值的东西时，它往往会真正改变我们的信念，并真正改变我们下一个最大的假设或问题。这种混乱有时会让人难以承受。

发现循环有点像这样连接在一起：

到目前为止，我们应该清楚开发和探索工作都至关重要。但你处理工作的思维方式和工作流程却截然不同。

好吧，这确实是 3 种工作……

要真正开始构建可工作的软件，你需要做出很多战术设计决策。这些可能不是需要验证的冒险决策，但仍然需要做出决定。设计人员通常需要在开发之前花时间来完善和完成设计工作，为编写代码做准备。

如果你已经验证该产品值得构建，那么可能需要在编写代码之前完成一些详细的设计工作

这一切都是同时发生的

如果我们都能专注于探索工作，完成它，然后将重点转移到战术设计和开发上，那就太酷了。如果所有团队成员都拥有相同的技能，那么这种方法就可以发挥作用。但由于有些人擅长编写代码，有些人擅长用户体验设计，还有一些人擅长其他各种事情，所以我们有机会同时做多种工作。那我们就这么做。

探索工作与开发工作同时持续进行。

这几天我把连体模型画得有点像这样。

探索工作使用不规则的周期长度。它是“精益”的，因为我们试图使发现周期尽可能短。发现过程中的想法会发生变化，并且经常被抛弃。最好的进展是进入更审慎的开发周期。我不知道如何在一张图中展示所有这些东西。但是，我正在尝试上面的一项。

探索和发展分为两条轨道，因为它们是两种工作，两种思维

两条赛道，而不是两支球队

但是，你不应该将其视为两个过程——只是一个过程的两个部分。而且，我认为你不让开发人员和团队中的其他人参与探索工作，你就是看不起他们。

通常有足够多的探索工作要做，并且有很多方法让整个团队参与其中。如果您感到有压力需要缩短探索工作以“喂养野兽”，这通常意味着您在学习足够多的知识以确信自己应该这样做之前就做出了构建软件的决定。在最好的情况下，结果是不确定的，而且通常结果很糟糕。

整个团队对产品成果负责，而不仅仅是按时交付

打破双轨神话

让我再次指出人们对该模型的最大误解。

误区：探索是敏捷开发之前的一个过程。不应该。

探索是产品开发的必要组成部分。牢记同样的敏捷和精益原则来实践它。

误区：所有工作都是从探索到开发。事实并非如此。

如果我们正确地进行探索，我们就会大大改变并扼杀很多想法。

误区：探索团队与开发团队不同。不应该的。

虽然产品经理、设计师和高级工程师可以领导和协调发现，但他们必须尽可能让整个团队参与发现任务。让整个团队都能看到探索工作和进展。

误区：一旦从探索转向开发，探索工作就完成了。不是的。

这种误解让我的朋友 Jeff Gothelf 非常烦恼。他将我们构建的生产质量软件视为我们直到最后才要采取并实施的最佳实验。

即使在交付后，度量和学习也是不能停滞的。

从 Jeff Gothelf 的角度来看，一切都是探索，我们从所做的一切中学习；无论是纸质原型，还是生产软件中的下一个功能。我同意他的观点。

这个故事还有很多内容

我已经从概念上讨论了探索和开发工作是什么，以及为什么将它们结合在同一流程中。但是，我很少谈到如何在实践中做到这一点。你应该感到有点不满意。我很抱歉。

这是我正在撰写的系列文章中的第一篇文章。后续文章将涵盖：

• 如何在 Scrum 等敏捷流程中保持发现可见性

• 如何调整敏捷计划会议、站会和评审会议，使它们同时关注发现和开发

• 如何充满信心地思考下一个最佳实验并扩大发现投资

作者：Jeff Patton

译者：周菲(Fei Zhou)&Toby

专业认证：CSM，A-CSM，CSP-SM

致谢

本篇译文来自 ShineScrum 捷行译社翻译，未经许可不得私自转载。

原文链接：https://jpattonassociates.com/dual-track-development/