化学专业尽早转行_早晚：尽早交付或减少浪费

化学专业尽早转行

在何时进行决策时，精益/敏捷开发存在明显但重要的紧张关系。 在我们应该首先进行最重要和最冒险的工作的基本敏捷立场与精益论证之间，我们应该在最后可能的时刻做出决定。 我们需要尽早做出决定并进行尝试，进行迭代以最大程度地降低风险和上市时间。 但是我们应该推迟决策，避免重复进行以降低成本。

迟总比早好

精益开发说，为了避免浪费，我们应该等待尽可能晚的做出决定 ，尤其是当我们认为赌注可能很高时。 您做出决定的时间越晚，掌握的更多信息将有助于您做出决定，并且您将需要选择更多的选择。 这意味着您应该能够做出更好的质量决策。

递延决策内置于增量/迭代计划和管理中。 您不要试图预见所有事情。 您无需一开始就解决所有细节和依赖关系以及资源配置问题。 取而代之的是，您勾勒出计划大纲，其中包含您所知道的所有关键依赖性和里程碑，然后着眼于前进的方向。 当您准备好及时进行工作时，将制定有关计划，实施和重新优先级的详细决策。

决定以后花费更少

迈克·科恩（Mike Cohn）在《 敏捷估算与规划 》中说： “降低变更成本的最佳方法是尽可能快地实施某个功能–在没有更多变更时间的情况下有效。” 因为您要推迟工作到以后，所以出现新信息并迫使您更改已经决定的内容的可能性较小。 拖延症是有偿的，或者至少可以节省一些时间和金钱。

在您不了解所需要做的事情，需要做的事情或者甚至确实需要做的事情之前，您不想花很多精力。 首先构建原型或运行技术峰值，首先构建东西，然后再构建第二件事，并让客户使用它，获得反馈，并确保您在进行更多键入之前对自己的工作有很好的了解。 这是很好的常识。

还有其他您可以推迟的工作，因为您不必担心它–您必须这样做，但是您知道需要做什么并且知道自己可以做到。 您最好等到先充实系统的更多内容后，才能快速完成它。

您何时应该尽早决定呢？

您可以负担得起的安全工作大部分是显而易见的。 而且，以后无法推迟的工作也很明显，例如弄清楚基本体系结构，要使用的平台和语言，要遵循的基本方法，证明自己的核心想法。 这些是您需要尽早做出的决定，尽管仍有很多时间需要学习，并且仍有时间改变主意并根据需要重新开始。

这就是为什么我对迈克·科恩（Mike Cohn）在他的书中使用的示例感到惊讶的原因： “今天增加对国际化的支持可能需要四个星期的时间； 在六个月内添加它可能需要六个星期。 所以我们现在应该添加它，对吧？ 也许。 假设我们花了四个星期，现在就做。 在接下来的六个月中，我们可能会花六个多月的时间，根据在六个月内获得的知识来更改原始实施。 在这种情况下，我们最好等待。 或者，如果我们现在花了四个星期，后来又发现更简单，更快的实施就足够了呢？” 但是国际化是一个贯穿各领域的问题 。

这类工作通常比您想要或想做的要难得多，对设计和代码的影响比您预期的要多。 您是否真的要等待六个月，才能发现必须更改为同时处理LTR和RTL语言而开发的所有表格和报告，或者适当地安排日语和汉字的布局？ 我已经与国际化专家一起工作了数周，他们只是试图理解和解决在阿拉伯语名称中打上尊敬标记的问题（这是一件小事，但如果您使用的是中东皇室，那是一个杀手er）。

其他横切关注点可能需要更多，更基本，更昂贵的更改才能在以后实施，而这些更改很难正确测试且难以测试：数据验证，安全性，监视和检测，缓存，日志记录，错误处理，持久性。 与尝试“在以后添加”相比，从一开始就了解这一点并从一开始就对其进行支持，其风险和成本就会大大降低。

如有疑问，早日胜于晚

尽早做出决定意味着您可能会犯错，并且您将不得不放弃一些工作，并且当您获得更多信息时，您将不得不稍后进行更改。 所有这些都是浪费。

在计划细节时，按时推迟决策很有意义。 但是，在设计和实施系统的重要部分时，尤其是技术管道和跨领域工作时，尽早做总是比以后做得更好。 预先管理风险将最终为您节省更多的钱。

参考： 迟早：在Building Real Software博客上， 尽早从JCG合作伙伴 Jim Bird 交付或尽量减少浪费 。

翻译自: https://www.javacodegeeks.com/2012/06/sooner-or-later-deliver-early-or.html

化学专业尽早转行