除了在冲刺之间建立有效的组合之外，敏捷实践是否还有其他优势？

最近，我对软件开发中的敏捷实践产生了兴趣，从那以后，我已经看到很多文章指出，这些实践可以降低总体成本。

其背后的逻辑通常是这样的：如果您的需求发生变化，则可以在下一个sprint待办事项列表中反映此变化，这将导致成本降低，因为设计新功能并在时间上紧密地实现了新功能，因此根据著名的规则，成本降低了，您越晚需要对需求进行更改，满足该需求的成本就越高。

但是中大型软件项目很复杂。需求的突然变化并不意味着您不必接触系统的其他部分即可满足该需求。在很多情况下，将需要对架构进行非常大的修改，这也意味着您将需要重新实现依赖于较旧架构的所有功能。因此，降低成本的要点在这里已经消失了。当然，如果新的需求需要系统的新的独立部分，那不是问题，旧的体系结构只会不断增长，不需要重新考虑和重新实现。

相反。如果您使用的是瀑布，但突然意识到必须引入新的要求，则可以进行更改。如果需要更改现有体系结构，则可以重新设计它。如果它并没有真正引起混乱，而只是引入了系统的新部分，那么您就去做所有的工作，在这里没有问题。

话虽如此，在我看来，敏捷开发的唯一优势是可以在sprint之间完成功能的完整构建，对于很多人和项目来说，这并不关键。此外，敏捷似乎会导致整个软件体系结构不佳，因为某种功能会相互重叠，因此敏捷团队只关心功能的工作原理，而不是功能的工作原理。看起来，当系统随着时间的推移而变得越来越复杂时，敏捷开发实践实际上会增加整个产品架构的混乱度，从而最终导致更高的成本，因为引入变更的难度越来越大，而瀑布式设计则可以使您完善架构在释放任何东西之前。

有人可以指出我在哪里出问题了吗，因为显然很多人在生产环境中使用敏捷，所以我一定在某个地方错了。

首先，“瀑布”模型始终是一个稻草人，描述了如何不运行软件开发项目。查一下

无论如何，大多数“瀑布式” SDLC项目都需要一个“变更管理”过程，因为当人们发现写在规范中的假设不再有效时（在大型复杂项目中总是会发生这种情况）。不幸的是，变更管理过程是作为异常处理措施而建立的，而且非常昂贵，这意味着该项目将延迟很晚或质量很差。

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

前加载设计的另一个主要问题是（通常）在需求收集和设计，开发和测试时间上花费了太多时间。此外，如果测试是最后阶段，并且发现了严重问题，则极不可能在您的时间范围内解决。

敏捷方法的最佳功能之一可能是，它要求开发解决方案的团队与需要该解决方案的客户之间保持持续的交互（即真正的沟通）。确定优先级，以便首先处理最高优先级的项目（如果时间用完，则会削减低优先级的项目）。反馈很快。

回到急剧变化的问题-您确实需要使用缓解变化的方法。好的SOLID OO负责人可以在其中发挥很大的作用，构建可靠的自动化测试套件也可以使您可以对软件进行回归测试。无论采用哪种方法，都应该执行这些操作，但是如果您要变得敏捷，它们就变得非常重要。

好吧，这里有一些优势。首先是客户不阅读规格文档。曾经 Waterfall假设一开始每个人都会很好地同意规格，然后在一年后将符合规格的软件交付给客户时，他们会很高兴。实际上，客户在积极使用软件本身时，只会发现他们真正需要的所有东西，真正不需要的东西，以及确实需要有所不同的东西。敏捷在客户手中获得了一个可行的原型，因此这些脱节立即被发现。敏捷不仅仅是要对不断变化的需求做出反应。这还与在变更成本低时而不是在变更成本高时结束时早些发生变更需求有关。

第二个优点是，由于敏捷通常具有高度可见的可交付成果，因此项目不太可能脱离轨道。对于大型的Waterfall项目，即使没有意识到，也很容易落后。在项目结束时，瀑布会产生数月的死亡行军。使用敏捷，因为您每两周向客户交付一次，所以每个人都确切地知道项目在哪里，并且可以迅速捕获（调整）支票。以我的经验，Waterfall最终会产生几周或几百小时的工作。敏捷意味着您可能需要在冲刺结束后的12个小时之内投入一些时间。

