很多架构师在努力了很多年才得到这个威严的头衔“架构师”。他们确实应该为他们的知识、经历和能针对技术和业务挑战提出一流的解决方案的能力而骄傲。我发现很多架构师在面临采用Scrum时提出的担忧可以归纳为下面2类：
•大家仍会按照我告诉他们的架构去做实现吗？
•我如何能在没有一个提前设计架构的阶段后保证我们构建了一个架构不错的产品？
对首个担忧的答案完全取决于问题中的架构本身。很多架构师可能会发现对他们的头衔变化很少。因为其他开发人员尊重架构师并且知道他们的建议很可能是不错的，所以这些架构师建议的方案会被实现。例如，如果我的某个同事过去有过能做出不错的架构决定的名声，同时我观察在该项目做出过好的架构方面的决定，我将很愿意咨询她有关架构的问题。即使我们是一个自组织的团队，我也将这么做；没有人可以强迫我去获取跟我的决定有关的其他意见。
第二个担忧很大程度上没有理由。当我们将在第十四章中“每个Sprint中贯穿始终的协作”部分和第九章中“设计: 有意的而又是涌现式的” 部分中看到，产品架构方面的需求和业务目标一起被用来驱动产品Backlog的优先级区分。
AgileArchitect.org的Andrew Johnston曾写到：“在敏捷开发中，架构师主要的职责是去考虑变化和复杂性；而其他开发人员则关注于下一步的递交（2009）。在各个sprint中有合理开发顺序的工作可以帮助团队快速获得关键的知识，拥有足够时间反应来避免或发现风险以及最小化整个开发成本”。
不编码的架构师
不编码的架构师将会看到在他们做的工作中的最大变化。这些人被Scott Ambler称为“象牙塔中的架构师”（2008b）。不编码的架构师的出现是众所周知的麻烦出现的先兆，Scrum项目要摆脱他们。一些不编码的架构师应把Scrum看作一次机会，它能让他们重新做那些他们职业早期比较享受的开发工作，这些架构师对Scrum团队来说将是受欢迎的贡献者，他们将会因为他们知识和经验的深度以及卷起袖子立刻能编码的能力而受人尊重。
要小心那些拒绝角色转换的架构师，他们抗拒新角色需要在项目中亲手开发。在许多案例中，这些不编码的工程师曾将他们的职业生涯方向定位在避免亲手开发。有个类似的架构师Tom，在我首次碰到他时就让我讨厌。他讲了一个好游戏并且在所有正确的技术方面听起来也很有见地，但是他是我所遇到的首个很喜欢开会的开发人员。他总是在他的时间表中安排更多的会议。当我更了解他后，我认识到他的技术知识是很肤浅的—他并没我想的那么好。我很快意识到他喜欢花这么多时间参加会议的原因：在某个不必要的会议中，所有参加者是具有同等的生产率和价值的。
在团队成员回到工作桌开始做实际的工作时，开发人员之间的显著差异就开始显现。Tom对不必要会议的钟爱是一种自我保护的技巧—团队在会议中花的时间越多，这就会让每个人花更长时间意识到Tom不是那么好。作为一名有用的贡献者，那些有架构师头衔名片的人并不需要全职编码。实际上，架构师不用编写任何一行代码而完成一到两个sprint是很有可能的。我想说的差异是指仍然能编码的架构师与那些编码技能已经落伍的架构师之间。软件架构师Johannes Brodwall谈到这点时说“我作为一个架构师的角色，敏捷给我带来的最大变化是，之前架构师不需要具有指示具体技术解决方案的能力，而现在它必须能成为一个顾问和促进者。作为顾问，我最好自己仍然能做那些正在给出的建议的工作”。
作者:Mike Cohn
