在敏捷环境中，负责软件架构的人

在敏捷团队中，谁负责制定影响整个系统的高级体系结构和设计决策，而不仅是当前sprint中正在完成的工作？

也许是产品所有者，Scrum主管，Scrum团队或其他人？

“软件架构是由整个团队执行的。这种实践并不能消除对软件架构师的需求，这仅意味着架构师可以以更广泛且可能更有经验的视角为讨论做出贡献，尽管如此，团队中的所有成员都为软件的体系结构。”

• 资料来源：http : //www.executivebrief.com/blogs/software-architecture-agile-environment-sashimi-approach/

当然是建筑师，但也许不是传统的建筑师。

我并不是说要负责所有思维，然后让猴子来做所有打字的首席外科医生。我指的是一位经验丰富的首席程序员，他了解难以逆转的决策的成本/收益折衷，并为团队提供建议。

很难找到有效的架构师，但是这可能是一个奇妙的职位，因此您可能至少有一个经验丰富，周到的程序员可以很好地完成工作。这样的人需要

• 当然，要做出好的架构决策
• 知道如何有效地提供建议，以便其他人也可以接受，并且
• 缓慢将架构决策委托给团队

最后一点使很多人绊倒。当善意的敏捷专家说“团队拥有架构”之类​​的东西时，他们就有“正确”的想法，但是我发现该建议在其应用中几乎完全没有意义。如果您信任团队对自己的体系结构负责，那么您将不会首先问这个问题，对吧？因此，我假设您问这个问题，因为有人担心

• 没有人会承担责任，我们的架构会很差，或者
• 错误的人将承担责任，我们的架构会很差，或者
• 负责任的人将成为替罪羊，您希望避免这种情况

如果您需要某人承担责任，则将其交给希望接受的人。说真的 那个人至少在乎。为该人提供完成工作所需的资源，并在需要时提供帮助。这个人的胜任力可能并不重要，因为如果他们在乎，那么他们将尝试学习他们需要学习的东西。当然，这样的人需要阅读的好书以及需要同事帮助的社区和指导老师的帮助。

如果您担心错误的人要承担责任，那么我希望您知道“正确的人”是谁，并将为将他们安装为建筑师而奋斗。像《新战略销售》一书将帮助您学习实现这一目标的销售技巧。

如果您只需要替罪羊，那么请悄悄推动他人，将您最想破坏或损害的职业的责任推给他人。至少对此诚实。

回到有效的架构师的工作之后，他们可以将其工作视为管理职位，而不仅仅是决策职位。如果他们不将最常规的决定至少委派给团队，那么它们将成为瓶颈，并拖慢整个组织的步伐。在顶部增加更多的架构师并不能使它更快。从头开始培养更好的架构决策。随着时间的推移，委派委员会技术将帮助您的架构师变得更加自在，因为这些团队通过展示能力赢得信任，从而将越来越多的决策委派给团队。

我认为一位优秀的架构师可以帮助我理解如何更好地设计系统，在我提出要求时会耐心地为我提供建议，并且偶尔会阻止我做出错误的决定。从最真实的意义上说，这样的建筑师就像领导人一样：别人自愿跟随的人。

我知道很多。

参考文献

米勒，新战略销售。本书提供了一个模型，用于了解您为什么无法完成特定的销售。在理解同事为什么不做我建议的明显美妙的事情时，我发现这非常宝贵。

温伯格成为技术领导者。这本书帮助我学习了如何做有效建筑师的非建筑师部分。

Appelo，代表团董事会和代表团扑克。不要低估委派的艰辛程度以及我们对它的依赖程度。学习更有效，更舒适地进行操作。

最好的架构，需求和设计来自自组织团队

- 敏捷宣言

因此，团队会自行组织以适合自己的方式做出架构决策。没有硬性规定，范围从共识到最高级成员的“委员会”，再到指定一个特定成员为体系结构权威，再到让架构师选择是否有这样的职务。 。

我觉得对“谁负责高层架构和设计决策的负责人”的答案取决于团队的规模和数量。

