敏捷的隐性假设

敏捷解决了我们在软件开发中遇到的常见问题，但是，敏捷存在局限性。 这看起来似乎是灵丹妙药，但是在某些情况下，敏捷不是开发的最佳选择，或者至少不是整个项目的开发。

到目前为止，瀑布模型的问题已广为人知和理解。 高层次的瀑布方法吸引了高管，因为它为思考问题提供了一种清晰的方法。

毕竟：

• 您无法在满足需求之前进行设计
• 设计之前就无法编写代码
• 在进行编码之前，您无法测试某些内容

这些事实在敏捷中也是如此。 唯一的区别是，您不会像大爆炸那样尝试完成所有阶段。 我们知道，除非使用某种迭代过程，否则我们将无法返回上一个阶段并修复任何问题。 因此，敏捷过程如下所示：

就是说，我们不是一次大爆炸，而是一次做一点。 有些方法将每个sprint产生的代码称为“砖块”，通过砌砖，我们最终完成了隔离墙。 因此，敏捷本质上是在简化瀑布方法，但是所有需要完成的工作仍然完成。

那么为什么在地球上我们要使用瀑布式过程呢？

敏捷的一个隐藏假设是，您可以一次构建一个砖块来构建所有软件项目。 但是，您是什么时候最后一次看到承包商出现并只是没有计划就开始建造摩天大楼？

我的意思是，不仅仅是一次建造摩天大楼的问题，为什么还要烦恼规划呢？

即使将摩天大楼从下往上一次建造一层，但仍然需要先进行一些建筑规划。 建筑物支撑结构中的材料以及为每层楼提供公用服务（管道，电，空调）的公用组件需要预先计划。

如果没有对建筑进行足够的规划，则没有足够的水管将水驱入建筑物的顶部，购买了不足的断路器来满足电力需求，可能没有足够坚固的材料来支撑建筑的重量。建造。

软件在一定程度上具有延展性，您可以在事后添加内容。 但是在事实之后添加东西通常会产生成本，这要比元素是预先设计的要高得多。 例如，您可以在帝国大厦中添加一个停车库，但这样做的成本高昂。 如果他们想要一个车库，那应该是在建筑物建造时就建造的。

因此，任何需要认真架构的项目都应暂停并计划该项目所需的结构和连接元素。 应该首先开发与体系结构相关的需求，以便首先开发项目的体系结构。 当然，可以使用敏捷或传统的瀑布方法来开发体系结构。

一旦架构就位，然后就可以使用敏捷知道剩下的所有结构和连接元素就可以完成其余的开发。 这类似于一旦计划了架构就一次将摩天大楼建造一层。

首先构建体系结构的替代方法是，您发现自己已构建了一个10层的建筑，然后意识到需要拥有30层。 当您到达10层以上时，最初需要快速解决的初始架构会受到周围环境的影响。 您可能会到达15或20层，但是您将永远无法完成项目。

在建造了几层楼之后，增加昂贵的东西：

• 需要额外的电梯
• 在停车场需要额外的地板
• 需要整个建筑用光纤电缆

大多数项目不需要高级架构，就像大多数2层楼的房屋不需要建筑师一样。 但是，如果您的项目很大并且具有认真的体系结构考虑，那么您最适合预先计划体系结构。

在进行敏捷开发之前，请确保计划架构。

翻译自: https://www.javacodegeeks.com/2016/07/hidden-assumption-agile.html