Basically, favour flexibility and speed of response over big design up front and unwieldy specifications. One of the best ways of doing that is to only build enough to meet your current requirements, because you never know when they're going to change.
It may apply to software construction, but I am not sure it does apply
If we consider the five elements in a "toyota-way of decision making", based on the principle that "how you arrive at the decision is just as important as the quality of the decision":
[mode humour ON]
Finding out what is really going on, including 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;)
Understanding underlying causes that explain surface appearances—asking “Why?” five times.
Sure but the client is not available enough during the project ;)
Broadly considering alternative solutions and developing a detailed rationale for the preferred solution.
Too late, the programmers are already coding like madmen :)
Building consensus within the team, including Toyota employees and outside partners.
Oops that programmer is already re-writing the authentification system even though the old one was working fine
Using very efficient communication vehicles to do one through four, preferably one side of one sheet of paper.
Did you hear "death by powerpoint" ? This is not always our strong suit ;)
[mode humour OFF]
Seriously, as stated by the previous answers, the Agile philosophy does address some of the core tenants of this Toyota principle.
And it may be a little richer that just "You Ain't Gonna Need It", as described in the book "The Toyota way"
It is a good agile practice to think just like that. There is also something called Test-Driven-Development, that helps you get software without bugs (almost), but also have that side effect that NOTHING is implemented that you don't use.
A example is you're own collection class. If you only are needing a Add method, and a ToArray method, then why use the time to implement the Remove and Count methods?
发布评论
评论（4）
有点，是的。 这是敏捷哲学的核心部分。
基本上，优先考虑灵活性和响应速度，而不是大型的预先设计和笨重的规格。 最好的方法之一就是只构建足够的东西来满足您当前的需求，因为您永远不知道它们什么时候会发生变化。
Sort of, yes. This is a core part of the agile philosophy.
Basically, favour flexibility and speed of response over big design up front and unwieldy specifications. One of the best ways of doing that is to only build enough to meet your current requirements, because you never know when they're going to change.
它可能适用于软件构建，但我不确定它确实适用
如果我们考虑“丰田决策方式"，基于“你如何做出决定是与决策的质量同样重要”：
[模式幽默开启]
了解到底发生了什么，包括 genchi gembutsu。
<块引用>
只不过有时，当客户在项目结束时向我们解释时，人们终于明白发生了什么；）
理解解释表面现象的根本原因——问“为什么？” 五次。
<块引用>
当然可以，但是在项目期间客户的可用性不够；）
理解
广泛考虑替代解决方案并为首选解决方案制定详细的理由。
<块引用>
太晚了，程序员已经像疯子一样编码了:)
广泛考虑替代解决方案
在团队内部建立共识，包括丰田员工和外部合作伙伴。
<块引用>
哎呀，程序员已经重写了身份验证系统，尽管旧的系统工作正常
使用非常高效的通信工具来完成一到四，最好是一张纸的一面。
<块引用>
你听过“powerpoint死亡”吗？ 这并不总是我们的强项；）
[模式幽默关闭]
说真的，正如前面的答案所述，敏捷哲学确实解决了一些核心问题丰田原则的租户。
正如《丰田之路"
It may apply to software construction, but I am not sure it does apply
If we consider the five elements in a "toyota-way of decision making", based on the principle that "how you arrive at the decision is just as important as the quality of the decision":
[mode humour ON]
Finding out what is really going on, including genchi gembutsu.
Understanding underlying causes that explain surface appearances—asking “Why?” five times.
Broadly considering alternative solutions and developing a detailed rationale for the preferred solution.
Building consensus within the team, including Toyota employees and outside partners.
Using very efficient communication vehicles to do one through four, preferably one side of one sheet of paper.
[mode humour OFF]
Seriously, as stated by the previous answers, the Agile philosophy does address some of the core tenants of this Toyota principle.
And it may be a little richer that just "You Ain't Gonna Need It", as described in the book "The Toyota way"
像这样思考是一种很好的敏捷实践。 还有一种称为测试驱动开发的东西，可以帮助您获得（几乎）没有错误的软件，但也有副作用，即没有实现您不使用的东西。
一个例子是你自己的集合类。 如果您只需要一个 Add 方法和一个 ToArray 方法，那么为什么要花时间来实现 Remove 和 Count 方法呢？
所以是的。 遵循这个原则:)
It is a good agile practice to think just like that. There is also something called Test-Driven-Development, that helps you get software without bugs (almost), but also have that side effect that NOTHING is implemented that you don't use.
A example is you're own collection class. If you only are needing a Add method, and a ToArray method, then why use the time to implement the Remove and Count methods?
So yep. Follow that principle :)
有点旧新闻了。 它通常被称为“你不会需要它”（非惯用英语中的“You Arent' Going to Need It”），并缩写为 YAGNI。
当您不需要某个功能时，与实现该功能相关的问题：
It is old news a little. It's often called "You ain't gonna need it" ( "You Arent' Going to Need It" in non-idomatic English), and abbreviated YAGNI.
Problems associated with implementing a feature when you don't need it: