敏捷方法导致碎片设计

Question

如何通过每月冲刺/迭代来防止敏捷方法导致设计碎片化。对于前者以曼哈顿街道设计与波士顿街道设计为例。曼哈顿街道的蓝图设计为一个整体，因此易于操纵和驾驶。波士顿的街道设计采用单餐方式，是一场噩梦。

Answer 1

Streets是用于软件的不好的比喻。如果没有重要的努力，就无法轻松移动，重新路由或更改街道。编写良好的软件是正交组件的组合，可以根据需要轻松重组和修改。

敏捷开发的原因在于开发人员和软件本身都是敏捷的。开发人员对变更做出快速反应，他们编写的软件也以对变更做出响应的方式编写。

Answer 2

重构，重构，重构。

Answer 3

敏捷开发并不是要求抛弃过度设计的任务。例如，规划“大局”非常有意义 - 主要组件的职责是什么，以及它们将如何相互作用。在我自己的团队中，我发现一个合理的妥协方案是事先就广泛的公共API达成一致，但在可能的情况下推迟详细的实施决策。这使得各个开发人员可以随着实现的发展自由地修改设计，同时还可以获得在设计级别挖掘不同方法的好处，而这些方法的变化要便宜得多。模块化也是关键 - 保持组件的功能特性并尽可能地彼此分离。当您发现需要对实现进行更改时，这可以最大限度地减少开销，并且应该增加您编写的各个组件仍然有用的机会。

Answer 4

您可以设定一个决定Streets的设计阶段。在每个阶段确定建造什么建筑物。

我认为scrum项目中存在设计/架构设计太少的趋势。你可以做不断的重构，但如果没有设计的话，这可能是很多工作。如果设计中存在错误，您可能会遇到同样的问题。

Answer 5

使用SOLID principles会导致代码松散耦合＆amp;高度凝聚力。

记住设计是王道。

恕我直言的软件组件与建筑物，街道的类比是不合逻辑的。这些都与软件开发或软件设计无关。

Answer 6

敏捷用户总是有可能建议根据当前的情况调整敏捷的原则，但是当这种情况随后失败时，那些支持迁移到敏捷的人会受到批评，因为敏捷没有被完全采用。< / p>

碎片化设计是敏捷的持续风险，因为架构没有价值。我们需要的是一种使用敏捷的有利方面的方法，例如持续交付，但解决了诸如敏捷的不可扩展性之类的问题。一种可能的方法是The Game of Thrones Methodology就是这样做的。

Answer 7

“敏捷方法论”（我认为你的意思是SCRUM，这里）与你的设计架构没什么关系;架构是您创建的软件或系统的属性（在UML世界中，您可能将其称为“artefacts”）。

“Agile”并没有告诉您任何关于您编写​​的软件类型的信息，它可以用于任何和所有类型的软件，甚至可以轻松地用于与软件无关的项目。

因此，如果您感觉敏捷项目中存在错误的软件架构，那么您应该查看实际原因是什么。只是因为你敏捷并不意味着没有计划，每个人都做他想做的事情，或者你根本不需要任何文件。虽然在开始工作之前不会将每个类指定为位级别，但您仍然需要写下高级架构，甚至在第一个sprint之前。根据您的团队规模和选区，您可以想象使用您的第一个sprint甚至创建您的架构。