除了在sprint之间进行工作构建之外，敏捷实践还有其他好处吗？

Question

最近，我对软件开发中的敏捷实践产生了兴趣，此后我看到了许多文章，指出这些实践允许降低总体成本。

这背后的逻辑通常是这样的:如果您的需求发生了变化，您可以在下一个sprint待办事项中反映这一变化，这将导致降低成本，因为设计新特性和实现它在时间上是紧密相连的，因此成本会降低，根据一条著名的规则，您需要对您的需求进行更改，那么满足该需求的成本就会越高。

但中、大型软件项目是复杂的。对需求的突然更改并不意味着您不必为了满足该需求而接触系统的其他部分。在许多情况下，架构需要进行非常大的修改，这也意味着您需要重新实现所有依赖于旧架构的特性。所以降低成本的重点就消失在这里了。当然，如果一个新的需求需要一个新的独立的系统部分，这不是一个问题，旧的架构只是增长，它不需要重新考虑和重新实现。

反之亦然。如果你正在使用瀑布，你突然意识到必须引入一个新的需求，你可以去改变你的设计。如果需要修改现有体系结构，则重新设计它。如果它并没有真的搞砸它，只是引入了系统的一个新的部分，那么你就去做所有的工作，这里没有问题。

尽管如此，在我看来，敏捷开发所拥有的唯一优势是在sprint之间完成功能构建，对于很多人来说，这并不重要。此外，敏捷似乎会导致软件体系结构整体上的恶化，因为特性之间会相互影响，敏捷团队只关心某个特性的工作，而不是它的工作方式。这似乎表明，当系统随着时间的推移变得越来越复杂时，敏捷开发实践实际上会增加整个产品体系结构的混乱，从而最终导致更高的成本，因为引入更改将变得越来越困难，而瀑布允许您在发布任何东西之前完善您的体系结构。

有人能告诉我我在这里哪里出错了吗?因为很明显，很多人在生产环境中使用敏捷，所以我肯定错了。

Answer 1

首先，“瀑布”模型一直是描述如何不运行软件开发项目的稻草。查一查。

无论如何，大多数“瀑布”SDLC项目都需要一个“变更管理”过程，因为当人们发现被写入规范的假设不再有效时(这种情况总是发生在大型复杂项目上)。不幸的是，变更管理过程是作为异常处理措施构建的，而且代价很高，这意味着项目将结束得很晚，或者质量很差。

敏捷方法学背后的理念是，改变是一种必然--它将会发生。因此，您必须进行“更改管理”标准操作，而不是异常处理。这并不容易，但人们已经发现，如果您使用许多好的设计实践，您可以做到这一点。

前端加载设计的另一个主要问题是(大多数情况下)在需求收集和设计、开发和测试时间上花费了这么多时间。另外，如果测试是最后一个阶段，并且发现了一个严重的问题，那么很难在您的时间范围内修复它。

也许敏捷方法的最佳特性之一是它需要开发解决方案的团队和需要它的客户之间持续的交互(即真正的交流)。优先级是确定的，这样就可以先完成最高优先级的项目(如果时间不多，那么低优先级项就会被削减)。反馈来得很快。

回到戏剧性变化的问题上--你真的需要使用减轻变化的方法。优秀的SOLID OO主体可以发挥很好的作用，也可以构建坚实的自动化测试套件，这样就可以对软件进行回归测试。不管你的方法如何，你都应该做这些事情，但是如果你想变得敏捷，它们就变得非常重要。

Answer 2

嗯，有几个优点。第一，客户不阅读规范文档。永远不会。瀑布假设每个人都会在一开始就很好地同意一个规范，然后当软件在一年后交付给客户时，他们会很高兴的。在实践中，客户只会发现他们真正需要的、真正不需要的东西，并且在积极地使用软件本身时确实需要与众不同。敏捷在客户手中获得一个工作原型，因此这些断开立即被捕获。敏捷不仅仅是对不断变化的需求做出反应。当更改的成本较低时，而不是在更改的成本较高的时候，更改需求也会提前发生。

第二个优势是，由于敏捷具有高度可见的可交付性，因此项目不太可能偏离轨道。有了一个大型瀑布工程，它很容易被远远落后，甚至没有意识到它。瀑布在项目结束时产生了数月的死亡游行。使用敏捷，因为您每隔几周向客户交付一次，所以每个人都知道项目的确切位置，并且快速地捕捉到(并调整了)错误。根据我的经验，瀑布会在最后产生一周或几个月的100个小时的周。敏捷意味着你可能不得不在冲刺结束时每天花几个小时。

第三个优势是敏捷项目往往更有动力。在一个长达一年的项目中，人们很难有任何一种动力感。截止日期似乎如此遥远，缺乏即时性意味着人们倾向于拖延、过度抛光的设计，或者只是工作效率不高。这一点尤其正确，因为最初的几个月都花在人们不喜欢做的事情上，比如规范文档。因为敏捷在不久的将来总是有一个非常即时的、具体的最后期限，所以人们往往更有动力。对于下周到期的一组固定任务来说，拖延一个具体的截止日期要困难得多。

Answer 3

在回答这个问题时说，这是反敏捷反对者

的一个基本误解。

“.而瀑布允许你在发布任何东西之前完善你的架构。”这是个谬论，让我来帮你解决吧；“.而瀑布允许你完善你的架构，所以你永远不会发布任何东西。”

瀑布提供更高质量建筑的暗示是根本错误的，并被经验性的历史证据所证明。

如果Facebook是以一种瀑布式的方式设计的，拥有5亿用户，这是一个艰难而快速的需求，直到一个完善的支持体系结构才会发布，那么今天没人会听说过它。

YouTube、Twitter和其他无数公司也是如此。

他们得到的东西，客户可以触摸和响应工作，并尽快发布。他们得到了反馈，并对其进行了改进，并再次发布；迭代。在这三个例子中，它们的反应只是客户接受和想要的特性，并尽可能少地浪费时间在客户发现很少或根本没有价值的东西上。

任何有着丰富的软件开发经验的人都会同意，没有一个完美的架构。只是一个比其他选择更远离熵和大泥球的方法。敏捷承认这一点，并将其考虑在内。在这个过程中，这包括技术债务，快速重新排序和重构.