敏捷宣言：软件架构师的视角（中）

01

架构师必须不断促进团队共识，并消除官僚程序

组织热爱流程，管理层则热衷于为团队创建“规则”。组织越大，这种流程就越彻底和官僚主义。要快速了解公司的官僚作风，数一数你上面有多少个管理层；大多数时候它们是成正比的。谈到软件开发，我想谈谈两个对团队既有直接影响又有长期影响的特定过程:代码评审和代码质量检验关(例如代码覆盖率)。

架构师和团队必须积极参与评估产品实际需要的内容，以实现业务目标并满足利益相关者的需求。在达成团队共识后，以自下而上的方式记录并将其传达给利益相关者，而不是相反。如果团队参与了决策，他们就会相信这是正确的方法，并会支持它。拥有团队一致同意的代码评审指南可以节省宝贵的时间，并防止在代码评审过程中出现过度争论或过于具有挑战性的事情。除此之外，它还会产生一个同构且一致的源代码，因为开发人员将遵循一组类似的审核模式以及实施指南。

代码质量检验关（包括代码覆盖率）解决了产品的内部质量问题。内部质量提高导致外部质量提高，客户和产品受益者可以看到这一点。保持产品良好的内部质量应该是团队文化的一部分，而且是团队成员喜闻乐见的文化。

相反，在团队中强加任意的代码覆盖率阈值或任何类型的质量检验关，将导致人为的低效。开发人员将很难调整他们的代码（包括开发合成测试用例）来满足这些度量标准。更糟糕的是，他们可能不会认真对待，因为他们不相信这些措施的真正好处。

任何对开发过程有直接影响的流程都必须由团队驱动、拥有并不断审核。与其强加自上而下的规则，不如使用回顾来讨论代码评审指南和内部质量检验关是如何提高软件质量的。当外部定义和强加给团队的情况发生时，架构师应该真正地挑战并尝试预防它们。

02

架构师必须与开发人员保持更密切的关系，既是他们的仆人，也是他们的保护者

将你的工作站放在开发人员旁边，并像其他团队成员一样积极参与对话。这改善了协作和人际关系，创造了更强的联系，以及更好的团队精神。个人和互动比任何形式的流程都要有效得多。不断地询问团队成员，特别是开发人员，他们是否需要帮助，并思考你可以做些什么来更好地支持他们。

同事们会欣赏你的做法，并将你视为一个真正的团队成员。当他们遇到问题时，他们会毫不犹豫地来寻求你的建议，因为他们知道你能支持他们。他们应该把你看作一个领导者，而不是一个戴着另一顶帽子的经理。不要给自己贴上架构师的标签；相反，让其他人欣赏你的贡献，并重视你作为架构师的角色。做团队的推动者和仆人，而不是他们的老板。

有时候架构师必须保护团队免受客户、产品所有者、业务分析师甚至scrum master的压力。你可能会认为SCRUM或SAFe之类的方法明确地将这一职责委托给scrum master。但在现实中，我也遇到过这样的情况：即使scrum master也变得苛刻起来，并试图把事情推到一边，这可能会损害内部工作质量。

此外，客户希望交付越来越多的功能，而且还想要更快和更低的成本。有时，产品所有者或业务分析师可能希望在Sprint期间添加或修改用户故事，这将增加开发工作量。在所有这些情况下，架构师都应该控制外部压力并消除这些不良习惯。

与相关方进行讨论，并让他们意识到长期的后果，例如人们变得缺乏动力，可能会离开项目，影响产品质量，或对未来开发成本产生负面影响，等等。保护团队免受外部压力，提供稳定、舒适和可预测性是保持团队健康的重要因素。

03

架构师应该让人们在他们的环境中感到舒适，并避免破坏性的活动

与其召开正式的技术会议，不如与团队成员直接接触，讨论问题，无论是在办公室里坐在他们的办公桌前，还是一起去咖啡馆或共进午餐。这是一个重要的事实，技术人员不喜欢开会。因此，尽量减少会议的次数，并让开发人员更接近他们感觉舒适的环境(即在他们的计算机前)。与其向开发人员询问未来的会议可用性，不如当场进行；在正式会议之外进行直接友好的交谈。

对于远程团队，当团队成员分布在各地时，需要一些特别的策略。比如，有一种方法是，将每一位员工都视为远程工作者，但仍然让开发人员处于自己的舒适区。这意味着永远不要进入会议室，而是宁愿在每个人的办公桌上都有一个视频会议，即使这意味着有些人戴着耳机坐在一起。

架构师应该注意减少会议的干扰；有时候太多的干扰是不好的，技术人员可能会失去注意力，变得效率低下。此外，有些人在早上更有效率，而对其他人来说则完全相反。在任何一种情况下，架构师都必须找到合适的时机和良好的平衡，以避免危及工作时间，并保持人们的注意力集中。

04

架构师必须找到将业务功能与技术故事相结合的空间

  

除了业务功能之外，可能还有与产品内部质量相关的技术任务，这些任务值得优先考虑。其中一些支持业务功能的开发，这些功能对客户来说是直接可见的，而另一些功能可能不会立即产生实际效果。这些示例可能与重构或重组(以提高代码可读性、增强内聚性、减少耦合)、升级库或框架版本、增强日志格式、添加跟踪和监视等相关。

架构师必须在添加新功能和所需的技术任务数量之间保持平衡。根据我的经验，在产品负责人面前，逐一为每一个sprint划分优先级并说明其必要性并不容易。最重要的是，向非技术人员说明或证明技术上的合理性是不容易的。他们也许清楚概念，但往往对必要性没有正确的理解。

对我有效的解决方案(现在已经很少的项目中)是与产品负责人就技术任务的配额(或技术缓冲区)达成一致(大约是团队平均速度的20%)。在此限额内，架构师和团队成员可以自由决定下一个sprint中包含哪些内容，以便在技术任务之间保持合理的进展。这个配额可能不会被定期严格遵守，但是，与产品所有者达成共识并在必要时利用这个选项是很重要的。

05

架构师应该支持开发人员及时了解最新技术

架构师应该与产品所有者和scrum master讨论，留出时间让团队学习他们热衷的不同技术，或者为开源项目做出贡献，即使这些技术与他们的产品没有直接联系。当人们与最新的技术保持同步，并接触到其他想法时，会对产品产生积极的影响。

有些公司高度鼓励这类活动并认为这是理所当然的，而在其他地方，由于总是需要忙“正事儿”，因此很难获得批准。像SAFe这样的方法论明确地为类似的活动分配了空间(每四个创新sprint之后就有一个)，这是一个很好的进步，但是，在我看来，这必须是所有产品开发团队“日常”的一部分。

另一种补充方法是，定期为团队成员提供参加顶级技术会议的机会，并为他们参加专门的在线课程或培训平台提供便利。试着与预算负责人协商这些福利。团队成员会感到被赏识和奖励，并且会在项目上停留更长时间。团队中有知识丰富的人会带来更高的产品质量。举办不同主题的演讲，包括内部实践社区，感兴趣的人定期会面和讨论技术主题，是传播知识和最佳实践，强调人际互动和良好协作的好方法。

（未完待续）

注：本文译自InfoQ

点击【在看】与好友一起分享