您如何在敏捷项目中控制架构？

Question

如何确保项目能够通过“良好”的设计决策来构建，从而实现灵活的软件架构？

如何在一方面完全离开架构与团队之间取得平衡，让所有架构控制到另一方的少数人？

您是否拥有“架构组”，“架构标签”或类似的东西？

Answer 1

敏捷方法的先决条件是您已经知道如何使用的架构。

如果架构没有明确定义并且完全理解，那么你就无法采用敏捷方法。

您需要有一些技术峰值，以显示架构的工作原理，以及各个部分如何组合在一起。你可以做这些是初步冲刺，但它们不会直接导致用户发布。它们是一个特殊情况，需要进入可以使用的架构。

一旦你超越了这个“理解架构”的努力，你就可以开始执行直接导致用户发布的sprint。

Answer 2

我可以解释一下我会怎么做，但是this说得比我好。

Answer 3

我还建议阅读fowlers文档Is Design Dead，据我所知，如果你考虑所有敏捷实践作为一个整体，那么你就可以自由地做出大的改变，从而可以发展一个架构。

重构与连续交互最有效，TDD和持续集成增强了测试...我可以继续。如果您无法进行大量更改以纠正“错误”，那么不断发展的“架构”将受到限制。

此外，我认为你有一个架构师作为项目的利益相关者，他们提供用户故事，然后交给建筑师。

这也是利用结对编程的好方法，而架构师则作为对的一部分。在这种情况下，架构师并不是一个专门的人，而是开发团队成员在成对编程时所戴的帽子。

我认为XP并没有削弱架构师（和架构）的作用，它只是将所有团队成员的责任放在项目的整个生命周期内交付和分摊成本。

[编辑]

其他评论不要害怕一些前期规划，尝试零是尝试制定计划的好时机，只是不要严格按照特定的时间尺度交付。

Answer 4

根据我的经验，最好的方法是让经验丰富的开发人员/架构师参与项目，逐日推动架构愿景。

我建议项目的开发负责人来控制架构并确保所有新工作都适合它。

Answer 5

我通过预先做一些计划来处理这个问题 - 通常，我有一些类似应用程序的先前经验来帮助解决这个问题。如果没有，我会在空间进行一些探索以获得一个想法。一旦构建了基本架构，我将根据我的优先级故事开始考虑它。然后，当我继续解决架构中的缺点或错误时，我进行了重构。

Answer 6

如果不进行大型设计，通常会有一个适用于每个项目的基本设计。通常，这定义了在应用程序设计中要遵守的基本层。大多数其他设计决策都是由每个开发人员做出的。

我们的开发过程基于短暂的开发突发和频繁的同行评审。每个开发人员的体系结构决策的质量在同行评审时进行验证。这还包括验证代码是否遵循产品架构。

根据项目类型和可用工具，我们还使用macker等工具自动验证图层蛋糕的完整性。