我在听播客。在他们谈论丰田使用的原则的地方：

Never do anything until you are ready to use it.

我认为这告诉我们要去其他地方看看，以了解多年来已知的其他做法。

解决方案

像这样思考是一种很好的敏捷实践。还有一种叫做"测试驱动开发"的东西，它可以(几乎)没有缺陷地获得软件，但是还具有副作用，即实现了我们不使用的NOTHING。

一个示例是我们自己的集合类。如果只需要一个Add方法和一个ToArray方法，那么为什么要花时间实现Remove和Count方法呢？

是的遵循该原则:)

是的，是的。这是敏捷哲学的核心部分。

基本上，相对于大型设计和笨拙的规格，更倾向于灵活性和响应速度。最好的方法之一是仅构建足以满足我们当前要求的内容，因为我们永远不知道它们何时会更改。

有点老新闻了。它通常被称为"我们将不需要它"(非偶语英语中的" You Arent'Going to Need It")，并缩写为YAGNI。

不需要功能时与实现功能相关的问题：

• 实现需要花费时间来开发所需的功能
• 很难记录和测试该功能，因为如果我们不需要它，谁知道它应该做什么呢？
• 维护功能将花费更多时间
• 该功能增加了额外的代码，使代码库复杂化
• 该功能可能会产生滚雪球效应，从而暗示了我们可能需要添加的其他功能，即使它们并不需要

它可能适用于软件构建，但我不确定它是否适用

如果我们考虑"决策的丰田方式"中的五个要素，则基于"我们如何做出决定与决定的质量同样重要"的原则：

[幽默模式开启]

• 找出实际情况，包括genchi gembutsu。

Except that sometime, one does finally understand what is going on when the client explain to us at the end of the project;)

• 了解解释表面外观的根本原因问为什么？五次。

Sure but the client is not available enough during the project ;)

• 广泛考虑替代解决方案，并为首选解决方案制定详细的原理。

Too late, the programmers are already coding like madmen :)

• 在团队内部建立共识，包括丰田员工和外部合作伙伴。

Oops that programmer is already re-writing the authentification system even though the old one was working fine

• 使用非常高效的通讯工具来完成一张纸的一到四个，最好是一侧。

Did you hear "death by powerpoint" ? This is not always our strong suit ;)

[幽默模式关闭]

认真地，正如前面的答案所言，敏捷哲学确实解决了这一丰田原则的一些核心租户。

如"丰田方式"一书中所述，只是"我们将不需要它"可能会更丰富一点。