对于一个或两个团队，每个团队3-7人，则自组织团队可以由高级成员领导。

对于3个或更多团队，复杂性的提高导致需要一个架构团队，该团队可以查看各个子团队是否正在与其他团队进行交互。以我的经验，达到大约8个团队或大约50个人时，这一点已经达到。

可伸缩敏捷框架（SAFe）团队在其站点上提供了许多宝贵的资源。

从本质上讲，它可以帮助您在整个组织中扩展敏捷性，超越单个发行版，还可以扩展到项目组合和计划规划中。他们的文档显示了有关如何使企业和系统架构师参与将架构史诗引入发行流程的建议。

进行编辑以更清楚地解决该问题：

在规模化的敏捷环境中，该架构具有多层所有权。敏捷的实施团队将通过根据需要进行重构以拥有低级的新兴架构，以继续执行其积压的工作。更高级别的体系结构决策（受支持的操作系统，浏览器，平台，库）由您的系统和企业架构师负责。他们将为何时需要进行这些更改提供业务案例，并建议将这些体系结构更改添加到实施团队的发布培训中。

因此，对于超越冲刺的高层架构决策，通常会将这些决策置于团队之上。传统上，这些专业人员在企业内部已经扮演了“架构师”的角色。

我认为其他大多数答案都从进入项目内部的角度来考虑。

如果那是组织中唯一的体系结构级别，那么结果将很坦率地讲就是混乱。我亲眼目睹了这种混乱，不幸的是它发生了。

根据TOGAF的说法，企业架构部门为与企业一起创建和替换IT环境制定了高层计划。企业架构师将定义架构原则，并在组织的最高层上签字，并将帮助为每个项目创建高层架构和要求。启动每个项目以提供该高层架构中的架构构建块。

因此，在项目级别，解决方案架构师将创建项目架构（可能迭代），并从企业架构师处获得批准。

现在，将重点放在敏捷项目上。敏捷项目有要求。它们不是大量的“需求文档”形式，而是史诗和故事。这些史诗仍然需要计划。您不会让开发人员团队冲刺到未知的地方。您从较高的层次上知道了系统需要做什么，需要与之交互的其他系统以及组织具有哪些硬件/操作系统/语言限制，并且这指导和限制了解决方案架构师可以选择的体系结构选择。例如，如果你致力于.NET和SQL服务器，你将不得不作出一个非常由于支持两个数据库，两种语言，两个网络服务器等需要花费成本，因此有理由使用PHP和MySQL来实现基于Magento的电子商务站点。感觉，这可能会对所有其他机上项目产生影响。必须具有企业架构师的监督才能防止这种“建筑债务”的发生。

取决于组织的组织设计以及产品是否在投资组合中。较大的，面向角色的组织可以任命高级架构师来领导此类活动。

通常，高级架构师会协助并指导设计决策，因为它们不仅会影响产品积压，还会影响产品组合中的多个产品。

规模较小的敏捷公司可能会依靠系统专家的开发人员来带领开发团队调整架构设计。

最终，需要由负责该产品的交付团队就体系结构决策达成一致。经验丰富的建筑师和技术负责人将更加专注于促进围绕设计外观的讨论，而不是指示设计。

我认为大多数答案已经强调了团队不是一个人应该做出这些决定。

他们不碰的是另一个敏捷原则：

简单性-最大化未完成工作量的艺术-是必不可少的。

考虑高层体系结构和设计决策时，往往不会以简单为代价，这可能会导致浪费大量精力并增加不必要的复杂性，从而使事情难以扩展。

考虑“园艺”而非“建筑” —创建一种生活，不断发展的设计文化

在当前的迭代中，您应该根据当前的需求做出体系结构和设计决策。与其展望未来可能永远不会变成的未来，不如专注于您现在所需要的。YAGNI现在可能是一个经过深思熟虑的体系结构，让团队可以一点一点地处理它。

其他读物：

• https://less.works/less/technical-excellence/architecture-design.html