大多数软件开发团队都了解敏捷宣言所描述的“内容”部分。但是，对于软件架构师来说，挑战在于“如何”变得敏捷，因为他们与开发人员实现相同目标的方式不同。除此之外，一些敏捷团队可能认为软件架构师角色是不必要的，模糊的，甚至违背敏捷软件开发的原则。
虽然一些敏捷框架试图为软件架构师的角色创建一个书面定义，但是这可能会导致一些人因为遵循指导，而没有达到他们应该达到的敏捷和实用的程度。一个好的架构师必须不断调整自己的行为，不要偏向某个特定的框架或方法，保持与流程的相关性，并为团队提供必要的指导和愿景。当确立了正确的心理模型时，敏捷宣言的价值将被自然地采用，这是所有敏捷软件开发方法的支柱。
在过去，特别是在瀑布时代，像“宇航员架构师”和“象牙塔架构师”这样的术语被用来定义一个离地面团队太远的架构师。他们并没有为软件本身增加真正的价值，而是更专注于以图表和规范的形式创建全面的文档，而不是创建可工作的软件。不幸的是，尽管我们开发软件的方式发生了巨大变化，这种现象今天依然存在。
支持“工作软件”并不意味着必须忽略文档。这两个方面并不矛盾，也不应相互排斥;相反，它们必须在最终产品中包装在一起。软件架构师必须记住敏捷宣言的最后一句话:“虽然右边的项目有价值，但是我们更重视左边的项目。”
综合文档可能会成为陷阱
具有体系结构影响的规范（以新用户故事的形式）应该由架构师跟踪，并由整个开发团队（包括经验丰富的开发人员、测试工程师和devops）以实用的方法进行评估。过去那种架构师在纸上为团队创建完整的技术设计的方式，并不适合现代敏捷环境。这个模型有很多缺点，我在日常的基础工作中也遇到过。
首先，也是最重要的，架构师可能是错的。在我创建了一个详细的前期技术设计并在Sprint改进期间提交给开发团队之后，我遇到了这种情况。我收到了一些与我没有考虑或没有考虑到的案例相关的问题。在大多数情况下，最初的设计不是不完整就是不切实际，需要额外的工作。
大的前期设计限制了团队成员的创造力和自主性，因为他们必须遵循已经批准的配方。从心理学的角度来看，即使是作者也可能会产生偏见，之后更不愿意去改变它，试图证明它是正确的，而不是承认它的缺陷。
架构师也将成为团队的瓶颈，因为他将努力提前提供准确的详细设计。一个完全依赖于架构师始终提供预先设计的团队具有多大的可伸缩性和自主性?经验丰富的开发人员喜欢参与系统的设计，并为系统的设计做出贡献，因此这种指令风格并不适合他们。
他们可能会说，“不要预先提供解决方案，而是告诉我们业务需求，让我们(与架构师)提出合适的设计”。当然，这并不意味着团队可以做任何他们想做的事情;在架构师和团队成员之间仍然必须有一些相互的协议，包括架构的核心原则和每个成员都必须理解和遵循的设计指南。
足够的文档作为开发软件的推动者
架构师仍然必须考虑全局，并继续维护系统的技术完整性，并注意集成点。在某些情况下，架构师应该进行前期分析来评估即将到来的业务规范，以便评估与当前架构相关的潜在风险，并使其对所有涉众透明。
当与新的外部系统集成时，或者对于具有体系结构影响的内部功能，这可能是至关重要的。在这两种情况下，如果架构师准备一些高级设计，就会变得事半功倍。一个粗略的组件图或一些功能用例可以作为进一步讨论的基础，并帮助团队全面理解所有涉及的组件。
然而，当涉及到具体的技术设计时，我的建议是让团队参与进来，集思广益，达成一致。这种协作在开发过程中既不应该太早也不应该太晚。例如，在常规sprint的情况下，架构师和团队可以在sprint开始之前的细化会议上达成共识。所有与该技术解决方案相关的实现细节(例如用于组件内部通信的内部API、多线程模型、数据库实体模型等)都可以在sprint开始时进一步讨论。
创建和更新技术文档必须在同一任务（在同一个sprint中）下进行，作为持续开发过程的一部分，并作为所有团队成员的共同责任。然而，架构师应监督并确保此流程顺利运行并成为团队文化的一部分。
当文件很重要时
在一些特定情况中，文档起着重要作用，架构师应该仔细考虑之：
具有讽刺意味的是，敏捷框架(如Scrum、SAFe)的开发是为了定义一个过程，但随后人们开始使用工具来编写过程(例如，遵循Scrum/SAFe过程的敏捷软件管理工具:产品规划、发布规划、sprint规划、sprint跟踪、sprint审查等)。这听起来可能与敏捷宣言的原则有直接的矛盾，然而，在现实中总是存在着一种混合，这取决于组织、产品、团队等等。重要的是要记住如何“敏捷”而不仅仅是“做敏捷”；重视沟通，持续合作，更好地了解对方，建立信任和纽带，倾听对方的意见。官僚程序和不适当的工具增加了更多的摩擦，降低了团队的速度。
架构师必须编写和审查代码
为了实现和维护团队内部的良好协作，并不断地参与开发过程，架构师必须是敏捷团队的一部分。这意味着积极地编写和审查代码，处理新特性请求，并监督端到端交付过程。
与开发人员相比，架构师可能在编码活动上花费的时间较少，但是尽可能多地编写代码是极其重要的。例如，我平均花费至少30-40%的工作时间编写代码(有时甚至是一整天)，其余时间用于会议和其他技术活动(例如技术设计、评估未来的业务规范)。
开发任务的性质可能不同，架构师必须关注在应用程序的敏感部分或体系结构的关键部分编写代码。或者，根据团队环境的不同，他们可以像其他高级开发人员一样处理任何任务。
除了编码，架构师还必须积极地参与评审其他人的代码，这可以提高不同模块之间对代码库的认识和知识。一个主要的关注点必须是检查应用程序中对性能、安全性或其他质量属性至关重要的那部分的代码。体系结构代码评审还应该确保系统边界(例如API、通信类型、消息等)、体系结构核心原则和设计准则不被违反。这有助于架构师确保预想设计和实际实现之间的一致性和完整性。
要更好地理解真正的挑战，并提供有意义的技术解决方案，唯一的方法就是“不要插手”。编写和审查代码使架构师与开发人员更接近，从而更好地理解他们的实际问题和需求，并培养深入的产品知识。
（未完待续）
注：本文译自InfoQ
| 留言与评论（共有 0 条评论） |