第三个优势是，敏捷项目往往更具激励性。在为期一年的项目中，人们很难拥有任何动力。截止日期似乎很遥远，而且缺乏即时性意味着人们倾向于拖延，过度抛光设计，否则工作效率将不高。尤其如此，因为最初几个月是花在人们不喜欢做的事情上，例如规格文档。由于敏捷总是在不久的将来有一个非常紧迫的，具体的截止日期，因此人们往往更有动力。对于下周要完成的一组固定任务的具体截止日期，拖延要困难得多。

回应问题的引言，这是对反敏捷对手的根本误解

“……而瀑布使您可以在发布任何东西之前完善您的体系结构。” 是一个谬论，让我为您解决；“ ...而瀑布使您可以完善自己的建筑，因此您从不释放任何东西。 ”

从根本上讲，瀑布是如何提供更高质量的建筑的暗示是错误的，并被经验的历史证据完全驳斥。

如果Facebook的设计是一个瀑布式的设计，有5亿用户是一项紧迫的要求，并且直到一个完美支持的体系结构才发布，今天没人会听说过它。

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

他们得到了客户可以触摸和响应的信息，并尽快发布了该信息。他们得到了反馈并对其进行了完善，然后再次发布。重复。这样，在这三个示例中，它们仅以客户接受和想要的功能进行响应，并在客户发现价值很小或没有价值的事情上浪费尽可能少的时间。

任何具有多年软件开发经验的人都会同意，没有完美的体系结构这样的东西。只是比其他方法更远离熵和泥泞球的一种方法。敏捷承认并考虑了这一点。在构建过程中，这就像技术债务，快速的优先级划分和重构一样。

Scrum本身并没有规定任何技术实践，因为它是一个通用框架。

敏捷软件开发需要团队提供卓越的技术。这来自XP（极限编程）的以下技术实践。例如，您必须了解重构，tdd，整个团队，结对编程，增量设计，ci，协作等。

这样，就可以快速安全地处理变更，这也是首先使用敏捷开发的主要原因。

衡量敏捷性的一项重要指标是，您是否定期（每周，每两周一次）设法向客户发布有价值的有效软件。你能做到吗？然后，您在我的书中很敏捷。

对我来说，敏捷的主要好处是降低了项目的风险。

通过迭代地交付并从用户群中获得大量反馈，您增加了交付他们实际想要的东西的机会，并且您将通过尽早为他们务实地交付最重要的功能来做到这一点。从理论上讲，这将通过更好的估算和计划来完成。从业务角度看，这显然很有吸引力-不仅仅是可发布的版本。

您可能会说，这种不断的变化会损害您的系统并降低质量，但是我要说两点。1）无论如何，这种变化都会发生在更传统的软件交付项目上-它只是无法解释的，并且稍后会在项目中发生，正如您所指出的那样，当事情变得更难，更昂贵时。2）在使用有经验的，积极上进的人和实践（例如TDD，配对和代码审查）方面，敏捷对于处理这种变化有很多话要说。如果没有将思维方式转移到质量和持续改进上，我就会接受敏捷所暗示的频繁变化可能会引发问题。

在很多情况下，将需要对架构进行非常大的修改，这也意味着您将需要重新实现依赖于较旧架构的所有功能。

如果由于需求变更而需要对架构进行重大修改，那么您的架构要么不好，要么需求不好。良好的体系结构可以使您尽可能多地推迟决策，并解耦系统组件。好的（用户）需求不是“使用其他数据库”之类的东西。

因此，让我们在拥有良好工作架构的假设下进行操作。如果真是这样，那么敏捷开发方法论就会失去采用大型前期设计方法论的“洗礼”。毕竟，敏捷开发方法学的核心特征是TDD之类的实践，它们促进了代码中的松散耦合，从而使该项目无论是在开始时还是在非常成熟的时候都能够以高速度继续进行。

在很多情况下，将需要对架构进行非常大的修改，这也意味着您将需要重新实现依赖于较旧架构的所有功能。因此，降低成本的要点在这里已经消失了。

经过敏捷的过程，在开发过多的软件（并需要进行更改）之前，有更好的机会来捕获此需求。当您几个月不与客户合作并给予他们一些注意的机会时，您只有在“认为”您准备好交付时才发现这些主要的体系结构问题。

我宁愿尝试在具有测试覆盖范围的工作应用程序中实施这些更改，而不是大量甚至无法编译的代码。在担任技术支持负责人的同时，我还获得了一个应用程序的CD，该应用程序已经开发了几个月，甚至无法安装。我们可能在第一周就发现了这个问题，但是现在是时候订购晚餐了，因为那是一个漫长的夜晚。