问敏捷的货币好处是什么？

EN

敏捷在更短的时间内(或者至少用更可靠的估计)产生更好的结果(更接近客户的需求，而不一定是他最初想要的)。这只是一种更好的项目执行方式(与“瀑布”相比)。顾客更快乐。程序员更快乐。项目更好。沟通是真实和透明的。生活是美好的。有什么不喜欢的，专业意义上的？

如果你有好的销售人员，你可以卖垃圾给你的客户，并收取更多。在经济上，这是合理的。现实要比容易上当的观点复杂得多：“如果你让顾客高兴，你的销售额就会增加；如果你让他们失望，你的销售额就会下降”。世界不是一个公平的地方。作为一个混蛋寄生虫你可以过得很好。很多人都这么想。你想不想成为一个人，这是你的选择。如果你是，我不会和你玩的。

如果你只想赚很多钱的话，那么赚很多钱并不是什么把戏。“公民凯恩”中的“埃弗雷特·斯隆”

另外：

我怀疑你所说的“传统”是指某种瀑布工作流。

货币利益是多方面的。实现额外功能所需的工时是主要的事情。一旦你启动了这个过程，你就不能停止它，因此，如果客户对他们所得到的不满意(而“愚蠢”的客户只关心完成他的工作，那么如果你的软件不能正确地完成这个工作，你就会失去客户)。

另一个是保证客户满意，这也会带来更多的销售和更快乐的客户(我们希望从业务的角度)。

拥有反馈开发周期的能力还意味着您可以适应技术改进(例如，现在即将到来的asp.NET mvc 4)，这也节省了大量时间。为项目设置了严格的规范之后，您就无法升级到更新/更好的技术/库/资产，这也可能会节省时间。

时间就是金钱。

我看到了一个演示，它很好地类比了敏捷相对于更传统方法的好处。它是基于游戏战舰。你和另一个玩家坐到正常的战舰网格。你们都有20张照片，每一张都花了5,000美元，最初的总费用是100,000美元。这是个陷阱，你必须事先计划好所有的射击，然后再开一枪。你的对手会“正常”射门，开一枪，看看会发生什么，再投一枪。

在20次投篮结束时，猜猜谁的命中率更高？

这个比喻非常清晰地解释了敏捷与瀑布的关系；在敏捷中，在规划下一步要做什么时，你可以把你已经做过的所有事情的总和都考虑进去。你将有一些基本的想法，哪些领域将是困难的，哪些领域将是容易的，基于困难或缺乏困难，你已经经历过。你还从你的客户那里得到了小块的反馈，说他们喜欢或者不喜欢这个，并且能够快速地融入这些知识，而没有在客户认为错误的东西之上构建很多额外的代码。

在传统的瀑布方法中，整个系统和开发计划都是在编码开始之前就计划好的。这是一种“在发射一枪之前就计划好所有的射击”的方法；你也许能够实现客户的要求，但他们可以看一看，然后说“这不是我们需要的”。是的，你得到你的钱是因为你按照合同的条款，但是你的开发者浪费了他们的时间，你的客户浪费了他们的钱，而且他们对结果都不满意。敏捷是为了帮助这一点而设计的，它允许在开发过程中改变项目的需求。任何您还没有做过的事情都是可以更改的；您已经做过的任何事情都可以更改，方法是在包含当前产品修改的待办事项中添加更多的故事。

另外，由于客户端可以决定您首先处理的是什么，并且随着您更频繁地交付小块已完成的工作，客户端可能会有一个他们可以更快使用的系统。这对您的客户来说是可见的ROI，这通常会使客户更愿意参与这个更复杂的开发过程。