问对设计掉以轻心是敏捷方法的一个陷阱，导致不断的返工，还是对方法的误解？

EN

这其中的一部分是预期的，一部分是好的，一部分不是，而且我们不能真正告诉你哪一个是哪个。

敏捷的主要重点是根据您今天所知道的，提供现在重要的内容。花点时间，实现这个重要的部分，然后把它发送出去，这样你就能更快地得到反馈。其中的一些反馈将是“呃，这实际上在实践中很糟糕！”这是敏捷促进的一种好的返工方式。既然你这么早就抓到了，你可以早点解决。

另一方面，对于业务人员来说，重要的东西对开发人员来说很少重要。作为开发人员，您需要有人倡导技术上重要的东西，如基础设施、培训和技术债务。这可以帮助消除大多数敏捷环境忽略的一些“空白”。但是最终，做好工作而不仅仅是拼凑一个解决方案的纪律会落在你的开发人员身上--敏捷与否。

尽管敏捷是基于最低限度可行的产品，并且只提供您需要的东西，但它也是基于您目前掌握的信息所能做出的最佳决策。

这意味着，不仅要考虑您正在处理的用户故事，还要考虑您所知道的即将到来或可能到来的内容。设计的正确时间是在你需要的时候--当你认为你正在做的事情可能会在将来引起问题时，考虑花时间进行设计。

对我来说，敏捷并不会鼓励设计决策的拖延或延迟，它允许您在一开始就消除系统设计的巨大开销(无论如何，这都不是正确的)，并在必要时将其集成到项目中。

在软件中总是会有某种程度的重新工作，总是会出现一些意想不到的事情，但是如果你说需求定义得很好，并且确实不太可能改变，那么你可以在设计的早期就考虑它们，并且在项目开始时仍然会花费相当多的时间在设计工作上。这也可以被看作是“sprint 0”的一部分--基本上是为项目规划一个框架。

在我所使用的敏捷设置中，这里的team wants.The定义不包括经理和业务民风。我同意，如果您在一个业务人员在技术问题上有更多发言权的地方工作，这可能是不可能的。

在我们的例子中，如果团队认为某些特性需要进行设计讨论，我们确实会想出一些设计文档和漂亮的块diagrams.But --这有时对某些特性来说是过分的，尽快完成它更有意义。

在敏捷工作流方面有经验的技术人员来指导演示和回顾可能会有帮助，在那里，相关的业务人员也可以参与并理解在敏捷中工作的实际含义。

每个团队都是不同的，所以应该由您的团队来确定什么是对您最好的，我觉得敏捷让您比其他模型更容易地使用演示、回顾来打开沟通机会，从而激发讨论和改进。