精益如何“尽可能晚决定”和“尽可能快地交付”？

Question

我正在学习各种软件开发方法，而阅读关于精益的文章并没有澄清什么听起来像是两个相互矛盾的原则：

• 尽可能晚做决定
• 尽可能快地交付

第一项：

由于软件开发总是与某些不确定性相关联，因此应该采用基于集合或基于选项的方法来获得更好的结果，尽可能推迟决策，直到能够根据事实做出决定，而不是基于不确定的假设和预测。一个系统越复杂，就应该建立更多的变革能力，从而能够推迟作出重要和关键的承诺。

第二项：

在技术快速发展的时代，生存的不是最大的，而是最快的。最终产品越早交付而没有重大缺陷，就越早收到反馈，并将其合并到下一个迭代中。迭代越短，团队内的学习和沟通就越好。随着速度的加快，决定可能会被推迟。速度保证了客户当前需求的满足，而不是他们昨天所要求的。这让他们有机会推迟决定到底需要什么，直到他们获得更好的知识。客户重视快速交付高质量的产品。

从维基百科

一个实践精益方法的行业如何在建立完整的事实之前优先考虑决策，同时快速交付软件呢？

Answer 1

一个实践精益方法的行业如何在建立完整的事实之前优先考虑决策，同时快速交付软件呢？

，这不是矛盾

让我们直截了当地说一件事。不管决定被推迟了多少，不管项目交付得有多快，有一件事始终是正确的：

项目需求，以及来自它们的设计，总是建立在项目交付之前。

因为没有这些需求，您就无法做出设计决策，而没有这些决策，您就没有真正要交付的产品，也没有任何交付它的需求。

这似乎是同义的，很明显，但它也指出了您的论点中的缺陷，或者更确切地说，在推迟设计决策和缩短交付时间之间没有固有的矛盾。

在最后确定交付的需求之前，任何客户都不能期待产品的交付。在客户能够制定出具体的交付预期之前，他们必须首先提供可交付产品的需求。

开发人员的工作是将这些需求转化为预期的产品。设计决策具体发生在这段时间内，因为您的设计是将需求转换成具体的产品。

延迟决策

不要过早地做出设计决策是为了尽量减少在项目上花费的精力(假设一个相同的最终产品来进行比较)。

当客户在需求上改变主意时，只有他们最后的选择才是最重要的。因此，现在已经更改的构建之前的需求所花费的精力实际上被浪费掉了(部分或全部)。

把它想成这样:你在餐馆里点菜，你在和服务员说话，但是厨师可以听到你点的菜。

我想我要吃三文鱼千层面。但是再一次，牛排馅饼听起来也很不错，这可能是一个更好的选择。哦，等等，你供应龙虾？我都没看过。请给我龙虾。

如果那个厨师急于做一道菜，在你一提到它的时候就开始做它，而不是等到点菜结束(即服务员离开你的桌子)，那么厨师就会开始做鲑鱼面，然后是牛排馅饼，然后是龙虾。鲑鱼千层面和牛排馅饼会被浪费掉，因为你不再想要这些东西了。

通过推迟决策，可以将浪费在最终规范中的需求上的精力降到最低。

你可以说，客户应该只订购他们想要的东西，但这不是很好的客户服务，客户不喜欢被告知该做什么，即使他们认为自己知道自己想要什么，他们可能忘记了一些事情，说错了话，或者当他们收到最初订单时没有的新信息时，他们就会做出新的决定。

您可以争辩说，早期启动仍然有助于您更快地交付，因为旧需求的部分可以用于新需求，与从头构建新需求相比可以节省一些时间。虽然这当然是可能的，但这是一场赌博，因为当你只有旧的需求继续下去时，你无法猜测未来的需求可能是什么。

仅仅因为某件事情最终成功，并不意味着这是一个明智的决定开始。在你可能需要的机会上建造东西就是赌博。这并不意味着你不能幸运地猜出正确的结果，但也不能使它成为一个明智的决定。

加速交货

你送东西越快越好。我不认为我需要详细说明这一点。

但我想在这里指出，推迟您的设计决策实际上可能有助于缩短交付时间。

我们谈到了当厨师开始做千层面和牛排馅饼时浪费掉的食物。但另一件要考虑的是，厨房工作人员现在也必须清理这些浪费的盘子，即洗千层面，清洗牛排刀，……这对他们快速提供龙虾餐的能力产生了负面影响。

在编程方面，必须回滚不再有效的实现也需要付出努力，而更多的努力意味着需要更多的时间来交付。当客户在某一特定特性上改变主意时，必须回滚该特定特性，并需要开发其替换功能。但是这会触发整个重构链，如果这个特性导致了一个设计决策，而这个决定现在已经不再有效了，因为特性本身已经被废弃了。

这种重构链是常见的吗？这取决于对需求所做更改的大小，以及代码库的整洁程度。对于小的更改和/或干净的代码基，影响通常是最小化的。对于大型更改和/或脏代码基，影响通常更大。

Answer 2

你为什么会看到这两种说法之间的冲突？延迟决策有助于快速交付和快速交付，使团队在推迟决策时感到更容易接受。

让我们用两个例子来展示它：

1. 你必须开发一个复杂的搜索功能。您担心搜索效率很低，所以您有一些想法:构建专门的预测、使用缓存、进行非常精细的谷物优化。所有这些都会减缓你的发展，同时也会帮助你取得最好的成绩。重点是:你需要表演吗？为了知道答案，您应该确切地知道您的查询应该详细说明的数据量，用户使用此功能的频率，这是实际工作负载下的实际性能，以及用户的期望是什么。

结果:结果表明，预先决定使用这些技术是不值得的。如果您有一个可观察的平台，您可以发布一些运行良好的信息，收集度量和警报，并在正确的约束下做出正确的决定。

1. 你掌握了那种快节奏的思维方式。您构建了帮助进行30个生产部署的自动化管道，您已经开发了一个新特性，但仍然需要一些时间进行重构。为什么不直接发布未重构的代码，然后开始改进代码呢？至少您可以利用反馈，因为您知道已经部署和测试的代码可以工作，并且被客户认为是有价值的，因此值得投资于降低技术债务。

这里的另一面是应用一种“微精益”的方法，开发人员逃避每一个决定，甚至是最明显的。太糟糕了，理解平衡是一门非常复杂的艺术。

Answer 3

我想在骆驼的回答上面加上一点，那就是：

• 尽可能晚做决定，并不意味着拖延或推迟。当你准备好做决定的时候，做出决定。但是，当元素丢失时，如果您仍然可以提前，请稍后决定。
• 这甚至有一个经济概念(期权估值)。以商店里的一台电脑为例:一旦你买了它，它就立刻失去了它市场价值的很大一部分；如果第二天你决定转售它，即使你不打开它，你也永远无法收回它的全部价格。当然，如果你确定你的选择，这不是一个问题。但如果你犹豫不决，如果你真的不需要电脑，这可能是错误的，如果第二天，一个更强大的型号，以同样的价格。
• “尽可能晚”，意为“但不晚”。
• 越快越好并不意味着要送垃圾。你需要提供高质量的服务。但这并不意味着所有的决定都需要完成。如果您不确定用户是否很喜欢该功能的当前形式，您就不需要决定如何改进新功能的性能。
• 而且，交付快，意味着更频繁地减少不确定性。这将为决策提供便利。一个真实的循环;-)
• 在实践中，大多数早期的不确定性将迅速减少，留下较少的不确定决策。但当然，这是一种平衡的行为:如果你的进步被一个不确定的决定所阻碍，你就必须做到这一点，即使所有的事实都不存在。