软件架构师在敏捷团队中扮演什么角色

软件架构师是敏捷团队中的“鸡”还是“猪”？不管怎样，架构师通常能帮助开发和项目团队在长期内保持高效交付。

译自 Here’s What a Software Architect Does in an Agile Team 。

你是一个软件架构师。随着人工智能再次颠覆行业角色，关于架构师在敏捷团队中的角色的争论仍在持续。我不想假装这是全新的争论；事实上，The New Stack就这个问题还发表过一篇较新的文章。

“架构师”这个词的问题在于，它在建筑行业有非常具体的含义。这是大多数人首先接触这个概念的地方。但是在软件开发中，它是一个更加分散的术语。在某些情况下，它只是作为一个荣誉头衔使用——不太像“思想领袖”那么空泛，而是给予资深人员一定尊重，但不授予实际头衔。但让我们暂且不谈这一点，假设你是真正意义上的架构师。

对于运行简单网页应用的团队来说，大多数人可能认为不需要软件架构。开发人员都有自己喜欢的前端框架。AWS可以提供各种解决方案，并指导如何托管网站，如果这就是你所需的。现在已经不需要说服任何人使用Git了。我们都知道网站能做什么，所以客户和开发团队之间的沟通可能很顺畅。在这种有限的场景下，谁还需要架构师呢？当然，在这种简单的情况下，架构已经融入背景；网站在一段时间前已经标准化，它们能正常工作，我们不再仔细检查底层机制。但是一旦需要更复杂的功能，软件架构的重要性就凸显出来了。Tailwind仍然合适吗，还是Bootstrap的组件更可靠？我们需要在Lambda中运行额外的方法来降低成本吗？客户是否有从网站获得更多商业价值的需求？因此，作为架构师的第一个职责是: 通过管理复杂性来降低风险和成本。

当一个组织涉及多个团队或产品时，架构师可以更轻松地保持稳定的进展。有时是确保多个团队使用通用的API。维护流水线并定义不同的阶段。一些现有的云解决方案隐含了特定的设计，这也形成约束。无论哪种方式，架构师通过提供结构、统一标准和确定性来避免混乱。

将架构工作前移

敏捷关注当下

这可能开始作为一个不言自明的秘密，但现在已被广泛接受: 架构师可能不是一个有效的敏捷团队角色。我承认有时我对开发团队中的非编码成员过于狂热。温和一些的观点是意识到敏捷中的“猪”和“鸡”的区别。在做早餐时，鸡生鸡蛋而猪付出了真正的代价。因此，只有“猪”才应该参加每日站立会议。

将架构师角色引入典型的敏捷团队中有以下三个问题。可以把这些看作新教改革运动中的论点，象征性地张贴在会议墙上。

• 敏捷没有前期设计阶段。
• “最好的架构、需求和设计来自自组织团队”。
• 架构师不能作为批准者而造成延迟。

这导致了架构知识应该在团队其他成员中传播的观点。这通常确实如此——但是，它掩盖了架构责任并不明确落到任一个人身上这一事实，即使团队成员可能觉得自己负有责任。还记得RACI矩阵吗。

难道所有的敏捷开发者都应该兼任项目架构师吗？这似乎并不合理，因为架构描述了一个统一的计划。它不是一个持续的论点，不像软件开发可以是。

拥有架构能力的最大原因是当一个内部系统必须与另一个系统协同工作时。但是期望整个团队都对两个系统都有完整的了解，这是不现实的。

悄悄引入设计

我并不完全相信所谓的“出现式设计”；事实上，我经常看到设计被偷偷引入了day 0的冲刺计划，即使只是一个“稻草人”设计。或者由于高级成员的建议，某一建议的架构并未受到质疑。

这导致如果架构师也是一个动手的开发者，他们的刻意设计可以被悄悄引入，而不受任何质疑。尽管这是一个实际的解决方案，但它确实意味着团队运作变得不透明。

治理也是必须做但是通常被忽视的事情。敏捷仪式理论上可以帮助自我治理；但是当回顾不到位时，一个代价就是缺乏任何“演进”架构所需的反馈。

刚刚好的架构

因此，“大前期设计”已经被排除在外，架构必须更像轨道而不是完整的路线图。设置边界，利用现有系统中的技术限制来维持愿景，并与其他团队和项目保持一致。

我通常不会提及SAFE或"可扩展敏捷框架"，但它在面对与 Architectural Runway 理念的矛盾时相当乐观。它提出了字面意义上的“空中铺路”的概念，就像《惊魂鸟》动画中威利狼徒手在空中造路那样，这在物理上显然是不可能的。

但我们理解他们的意思。制定从“这里”到稍远“那里”的计划。这可能是足够的API、对新工具使用的限制，或者为即将到来的需求重新组织CI流水线。这也可能是指导开发人员理解与现有系统合作的好处，而不是重复开发。

从内部优化敏捷系统

我认为在严格遵循敏捷方法的同时，仍有效地为团队或项目工作的空间。事实上，认识到敏捷的局限性在一定程度上有助于改进它。

开发有意图的设计(可能不是一次展示全部，而是分阶段)，并不会太超前于客户需求——这些是敏捷架构师的主要技能。

处理技术债务也暗示了我们已经接受敏捷会导致生产力泄漏。在敏捷环境中，引导开发实现计划可能是架构师最佳介入点。这在敏捷过程中是合理的——先让代码实现对关键利益相关者的价值证明，然后以更多预见性重写代码。

关注组织内其他团队正在使用的数据格式和API，并添加故事来推动实现一致，这在任何敏捷框架下都可以良好工作。与json和yaml的重复争论相比，更好地利用社区实践，专注于最佳格式。

因此，即使稍微逆势而行，也不需要完全推翻敏捷系统。虽然我必须承认，这仍然使架构师成为一只“鸡”而不是“猪”，但架构师可能是保障团队和项目长期有效交付的关键——避免项目陷入混乱。