architecture - 您如何控制敏捷项目中的架构？

Question

您如何确保项目将以“良好”的设计决策构建，从而实现灵活的软件架构？

您如何在将架构完全留给一侧的团队和让所有架构控制到另一侧的少数人之间取得平衡？

你有“架构组”、“架构标签”或类似的东西吗？

Answer 1

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

如果架构没有明确定义和完全理解，你就不能真正采用敏捷方法。

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

一旦你完成了这个“理解架构”的工作，你就可以开始执行直接为用户发布的 sprint。

Answer 2

我可以解释我将如何做到这一点，但这比我能说得更好。

Answer 3

我还建议阅读 fowlers 文档Is Design Dead，据我了解他的论点，如果您将所有敏捷实践视为一个整体，那么您将获得进行重大更改的自由，从而可以发展架构。

重构通过持续交互最有效，测试通过 TDD 和持续集成得到增强……我可以继续。仅当您无法进行纠正“错误”所需的大更改时，才会限制不断发展的“架构”。

此外，我认为你有一个架构师作为项目的利益相关者，他们贡献用户故事，然后将这些故事传递回给架构师。

这也是利用结对编程的好方法，架构师作为结对的一部分工作。在这种情况下，架构师与其说是一个敬业的人，不如说是开发团队成员在结对编程时戴的帽子。

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

[编辑]

根据其他评论，不要害怕一些前期计划，零迭代是尝试制定一些计划的好时机，只是不要严格按照特定的时间范围交付它。

Answer 4

以我的经验，最好的方法是让经验丰富的开发人员/架构师每天致力于推动架构愿景的项目。

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

Answer 5

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

Answer 6

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

我们的开发过程是基于频繁的同行评审的短期开发爆发。每个开发人员的架构决策的质量都在同行评审时得到验证。这还包括验证代码是否遵循产品架构。

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